Copy that cannot ship without proof
Rasmus Kjær Damgaard, Founder ·
This article was produced with AI assistance and reviewed by a person. Rasmus Kjær Damgaard holds the editorial responsibility for the content.
TL;DR: Marketing claims drift from reality, and nobody notices until an auditor or a regulator does. On this site, a sentence that makes a factual claim about where data is processed, who can compel it, whether it crosses a border, or whether a model trained on it cannot be committed unless a machine-checked predicate backs it. This post explains the mechanism, shows three claims it currently refuses to let us make, names a real one it caught, and describes what it cannot prove.
The problem is drift, and the drift is a legal exposure
A claim on a vendor site is written once and then left alone. The fact under it moves: a sub-processor is added, a region changes, a certification lapses. The sentence stays. For months the page asserts something the company's own records already contradict, and the gap is invisible because the two live in different places, edited by different people.
For a European seller this is not only a credibility problem. Under the Unfair Commercial Practices Directive (2005/29/EC), Article 12, an authority may require a trader to prove a factual claim and may treat insufficient evidence as proof the claim is false. The burden sits with us, and no lawsuit is needed to trigger it. The EU AI Act adds a transparency duty of its own: Article 50(1) requires that a person is told when they are interacting with an AI system. A claim surface that overstates what a company can back is the exact shape both rules are written to catch.
The mechanism: claim, predicate, register, gate
The design is small. A registry binds each customer-facing claim to a predicate, and the predicate is evaluated against facts the copy cannot edit: the sub-processor register and the trust snapshot, both generated from source. Predicates are scoped by layer, because a phrase like "EU-hosted" is several claims in one: storage, the request path, and telemetry can each have a different answer, and conflating them is how a true statement about one becomes a false statement about another.
The gate, bun run check:claims, then enforces four things in one pass. A
claim whose predicate is false must not appear in the copy, in any language.
Any string that makes a residency-, jurisdiction-, transfer-, or
training-shaped promise must be declared, so the next absolute cannot be added
silently. No such claim may live outside the translatable message catalogue,
where it would escape every other check. And a claim corrected in English must
not stay live in the other 22 languages: the pipeline retranslates only when
someone runs it, so a fix applied to English alone would leave the old claim
standing in every other locale. That last check is the parity gate, and it is
the one most systems miss.
The final piece removes the authoring step entirely for the highest-risk slots. Rather than hand-writing a residency phrase into a meta description or a manifest and hoping a reviewer catches it, those slots take a token that resolves to a register-derived fragment, and the fragment renders only while its predicate holds. A sentence the register cannot back has no fragment to insert, so it cannot be typed. Detection catches one phrasing at a time; generation closes the whole class.
What it refuses
The clearest way to trust a gate is to watch it say no. Three claims are declared today that the register will not currently let us publish, and the gate reports each one blocked on every run:
- A claim that our terms forbidding model providers from training on customer content are contractually flowed down through every layer. We intend it; the register does not yet evidence it, so it stays unpublished.
- A claim that the platform already satisfies the whole of the EU AI Act. The corpus records a status per obligation, and not every one is met, so the totalising version is refused.
- A claim about the jurisdiction of the model supply chain, which needs a predicate about corporate incorporation rather than about where a request runs, and does not yet hold.
These are not oversights. They are claims we would like to make and do not, because the discipline is worth more than the sentence.
It has also caught a live one. On 2026-07-27 the gate landed (commit
3b7a4bffd), and within a day it forced a correction the review process had
missed: the landing hero asserted data residency with nothing in the register
behind it (commit a8d94d4a3), and the parity check then required carrying the
corrected wording into all 22 other languages rather than only English. The
claims that survived are the specific, checkable ones: generation runs in
France, embeddings in Berlin, documents in Ireland and Nuremberg, each shown on
the trust page with its transfer basis.
What it cannot prove, stated plainly
A gate that oversells itself is the thing it exists to prevent, so here is its boundary. It proves that every published claim matches the register. It does not prove the register describes the world correctly, though a separate gate holds the register to the code. It cannot verify that a benchmark figure is real or that a cited article number is the right one; those are matters of judgement a regular expression cannot reach. What it removes is the specific, recurring failure where a claim that was true at launch quietly becomes false and no one is watching the file. Getting the claim right in the first place is still a person's job.
How to do the same
The pattern transfers, and none of the parts are exotic. Keep a machine-readable register of the facts your claims depend on, generated from source rather than maintained by hand. Give each claim a predicate the register can refute, scoped narrowly enough that one subsystem's truth cannot stand in for another's. Run a pre-commit gate that evaluates every claim in every language you ship, and let a false predicate fail the build. Then, for the slots where a stray absolute does the most damage, generate the claim text from the register instead of typing it.
The result is not louder copy. It is copy an adversarial reader can check, which for a European buyer evaluating a security vendor is the only kind that converts.
Frequently asked questions
What does the claims gate actually check?
It reads every declared claim about the processing chain, evaluates its predicate against the sub-processor register and the trust snapshot, and fails the build if a claim whose predicate is false appears in the copy in any of the 23 languages. It runs as a pre-commit hook and again in CI.
Why check the register instead of just reviewing the copy?
A human review proves the state on the day it runs and nothing after it. The register is regenerated from source and gated in both directions, so binding the sentence to the register means the sentence cannot outlive the fact it rests on. When a vendor changes, the claim that depended on it fails on the next commit.
Does the gate prove our claims are true?
No, and it says so. It proves each published claim matches the register; it cannot verify that a benchmark number is real or that a cited article number is the correct one. Those stay human judgement. The gate removes the failure mode where a true-on-launch claim silently drifts false, not the need to get the claim right in the first place.
Can we reuse this pattern?
Yes. The parts are a machine-readable register of facts as the single source of truth, a predicate per claim that the register can refute, a pre-commit gate that evaluates every locale, and generation of the claim strings from the register rather than typing them by hand. Each part is small; the discipline is in wiring them together.