Teams you run on your own work
- A writer and a reviewer. One model writes the files your brief names and a model from a different family reads them. Your test command runs in between. A rejection sends the work back once.
- A review panel with a threshold. One model implements, several review at the same time, and the change passes when enough of them accept. Every seat is a different model family.
- Feature delivery. Nine stages: research and a plan, each reviewed; tests before code; an implementation that runs again with the reviewers’ findings; a person’s decision; evidence. Work goes back to the stage that owns it.
desc sentence
saying what it does and a gate sentence saying what must be true for it
to count, and both reach the reviewer’s input and the run record.
Teams outside a software change
The same form, for the work most teams do that is not a pull request. Each file is built to stop at a person, so nothing is sent or filed without one; each is a complete file with its brief and sample inputs beside it underexamples/use-cases/.
Each page carries one real run. Two reached their person. The third stopped
earlier, when its reviewer sent the work back a third time and the loop ran
out of attempts rather than pass on stories nobody had agreed.
Software and product engineering:
- Backlog grooming, then a person ranks. Raw tickets become stories with acceptance checks and the questions to settle first, each read by a second model; the product owner ranks.
- A contract against a playbook. Every clause mapped to accept, push back or never, the redlines written from the playbook’s own wording, a negotiating note saying what to hold and what to concede; the lawyer decides what goes back.
- Translate, then reflect on the translation. An article rendered into French against a glossary, then a terms table saying where the glossary and natural French pulled apart; a person publishes.
Mechanisms shown one at a time
These files run offline against the public packages and nothing else.- Three candidates, one winner. Three isolated attempts at one task, a deterministic judge, the winner lands and the losers leave nothing behind.
- A command decides the path. The tests run as a node with no inference; a red run goes straight back to the writer with the output attached, and a second command’s exit code chooses which review runs next.
- A person decides. A question to a person as a step: a no goes back to the writer with the note as the finding, a yes passes, and with nobody answering the run pauses and carries on from the answer.
- A review that sends work back. A reviewer rejects the first draft with a reason and the second draft passes.
- A file change approved byte for byte. Source records are captured, every mapping checked, exact output bytes approved, each target backed up before a merge, and a mismatch pauses the run.
- A feature from written issue to approval. One issue through analysis, implementation, a real test run, a review panel, a bounded repair, and an approval bound to the exact bytes.
- Shipping a reviewed change through GitHub. Push the branch, open one pull request, pass a strict gate on the exact head revision, squash the merge, delete the branch.