Start here · Walkthrough · Open the demo

A review conclusion that changes when the evidence does, and says why

Records about a figure keep arriving for weeks after it is published: a correction, an explanation, a reviewer's decision, a withdrawal. This system re-checks the conclusion as each one lands and records why the answer changed. Every number on the screen opens to the cell or sentence it came from.

Three demos, fifteen minutes. None of them is a product. Each is the smallest case we could build that shows the idea, and we are showing them to you for the questions at the end.

Open fixture: invented records, six steps → A reported total under review. It adds up. Then a summary arrives that cannot be checked, a reviewer settles it, a desk corrects its number so the parts no longer add up, and the support is withdrawn. Every state the system can reach, in order. Five minutes. Open fac: real filed records → Single-audit reports filed with the U.S. Federal Audit Clearinghouse: 529 submissions, 218 auditees, three audit years. Nobody here wrote a word of them. Three minutes. Open jpm2012q1: one quarter of one bank's filings → Twelve claims on a board. Each one has a source, a date, a rule that checks it, and a tripwire that says what would break it. A figure is published without saying how it was computed, explained by the company on its own earnings call, and closed by a reviewer. Nine months later an investigation publishes records the company wrote before that decision, and one cell turns red. Real SEC filings, unaltered. Five minutes. Open flg2024: one regional bank's 2024 filings, in order → Five years of one bank's filings are read first. Its 2024 filings then arrive one at a time, and after each one the system says what no longer agrees with what the bank said before. It reads only the bank's own filings. At the end, the SEC staff's letter to the bank is shown beside what the system had already raised — a letter the system never saw. Six minutes. Open rb-wal: the bank it had most to say about → One of twenty banks run without anybody knowing which of them a regulator had written to, picked by a public rule — the most raised of the twenty. We have not looked at whether the SEC wrote to this bank, and the screen does not say either way. Open rb-rrbi: and the one it had least → The other end of the same rule, from the same twenty: the fewest raised. Most of its beats say that everything still agrees. ⚠️ A quiet screen is a result, not a failure — and it is not evidence that nothing was ever wrong.

The bank screens above use the new layout. The previous one is still here: flg2024 · rb-wal · rb-rrbi (old view).

About the third demo. It uses the real, unaltered public filings of a named company for a quarter in 2012 that some readers will recognise. It reports what the filed record says and when. It says nothing about why any figure changed, nothing about conduct and nothing about any person. The investigations and enforcement actions that followed are not among the documents it reads, on purpose. If it read them, anything it reported would be the investigators' work repeated back.

A case is a self-contained set of records, rules and keys. Cases share code and nothing else. A story is one sequence of events inside a case. The picker in the demo names both: case · story.

Every demonstration built here

Start with the three above. The list below is everything this server has. Any demonstration can also be opened as a sealed scenario: the same records with one of them altered by someone trying to make the conclusion wrong, and the key to what they changed published beside it.

⚠️ Scored rounds. A round is a case with something deliberately injected into it, opened only after it was scored. It shows what the system concluded, and what that conclusion turned out to rest on.

What it is for

Someone downstream, such as a reviewer, an analyst or a pass-through entity, has to decide whether a stated figure or a filed record still holds given everything that has arrived since. Most of that work is reconciling: finding the records that bear on the question, seeing which have been superseded or withdrawn, and being able to show afterwards why the answer was what it was.

This system does the reconciling and leaves the judgement to a person. What it produces is a traced conclusion: the answer, the records it rests on, and what it could not check.

Three answers that usually share one alert

Most review tools raise the same alert whether the evidence contradicts a figure, is missing, or has been withdrawn. Here those are separate answers:

on screen	means
supported	the evidence backs it
conflicting	the evidence contradicts it. This is a real discrepancy.
insufficient evidence	it cannot be checked, and the system names the missing piece. The figure could still be right or wrong.
unassessable	it could be checked before and cannot now, because evidence was withdrawn. It does not mean the problem went away.
reopened	a question a reviewer had already settled is open again

What you can check on screen

Every figure traces. Click a locator and it opens the cell in a file or the sentence in a document that the figure came from.
Earlier steps are replayed. Step back and you see what was known at that date, re-queried from what had been recorded by then. It is not today's answer with the later dates filtered out.
Abstentions are printed. The panel lists the checks that ran and found nothing, and the kinds of problem that no check covers.
A reviewer's decision stays a decision. It is recorded with its author and time. It is never merged into the data, and never inferred from a document.
Common questions are answered on the page, under the evidence. Open “What am I looking at?”, “What changed at this step?” or “Which records is this based on?” and each answer lists what it is based on.

How the question card works

Under the evidence on every step is a short list of questions people ask about the screen.

The answers were written before you arrived. Nothing on this page calls a model while you are looking at it. The answers were generated offline, and the server has no key to call a model with.
Every answer was checked before it was stored. Every figure in it had to be in the record already, and every source it cites had to be on that screen at that date. An answer that fails the check is kept with the reason and never displayed, which is why some steps list fewer questions than others.
Some questions are refused on purpose. Ask whether someone did something wrong, who is responsible, or what you should do, and the answer declines and says why. Those questions are outside what this system is allowed to conclude, and the check rejects any answer to them that does not refuse.
A refusal still says what is there. Ask “Is this the same problem as last year?” on the second demo. It declines to judge recurrence, then tells you how many pairs of findings have been put side by side for a person to read.

The questions are a fixed list for each demonstration. There is no box to type into. Sending a stranger's typed question from a public page to a model carries different risks, and this build does not do it.

What it does not do

It does not scan a corpus and surface problems. It checks declared rules against a named question. A scan would imply an accuracy nobody has measured.
It makes no performance claim. Every score so far was measured on problems the builder planted, in rounds the builder ran. The scorecard says so for each round, and none of them counts toward a claim.
It never characterises. “Fraud”, “error by” and any statement of intent are kept out of the data, the generated prose and the vocabulary.
It has no access control. Everyone who can reach this page sees every record in it. Permissions are a separate build.

Finding and observation

In a single audit, a finding is a term of art: a formal, numbered item signed by a licensed auditor. This system calls what it produces an observation, everywhere, so the two are never read as the same thing. The second demo uses both words, with different meanings.

“Observation” also fits because about half of what the system emits is “I can't check this”. Conflict, anomaly or inconsistency would each assert a problem where the system is saying it cannot tell.

Where the records come from

Demo 1	Invented. A fictional institution with made-up desks and numbers, written by hand so you can see exactly what the system is asked to do. Real public company filings sit behind it only to show that the ingestion path works on real files. No figure under review comes from them.
Demo 2	Real and public. Single audits under 2 CFR 200 Subpart F, filed with the Federal Audit Clearinghouse and in the public domain. Stored unaltered, with a hash manifest. Personal names, phone numbers and email addresses are removed before anything reads the text.

No login, no access control, no zoning. Every viewer sees every record, which is why this link stays inside the company. The server is read-only and refuses every write, so nothing you click changes what anyone else sees. The reviewer controls run from a separate command, which is not running here.