Answer checks

What gets checked

Four checks read each answer beside the queries it ran and the rows they returned. They ask:

Data supports the answer

Does the data returned support what was said?

Right population and period

Is the population right?

Right source

Was the right table read?

Filters behave as assumed

Do the filters do what the answer assumes?

Each problem comes back named, for example: “this filter is on a nullable column, so it silently dropped rows.”

Other checks confirm the work behind the answer: the estate was queried, rows came back, and the approved findings for those tables reached the answer.

Estate knowledge

Some facts about your estate never show in a query: this view under-counts members, this table carries two feeds, this column is derived and does not reconcile. When a person approves one, it attaches to its table in the knowledge layer. Answers that read the table carry it, and the checks read it.

How a finding is added

1. 01A number looks wrong

   Someone gets a number that looks wrong and finds out why.

2. 02It becomes a proposal

   What they found is proposed as a finding about the table.

3. 03A person approves it

   Someone on your team reviews the proposal and approves it.

4. 04It attaches to the table

   It joins the knowledge layer, where every later answer that reads the table carries it.

Receipts

Every answer carries its receipts:

• Queries run
• Rows returned
• Sources read
• What was checked, and what could not be

A recipe can re-check an approved finding against the source on a schedule.

How the checks think

No overall score

We built one, and it could not be read: a clear pass and a clear fail could land on the same number. You get counts and named problems instead.

Wording is the threshold

Each outcome is a plainly written situation, and the verdict is whichever one fits.

Three outcomes

Met, worth a look, and unmet. Collapsing them to two flagged every correct answer we tested.

Couldn’t check

Its own state. A check that could not run says so; it is never counted as zero and never left silent.

Facts apart from verdicts

What the data shows is kept separate from the judgment made about it.

Never “correct”

It never says an answer is correct. The strongest result is “no problems found,” with the number of checks that ran.

Every judgment on record

Each judgment carries the model that made it and a hash of the question wording.

You see the spread

Each verdict shows the weight the check gave all three outcomes. A check at 55 / 35 / 10 and one at 90 / 8 / 2 reach the same verdict with very different certainty.

Why estate knowledge matters

A model reads the query, so it can catch the errors a query shows. It cannot see what only your estate knows, such as a table that carries two feeds or a view that runs short. That is a knowledge problem, not a model problem, and approved findings are how that knowledge reaches the answer.

What you get

• You know which answers to act on before anyone acts on a wrong number.
• Every answer is defensible, with its receipts.
• Each approved finding reaches every later answer that reads its table.
• It is honest about its limits, which is why “no problems found” means something.