A format for recording what a team rejected and why, so a dead idea is never re-proposed. Written for small studios and anyone running AI agents on creative work, where the agent will cheerfully re-propose next month the thing you killed last month. It is a plain Markdown file — it works in Claude Code, Cursor, Codex, or a shared doc, and it requires no tooling.
By Anisha Dogra, co-founder of RAAY Creative. This format came out of watching the same rejected idea come back a third time, six weeks after it was killed, because nobody had written down that it was killed or why. Corrections and disagreements are welcome — open an issue before opening a pull request.
An agent has no memory of being told no. Neither, after about six weeks, does a team.
So the same treatment comes back. Someone proposes the caption style that was killed in June. Someone re-derives the transition that does not render. Someone rebuilds the mascot that the client called fake. Each re-proposal costs a full build cycle to reject a second time, and the rejection is never cheaper than the first one — it is more expensive, because now there is a finished thing to argue about.
Retros do not fix this. A retro produces prose, and prose gets buried. A style guide does not fix it either: a style guide says what to do, and the expensive failures are almost always about what not to do, in a form specific enough to recognise on sight.
What fixes it is a numbered, append-only table of every treatment ever proposed, with a verdict on each one, that gets read before anything is proposed.
A ledger row has four fields. That is the format.
| # | Treatment | Verdict | Note | Changed |
|---|---|---|---|---|
| 27 | Rendering the final output as soon as the automated checks pass | REJECTED | Green checks are not quality. The run that passed every check shipped at the wrong duration with no concept. Superseded by gate 9a. | |
| 29 | Iterating privately through several render versions before showing anything | REJECTED | 7 versions produced, none shown, final was wrong. Show version 1. | |
| 44 | Caption style: system sans, centred, drop shadow | REJECTED | "extremely horrible" | |
| 45 | Caption style: heavy grotesque 96px, tracking −2%, two-stop vertical gradient #FFFFFF → #C9C9C9, shadow 6% at 4px |
ACCEPTED | Reproducible spec. Use this unless the brief names another. | |
| 61 | x/y-tweening a circular path | REJECTED | A 132° sweep collapses the radius to 41% at the midpoint. Rotate a parent instead. | |
| 62 | Infinite repeat counts in the animation library | REJECTED | Will not render. The renderer never resolves the timeline. | |
| 75 | Model X for client video | REJECTED → LIFTED | "Use it, but ask me before every spend." Standing condition: per-spend approval. Historic line: never Model X. | LIFTED 2026-09-03 |
Rows 44 and 45 together are the point. A ledger of rejections alone teaches an agent what to avoid and leaves it to re-derive the winner from scratch every time. Row 45 is what makes the ledger a specification rather than a minefield map.
Row 75 is the second point. Nothing is ever deleted. The reversal is dated and the historic line stays visible, because a question that reversed once may reverse again, and a reader needs to know this ground is contested.
Print these at the top of any file that uses them. Without a stated taxonomy every line reads as equally binding, and the agent either treats preferences as blockers or blockers as preferences.
| Tag | Means |
|---|---|
REFUSE |
Never do this. Stop and ask. |
HARD |
Release-blocking. No exceptions without an explicit instruction from the person you work for. |
DEFAULT |
Do this unless the job says otherwise. |
TECHNIQUE |
The proven recipe. Follow it and you will not have to think. |
Four levels is the whole taxonomy. REFUSE should be numerically rare — see 2.2. In the ledger this repository is drawn from, 12 rules out of 293 lead with REFUSE.
| File | Read it when |
|---|---|
| rules/01-the-ledger.md | Always, before proposing anything. This is the format. |
| rules/02-severity.md | Writing or tagging a new rule |
| rules/03-precedence.md | Two rules or two documents disagree |
| rules/04-binding-it-to-the-work.md | The ledger exists but nobody opens it |
| rules/05-auditing-the-ledger.md | The ledger is old enough to be wrong about itself |
| rules/06-who-ships.md | Deciding who is allowed to press the irreversible button |
| TEMPLATE.md | Starting your own. Copy it, delete the comments, fill it in. |
| examples/worked-ledger.md | You want to see a filled-in one before committing |
| # | Rule | Tag |
|---|---|---|
| 1.1 | Keep one numbered, append-only table of every treatment ever proposed | HARD |
| 1.2 | Record what was accepted in the same table as what was rejected | HARD |
| 1.3 | Give every row four fields: treatment, verdict, note, date changed | HARD |
| 1.4 | Quote the person verbatim when the verdict was taste, not measurement | TECHNIQUE |
| 1.5 | Amend a reversed row in place; never delete it | HARD |
| 2.1 | Use four severity tags and print their definitions at the top of the file | HARD |
| 2.2 | Keep the top tier rare, and reserve it for identity and destruction | HARD |
| 3.1 | Publish one ordered precedence chain and close it | HARD |
| 3.2 | Say the divergence out loud; never reconcile it silently | HARD |
| 3.3 | Resolve a conflict by scoping both rules, not by deleting one | HARD |
| 3.4 | When a summary disagrees with the dated entry it came from, the dated entry wins | HARD |
| 4.1 | Make reading the ledger gate 1 of a numbered standing-gate list | HARD |
| 4.2 | Mirror the always-binding sections into the file that loads automatically | TECHNIQUE |
| 4.3 | End every job with a dated, job-tagged LESSON → next time |
HARD |
| 4.4 | Promote durable lessons out of the log and into the standing rules | HARD |
| 5.1 | Audit the ledger with several critics holding different mandates | HARD |
| 5.2 | Tag corrections in place with a date; never edit silently | HARD |
| 5.3 | Recount the ledger's own numbers on every audit | HARD |
| 5.4 | Treat a reviewer's note as a claim until you have checked it | HARD |
| 6.1 | Separate the thing that decides from the things that do | HARD |
| 6.2 | Make "show the draft and get a yes" its own numbered gate | HARD |
| 6.3 | Log every stage through a writer that is forbidden to fail | TECHNIQUE |
Two of the four severity tags do not appear above. Nothing in this repository is REFUSE — none of these rules is about identity integrity or destructive commands — and nothing is DEFAULT, because a rule about the ledger that you may skip when the job says so is not a rule about the ledger. That is 2.2 working as intended, and it is worth noticing rather than filling in.
- Copy TEMPLATE.md into wherever your agent already reads on every job — the file loaded by your agent config, or the top of your team handbook. If it is not loaded automatically, it will not be read.
- Paste in the severity block and the precedence chain, and edit the chain to name your actual authorities in order.
- Write the last ten things you rejected. Ten is enough to start. You will remember them; the specificity is the hard part, not the recall.
- Write the three things you accepted that you would hate to have re-derived — the spec versions, not the vibes versions.
- Number every row. From now on it is append-only.
- Add gate 1: read the ledger before proposing anything. Add the debrief: every job ends by appending one dated
LESSON → next timeline.
The ledger becomes useful somewhere around row 30, and load-bearing somewhere around row 80.
One studio, two people, roughly sixteen months of AI-assisted creative production — motion, static, and long-form deliverables for a handful of clients across food, industrial goods and travel. The ledger it describes holds 119 numbered rows accumulated between May 2026 and September 2026: 89 rejected, 29 accepted, 1 lifted. Alongside it sit 293 severity-tagged rules across 13 sections, 72 dated debrief entries spanning 13 distinct job ids, one adversarial critic pass that produced 14 in-place corrections, and three measured review-acceptance rates.
Honest limits:
- This is n=1. It is one studio's practice written down, not a survey. Every rule here is falsifiable by anyone whose ledger behaves differently.
- It is shaped by creative production, where the failure mode is plausible and wrong — output that passes every automated check and is still not the thing. Teams whose failure mode is broken rather than wrong will find §5 and §6 more relevant than §1.
- It has not been tested above two people. My guess is that 1.4 — verbatim quoting — gets harder as the team grows, because a quote that reads as decisive from a partner reads as a reprimand from a stranger. I have not run that experiment.
- The numbers above are counts from one document. 5.3 exists because I found that document lying about its own counts.
Rules I am not confident in, stated as such rather than smoothed over.
1.4, verbatim quoting. It works — a paraphrased taste ruling drifts back toward the rejected option within weeks. But quoting someone's sharpest sentence back at them, months later, in a document they did not expect to be quoted in, is a real social cost. If your ledger is read by clients or by people who did not write the quotes, consider quoting the ruling and attributing it to a role rather than a name.
2.2, keeping REFUSE rare. "Rare" is a judgement, not a threshold. Twelve out of 293 is what mine settled at. I cannot tell you whether that is the right ratio or just mine, and I would distrust anyone who gave you a number.
The ossification risk. A ledger that records taste rejections will, over time, make your work more consistent and less surprising. Row 44 said a caption style was horrible in June; if the client's taste moves in October, nothing in the format notices. 1.5 gives you the mechanism to reverse, but no rule here tells you when to go looking for reversals. I do not have a good answer for this.
Do not open a pull request first. Open an issue with the incident.
A rule is admitted only if it comes with a failure that actually happened — what was proposed, what shipped or nearly shipped, and what it cost. Without that, the entry cannot be audited later, and an unauditable entry is the thing rule 5.1 exists to catch. See CONTRIBUTING.md.
MIT. See LICENSE and the reasoning in CONTRIBUTING.md.