Checking claims before they ship

You have a filled-in BV-01 and a draft script. Something still has to sit between them, and this section is what.

The mechanics are already built. claim-guard — in Module 2's skills folder — runs this check for you, with defined scan scope and three finding buckets. This section does not repeat it. It teaches the discipline the skill automates, so that you can do it without the skill, spot when the skill is wrong, and know what its findings actually mean.

That order matters. A check you have never performed by hand is a check you cannot supervise.

1The one rule

Every claim traces to a source before it ships: the client's barred list, the client's off-limits list, or your own record of what you actually did.

A claim with no source is not probably fine. It is unsourced, and unsourced is a finding.

The distinction that does the work here is between wrong and unsourced. You usually cannot tell whether a claim is false. You can always tell whether it is sourced. Chasing the first is impossible; chasing the second is a five-minute job with a definite end.

2The three kinds of finding

claim-guard sorts findings into three buckets, and the sorting is the useful part — they carry different consequences and a merged list gets triaged as one thing.

On FLAGGED: accepting is allowed. Accepting without noticing is not. That is the whole difference between a judgement and an accident, and it is why findings get written down even when you overrule them.

3The four checks, and which ones a machine can't do

1. Off-limits vocabulary. Literal string match against BV-3. A machine does this better than you — it doesn't get tired at 11pm and it doesn't skim.

2. Barred claims — the literal pass. Also mechanical.

3. Barred claims — the semantic pass. Does any line assert or imply a barred claim in different words? A ban on permanence claims is broken by "you'll never scrape again" as surely as by the banned phrase. This is where the machine gets weaker and you get more necessary. The intake tool says as much about its own checker: it cannot catch "tone, implication, or a claim phrased three different ways."

4. Claim-to-experience trace. Every factual claim about the product or your use of it, matched against your own written record of what happened. Anything without a supporting line is UNSUPPORTED.

The one a machine genuinely cannot do

A claim made by structure rather than by words.

The clearest example is in Module 2's demo runs. A problem–solution script shows the problem, shows it again next morning, then resolves it. Read as a sequence, the piece asserts that this is now how every morning goes — a durability claim made by editing, not by language. No vocabulary scan will ever catch that, because there is no word to catch.

Four weeks of recorded use supports has kept happening. Nothing supports will keep happening. Whether that gap matters is a judgement, and the judgement is yours.

4Why you keep a record of what you actually did

The claim-to-experience trace needs something to trace to. That is a second file, per client, alongside BV-01: what you actually did with the product.

Before, what changed, what's still not great — and, importantly, an explicit list of what you did not record. "How long it takes to heat. I never timed it."

That last part looks like bureaucracy and is the most valuable thing in the file. In Module 2's demo runs, a generated script confidently included "about ninety seconds of cooking." Ninety seconds is a plausible time to cook two eggs. It was also never measured, and the only reason the claim was caught is that the file said so in writing.

Write down what you don't know. It is the only defence against a plausible number.

5What this looks like in practice

Ten minutes per script, most of it mechanical:

1. Run claim-guard, or do the four checks by hand.
2. Read the findings by bucket. BLOCKED first — those aren't decisions.
3. For UNSUPPORTED: get the line or cut the claim. Do not retro-fit your experience file to justify something you already wrote. That is the one edit that is always wrong, and Module 2's demo run 01 records it being declined.
4. For FLAGGED: decide, and write down what you decided.
5. Check the surfaces that aren't the script — caption, on-screen text, cover frame, pinned comment. Clients read all of them.
6. Ask what else carries the same claim. If this script came from a template or a batch, its siblings probably say it too.

6And when you can't check

Say so. "I could check three of five things, here are the two I couldn't" is a useful report. A clean bill of health that quietly skipped the checks it lacked inputs for is worse than no check at all, because it will be believed.

With BV-3's barred-claims list empty, the honest output is UNCHECKED — no barred-claims list on file. Not "no issues found." Those are different statements and only one of them is true.

Module 4 takes this further, from not shipping something false to showing your work in a way that survives scrutiny. This section is the floor; that one is the standard.