Our marketing contract required every claim to carry a presentation role and a copy-ready flag. The generated ledgers carried neither, so internal task instructions were being classified as public marketing claims.
The governance layer was the most careful part of this system. A claim contract with a suitability
classification, a presentation-role vocabulary, a verbatim-copy gate, three proof tiers, a
no-evidence-no-claim rule, and a review checklist. It reads like something written by someone who has
seen a marketing system fail.
Then we generated a campaign against it and produced a ledger with none of it.
Every item in claims[] was required to carry candidate_class, channel_eligible,
presentation_role, copy_ready, risk_flags, proof_tier, and evidence_paths. The contract was
explicit about why the last three matter: presentation_role answers how a claim may be used,
copy_ready answers whether it may appear verbatim in public-facing prose, and evidence-backed
implementation breadcrumbs may be channel-eligible as support without being copy-ready.
That is a good design. It separates two questions people normally conflate — is this claim *true and
relevant*, and may I print it — and it lets a ledger be auditable without being publishable.
Counting the required fields in a generated ledger returns nothing:
$ grep -c "presentation_role\|copy_ready" evidence-ledger.json
0
Zero. Not "wrong values." The fields are absent. Which means the gate that was supposed to decide
what could reach a reader was not running, and every claim that reached the channel renderer was
treated as printable.
The channel variant for the website carries these four lines under "Claims Referenced":
- [implemented] **Depends on**: ADR-020 (Guardian Mediated Coding Agent Execution Contract)
- [implemented] 1. Define the coding-task envelope schema
- [implemented] 3. Wire into existing Guardian queue infrastructure
- [implemented] ADR-020 defines Guardian as identity/persistence owner
"1. Define the coding-task envelope schema" is a task instruction. It is not a claim about a product
capability; it is a line from a checklist. It was classified marketable_claim with
channel_eligible: true, and it was rendered into the website and social variants. The same block
appears in channel-social.md, channel-community.md, and ad-copy.md.
Meanwhile the brand constitution was explicit: capabilities must be backed by campaign receipts or
proof artifacts, and product language should reduce ambiguity rather than inflate aspiration. An
internal task line rendered as a marketing claim does the opposite of both.
Nothing here was catastrophic. The output was draft-only, human approval was required before publish,
and the artifacts never shipped. We caught it because we went looking.
But consider what happens when this system is pointed at a set of publications instead of one site.
A ledger that cannot tell a task instruction from a claim, in a pipeline that emits the same claims
regardless of what changed, across many addresses, is not a marketing system. It is a content
factory with a publish button. The governance that was supposed to make it safe was the thing that
was not running.
The contract was already right. The fix was to implement the fields it specified — classify each
claim's suitability, assign its presentation role, compute copy_ready, and have the channel
renderers consume only public_copy_seed items with copy_ready: true. The specification had been
written before the generator was written. The generator simply did not implement it, and nothing
failed loudly when it didn't, because a missing field is not a type error in a JSON blob.
The durable lesson is not about the fields. It is that a written contract is worth nothing until
something fails when the code stops honouring it. A schema check on the ledger — asserting that every
claims[] entry carries the full field set — would have caught this on the first campaign run,
before anything was published anywhere.
Governance that cannot fail is not governance. It is documentation.