# Spec Driven Development — Chapter 06 Memory: 2b - Requirement Language: Writing What the AI Executes Without Guessing
- **Stage**: Complete
- **Next Step**: None (frozen). Next: Chapter 7 preview (PDF pages 57–63); build its Carried-in Context from this file.
- **Reading Span**: PDF pages 43–56
- **Source Text**: /library/Spec Driven Development/Chapter-06-Requirement-Language-Writing-What-the-AI-Executes-Without/Chapter-06-source-text.md (read instead of PDF when needed; page 55 has no extracted text)
- **Full Record**: /library/Spec Driven Development/Chapter-06-Requirement-Language-Writing-What-the-AI-Executes-Without/Chapter-06-chapter-notes.md (read only if needed)
- **Last Updated**: 2026-10-01

## Carried-in Context (from earlier chapters)
- Ch1: Ködel's experience motivates the method but is not proof of broad effectiveness; reader wants to test it.
- Ch2: A specification sets a target for judging AI output; people still judge, decide, and answer. The 70/30 split is illustrative.
- Ch3: SDD = what/why, *FOCUS Architecture* = where rules live, *Context Engineering* = what the agent sees and at what cost. Reader expects cross-references to explain needed ideas in place.
- Ch4: The author combines specification direction with short feedback cycles and claims AI lowers code rewrite cost; no project-level measurement of total change cost. Reader said revised code must be tested against the spec.
- Ch5: A useful spec records purpose, scope, behavior, criteria, and edges, while technical choices belong in the plan. Reader distinguished scenario, rule, and criterion after feedback; their task-text rule required a non-whitespace character, but criterion said non-space, so wording was aligned to reject all-whitespace input, including tabs.
- Open cross-book thread: maintenance and information structure in *FOCUS Architecture* and *Context Engineering*; the stand-alone cross-reference promise is still being checked.

## This Chapter
- **Core Question**: How can a requirement sentence make its conditions, expected behavior, and check for correctness clear enough to guide a human or AI implementer?
- **Watch-For Themes**: Sentence precision; functional versus technical; EARS, Given/When/Then, Design by Contract, ATDD; starting state, triggers, invariants, negative guarantees; edit-task ambiguity.
- **Core Thesis**: Precise requirement sentences, concrete scenarios, explicit guarantees, and acceptance checks written before implementation reduce room for implementers to guess.
- **Key Concepts**: Functional versus technical; EARS trigger and obligation; Given/When/Then state/action/result; Design by Contract precondition/postcondition/invariant; ATDD prewritten feature check.
- **Notable Arguments / Evidence Limits**: To-do edit-task example: own unchanged title was counted as duplicate; prewritten description-only edit check caught it. Concrete example, not measured comparative evidence.
- **Action Item**: For one small feature, write an EARS-style rule and a Given/When/Then check before implementation; include one forbidden side effect and compare finished behavior with both.

## Reader State
- **Pending Questions**: None.
- **Reader's Answers (paraphrase)**: Functional describes observable behavior; technical describes construction. Correct persistence example; mistakenly labeled PostgreSQL storage functional. Gave EARS unique-title creation rule and Given/When/Then duplicate-title scenario. Correctly recalled invariant that task position and creation date stay unchanged during edit. Reader was unsure why description-only edits failed.
- **Misconceptions / Feedback Given**: PostgreSQL storage belongs in the technical plan. EARS and Given/When/Then examples should address the same case to compare them. Explained that a duplicate check against all tasks finds the task's own unchanged title and rejects description-only edits; compare other tasks only. A prewritten acceptance check catches this; position/date invariant is separate.
- **Personal Threads**: Reader may try their task-text mini-spec on empty, whitespace-only, and valid text; no Chapter 6 application selected.

## Open Threads
- Does sentence-level rigor prevent costly guessing in a real feature, and what costs remain?
- How does this chapter's example relate to the reader's non-whitespace/non-space wording gap?
- Which of the four approaches helps catch assumptions or unchanged behavior before implementation?