How to specify something whose output is different every time. The pixel spec and the acceptance criterion both stop working, and what replaces them is a behaviour contract, a rubric, and a set of examples that doubles as the eval set.
| # | Lesson | The question it answers |
|---|---|---|
| 01 | Why a Pixel Spec Fails | How do you specify behaviour when the output is different every time? |
| 02 | The Behaviour Contract | Must, must never, should, may: how do you write one? |
| 03 | Writing the Rubric | How does quality get defined before it can be measured? |
| 04 | Golden Examples and Counter Examples | How does the spec become a dataset? |
| 05 | The Prompt Is the Spec | Who owns it, who reviews it, and how is it versioned? |
| 06 | The AI Requirements Document | What does the document actually look like now? |
| 07 | Specifying Tone and Style | How do you write down something nobody can define? |
| 08 | Specifying What It Must Refuse | How do you describe the boundary without listing every case? |
| 09 | Specifying Failure Behaviour | What should it do when it does not know? |
| 10 | Acceptance Criteria as Pass Rates | How does definition of done change shape? |
| 11 | Reviewing a Spec You Cannot Test by Reading | What does a good review of this document look like? |
| 12 | Worked: A Behaviour Contract | One real feature, specified end to end |