# From idea to briefs

Illustrative design walkthrough; proposed controls and pending decisions are labelled. Estimates use 140 words/minute; measured voice timings override them at render.

| id | On screen | narration |
|---|---|---|
| scene-01 | Green tests. Wrong answer. | Imagine asking an agent for a report showing which coding model offers the best value. It builds the report. The tests pass. But missing spend becomes zero, and abandoned attempts disappear. The cheapest model may simply have the least complete records. |
| scene-02 | Ambiguity changes hands | That mistake can begin before anyone writes code. Requirements leave best value undefined. Design chooses a default. Implementation follows it. Tests encode the same assumption. Review sees consistent code. An unanswered question has travelled through the development cycle and emerged looking like an agreed requirement. |
| scene-03 | Define the outcome | Our discussion about model cost exposed this problem. We needed to assess the brief as well as the worker. The specification would define cost per independently verified, accepted brief, including review, repairs and unsuccessful attempts. Missing cost stays unknown. Those decisions belong before the chart. |
| scene-04 | Six dimensions. Separate judgments. | The proposed brief assessment asks six separate questions. How much work? How complete is the specification? How difficult is the reasoning? Which components are coupled? How strong is the verification? What are the consequences of failure? These answers inform planning, model choice and review. One complexity score would hide the differences. |
| scene-05 | Record the ruling | A specification also exposes choices that an implementer should not settle by accident. Should acceptance review block dispatch, or begin in shadow mode? The proposal records alternatives. The responsible authority makes the ruling. Its source and affected specification revision remain visible. A recommendation is still pending until that happens. |
| scene-06 | Challenge success, early | Before implementation, a separate reviewer would challenge the definition of done. It first derives failure cases, then reads the author’s proposed checks. For this report: could missing cost look like zero? Could abandoned work vanish? A check that only confirms a file exists would accept the wrong result. |
| scene-07 | Plan the dependencies | The specification becomes a stream of briefs. Policy rulings precede the schema. Procedures and event records can then follow separate branches. Admission checks and outcomes feed the analysis, followed by a pilot. Explicit dependencies keep an unresolved decision from becoming somebody else’s implementation default. |
| scene-08 | Make the brief executable | Each brief gives one implementer the purpose, relevant facts, scope and dependencies. Verification names commands and expected results. The worker can now execute against a reviewable contract. Missing facts remain questions to resolve; they do not become permission to invent requirements. |
| scene-09 | Review. Then verify. | Acceptance review asks whether the contract could accept the wrong thing. Code review examines the implementation and its wider effects. After merge, a fresh non-implementer verifies the merged work against the brief. These are different questions. A passing local check still cannot establish an operational claim it never observed. |
| scene-10 | Keep the original contract | When a worker discovers a missing requirement, correcting the brief helps delivery. Preserve the original too. The proposal keeps authored, approved and completed snapshots, with reasons for amendments. Otherwise, a rescued brief looks indistinguishable from a good one, and the author’s next brief learns nothing. |
| scene-11 | Explain the outcome | The outcome report would separate brief omissions, implementation errors, environment problems and changed requirements. Uncertain attribution stays uncertain. Compare similar work, include the cost of review, and show missing evidence. The pilot must establish whether the extra process earns its place. |
| scene-12 | Start with one change | The draft specification and stream now exist. The new controls still need implementation and evaluation. You can start with one completed change: compare its original request, recorded decisions, initial acceptance criteria and final result. If only the final ticket survives, preserve the next brief before work begins. |

## Description

How Assay takes an idea through a specification, explicit decisions and rulings, and a dependency stream of executable briefs. Uses the proposed brief-quality design as an illustrative example. The draft spec and stream exist; new controls still need implementation and evaluation. Synthetic Australian Assay house narration.