Who decides which figure is right

Companies quote different numbers for the same thing. A warranty is 24 months in one deck and 18 in another. A data retention period is 120 days in a policy and 90 in a contract. This post is about what the Verify demo does once that disagreement is on screen: who picks a figure, what happens to the others, and how a draft gets checked afterwards.

What is real in the demo

The demo company is Halden Flowworks. It is fictional, and so are its people, products and numbers. A script with a fixed seed generates the documents. The conflicts are planted: the claim list is written by hand, with each value and how many documents quote it. The README says it plainly: the facts are provided, not extracted by a model. The demo's own sidebar says "Synthetic, no model, no network."

So the demo does not find conflicts by reading documents. It shows the work that comes after they are found, and that part is real code.

A claim has a state

Every claim sits in one of five states: unsourced (stated, never approved), proposed (a person put one figure forward), approved (the one figure to quote), conflicting (several values, none approved), and retired. The code calls the fourth one "contested". We renamed it in the interface because "conflicting" is what people say.

Approving a figure

Approval is a function that refuses to run without a named approver. The value must be one of the figures documents actually quote. It also takes a scope, which defaults to "All customers", and a review date, which defaults to 182 days from today. When it runs, every other value of that claim becomes a deviation, and the history line says so: who approved it, what, in which scope, and that every other figure now deviates.

Proposing comes first if you want it. A proposal marks one figure without settling anything, and it refuses to run on a claim that is already approved or retired. Reopening an approved claim sends it back to conflicting if it has more than one value.

Two limits. The approver is picked from a list of six invented names, not from a login. And nothing is saved: decisions live in memory, and a page reload clears them. What we wanted to test was the order of events, and that a person has to be named.

Checking a draft

The check screen takes pasted text. The code splits it into sentences. For each claim it looks for the claim's terms in the sentence and then for a number pattern. Where a number sits near a term, the nearest term wins. Each figure gets one of three verdicts. Approved means it matches the approved value. Deviates means the claim has an approved value and this is not it. Unsourced means the claim has no approved value yet, because it is still conflicting, proposed or retired.

In the sample draft, the warranty is 24 months and the approved figure is 18. The retention period is 120 days and the approved figure is 90. Both come back as deviations, with the approver, the date and the documents behind the approved value. The screen's count reads 3 approved, 2 deviates, 1 unsourced. You can copy the result as markdown.

The matching is regular expressions written per claim, so it only knows the claims in the demo. It does not read arbitrary documents. The page says nothing leaves it, and in the code nothing does: there is no network call in this path.

Why a person

When two documents disagree, the newer one is not always right, and neither is the one more people quote. The demo never picks. It gives a named person the evidence, records the choice with a scope and a review date, and then treats every other value as a deviation. Checking drafts against that list is the dull part, and it works because someone made the decision once.