# What it takes to write down every claim a company stands behind

**One company wrote down 26 claims it stands behind in 60–90 minutes, with a named owner against every one.** The person who filled it in reported nothing a buyer would challenge; a second reader found four lines in ten minutes.

The second half of that is the finding. The exposure was not in the claims somebody was worried about — it was in the ones nobody was.

## Why run this at all

Reynforce asks a company to put the claims it stands behind in one place, each with an owner and a date it was last confirmed, so that an agent answering in the company's name reads them instead of inventing them. Everything after that rests on it being an afternoon's work rather than a quarter's, which is worth measuring before selling it rather than after.

## How it was done

<!-- method:start — generated by website/build.py; do not hand-edit -->
- **What was asked for** — “Thirty true statements about a real product, with an owner and a date against each. One afternoon.”
- **When it was run** — “Run: September 2026.”
- **The rule about looking things up** — “Don't look anything up until you've tried.”
- **The rule about owners** — “Name a real owner or leave it blank.”
- **The rule about the clock** — “Time yourself. Note when you start and when you stop.”
<!-- method:end — generated by website/build.py; do not hand-edit -->

Every figure on this page is quoted from the written protocol or from the record of the run, and the page is generated from those two documents rather than typed. A number here that cannot be traced to one of them fails our own build.

The filled-in sheet itself is not published: it describes a real company's product and commercial terms, and publishing those to make a point about exposure would be the thing this page is about.

## What came back

<!-- result:start — generated by website/build.py; do not hand-edit -->
- **What came back** — “26 rows, 60–90 minutes, an owner on every row, no dates guessed.”
- **Who owns the rows** — “Seven named roles own the 26 rows, one of them seven rows alone, all on 90-day intervals.”
- **Whether the intervals were thought about** — “The question of how fast each line actually goes out of date wasn't really asked.”
- **Where the dates came from** — “Rows sourced from the same document share one date”
- **What the evidence pointed at** — “Five rows cited the GTM messaging as their evidence”
- **What a second reader found** — “A second reading found four in ten minutes”
<!-- result:end — generated by website/build.py; do not hand-edit -->

**Dates came from documents, not from checks.** Rows taken from the same contract or pack all carried that document's revision date, which is not the day each statement was last confirmed true. That is convenient for drafting a register automatically, and it is also exactly the gap a register exists to close.

**Several rows were two or more claims in one.** One carried four conditions; another held two figures that go out of date at different speeds. An agent can be half right about a line like that, which is why proposing a claim has to split it first.

## The lines nobody flagged

The person who wrote the sheet was asked whether any row would trouble them if a buyer pressed on it, and said none would. A second reader, ten minutes later, had four:

- **A certification that belonged to a supplier**, read as though it covered the company. The certification category held none of the company's own — the first thing a procurement team asks for.
- **Two absolutes** — "all" standards met, data "never" lost. An absolute leaves no room for the exception that eventually arrives.
- **A roadmap commitment with no year on it**, confirmed in the closing month of the quarter it named. Wrong within days if it slipped.

None of those needed a detector to find. They needed somebody who was not the author reading the list — which is what a register with an owner and a date on every line gives a company every day rather than once.

## What it does not show

<!-- limits:start — generated by website/build.py; do not hand-edit -->
- **The company** — “The product was a tech-enabled services company (outsourced SDR)”
- **The person filling it in** — “The person filling it in knew every answer.”
- **The measurement column** — “`how_hard` was left blank and reported afterwards.”
- **What nobody was asked** — “None of them was asked.”
<!-- limits:end — generated by website/build.py; do not hand-edit -->

**And the half nobody has answered.** Producing a register took an afternoon. Whether the owners keep re-confirming their lines on the interval they set is the part that decides whether a register stays true, and none of them has been asked. That is said here rather than left until somebody asks.

## What changed because of it

Proposing a claim well turned out to matter more than making a register easier to fill in: splitting a compound line, flagging an absolute, flagging a roadmap item with no date, and telling a document's date apart from a check's date. All four came out of this run.

## The next run

A software company rather than a services one, with the difficulty column scored as the sheet is filled rather than recalled afterwards, and one owner asked outright whether they would re-confirm their lines on the interval they chose.
