Answer Boundary
Forces the model to commit to a final, discrete answer after reasoning, so the result is explicit and separable.
Problem
Reasoning and conclusion blend together, leaving no clean final decision for action, comparison, or automation.
Solution
Add an explicit commitment boundary and require a discrete final answer token/line/label. This does not improve correctness directly; it guarantees a separable commitment after reasoning.
Example
One worked example. The book has 2–4 per technique.
Classify the following support ticket by priority. Ticket: "Our entire sales team (12 people) cannot access the CRM since this morning. We have client calls starting in 2 hours and no access to account histories." Think through the impact, then classify as exactly one of: P1-CRITICAL, P2-HIGH, P3-MEDIUM, P4-LOW.
The issue affects an entire team of 12 people with a hard deadline in 2 hours. The CRM is a core business tool; without it, client-facing calls will proceed without account context, which risks deal quality and customer perception. This is not a partial degradation; it is a full access outage for a revenue-generating function with an imminent business impact. Classification: P1-CRITICAL
Techniques
Concrete ways to implement Answer Boundary. Each technique fits a different situation.
- 01
Open Answer
Require a final answer in the model's own words after a marker like "Assessment:" or "Decision:" so a nuanced conclusion stays extractable.
- 02
Constrained Answer
Require the model to commit to exactly one label from a predefined set so outputs are comparable across runs and parseable without ambiguity.
Full treatment in the book
Answer Boundary — the complete chapter
- ▸ Mechanism — why this pattern works
- ▸ 2–4 worked examples per technique
- ▸ Placement, sequencing, and debugging rules
- ▸ Composition with related patterns