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.

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.

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.

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?