The contract you write before you build.

Why this exists

When a builder ships work that doesn't land, the reflex is to build again, faster. The reflex misses the same way. Or: you ship work, the work lands, and somehow nobody on the recipient side notices it landed. Both shapes are the build trap — one is a clarity failure (you cannot say what was supposed to change), the other is a falsifier failure (you shipped without a way to prove a stranger could check the change happened).

Keep a Value puts three questions and a six-part gate in front of the reflex. It is modeled on Keep a Changelog: same shape (a file at the project root, a stable format, a small set of rules), different job. A changelog records what shipped. A VALUE.md records what was supposed to change for the recipient when it did.

The three questions

The six-part gate

Before you build, your VALUE.md must pass the Q0 grounding precondition AND all six checks below.

1. No hedge-words.No "maybe," "kind of," "ish."
2. A stranger gets it.Hand the three sentences to someone with no context; they can paraphrase them back.
3. Reads aloud without footnotes.No silent caveats. The sentences stand alone.
4. One recipient across all three sentences.No drift between who in Q1, Q2, Q3.
5. Subject test.Every promise's subject is your behavior, not the recipient's or a third party's. You can only promise what you control.
6. You named what you don't break.For your headline outcome, name one thing that could get worse if you optimize hard for it.

Any one fails — you're not ready to build. All six pass — go build.

How this standard was built

The standard was not designed in one sitting and shipped. It was written, applied to twelve real projects in the author's workspace, then put under adversarial pressure — two retrospective field studies, ten rounds of cold-read LLM critique on the standard's own text, and five rounds of user-scenario stranger tests in which language models played specific stuck-builder roles and walked through the live site.

Each round produced findings; an editorial pass decided which to apply and which to skip with a reason that lasts. The recurring-skip ledger is itself part of the record, because the same rejected findings recur until the doctrine answers them once. Five iterations refined the opening paragraph (which used to leave a whole class of users feeling unseen), the gate's structure (which used to stutter mid-page), the recipient-grounding rule (which had a quiet hole platform teams could pass through), and the Stranger Check Card (which used to read as paperwork instead of an action).

The standard's own field-evidence summary, the case studies, the synthesis pages from every round, and the harness that ran them are all in the research/ folder on GitHub.

What the strangers said

Cold-read LLM strangers were placed in three explicit scenarios: a B2B SaaS founder at her kitchen table with two churn tickets that week, a staff engineer the Sunday after a six-month platform migration that nobody on the product side noticed, and a nonprofit director on a Tuesday morning with a fundraising speech in three weeks. After five iterations:

Neither stranger declared the page perfect; both named specific friction that remained, and that friction was logged honestly. Both said they would use the standard this week with a specific named plan. The full responses, the iteration-by-iteration synthesis, and what we applied and skipped at each step are in user-scenarios-iter5/synthesis.md.

Start here

You're a builder. You want one of these things:

• Write a VALUE.md for your project · Runbook + Skeleton60-second test plus a fillable template
• Worked example · Fundraising speechA 12-minute donor talk, end to end
• Worked example · Publication submissionWriting for a trade editor's slot
• Worked example · Pinpoint (software)Incident-triage for on-call
• Worked example · This index pageThe page applied to itself
• Read the standard · Standard.mdThe full doctrine, ~10 min read
• Learn the format · Template.mdThe annotated teacher — read once
• Run a stranger test · stranger-test-prompt.mdA prompt to paste into any LLM

Where this comes from

Keep a Value is a distillation, not an invention. The load-bearing borrows are Promise Theory (Burgess 2005) for the subject test, Donabedian's triad (1966) for the feelings-need-a-proxy rule, the pre-mortem (Klein 2007) for "what we don't break," and the self-explanation effect (Chi et al. 1989) for the Value Statement Test. Full lineage with primary-source citations in lineage.md.

Status of the standard itself Proposed

Pre-1.0. Applied to 12 real projects in the author's workspace; two retrospective field studies have been published (case study 01, case study 02). They confirm that adopters write to the standard's format. They do not confirm that VALUE.md builders outperform description-only builders on recipient-accepted outcomes — that requires the paired-run test, which has not yet been run.

Open gap. All twelve case studies are self-application by one builder. Whether the standard produces the same result for a builder who is not its author has not yet been tested. The cross-builder pilot is scaffolded in research/experiments/paired-runs; recruitment is open.

License

Triple license in a single LICENSE file:

• Doctrine (Standard, Runbook, README, Changelog, Lineage) is locked under CC BY-ND 4.0. Share with attribution. Do not modify.
• Working surface (Template, Skeleton) is open under CC BY 4.0. Fork, translate, adapt — with attribution.
• Code (Makefile and any future tooling) is open under MIT.

"Keep a Value" and "Value Statement Test" are common-law trademarks of Natan Dahan. No CC license grants trademark rights.