Skip to content
AnantCausal
AI & model governance

Which of these numbers was an assumption?

A model in production is a mixture of elicited judgment, expert assertion and fitted counts. Once they are averaged into one score, nothing downstream can separate them again — and the separation is the governance question.

The problem

The problem

Governance over a model usually means knowing what it is, who owns it, and when it was last reviewed. That is registry-level assurance, and it is necessary. It does not answer the question a reviewer asks when the model's output is challenged: which parts of this were measured, and which parts were somebody's judgment.

The distinction is not academic. A number fitted from ten thousand rows and a number asserted in a workshop are different kinds of claim. Averaged together they become one claim that is stronger than either — the guess borrows the credibility of the count.

Where a language model is in the loop, this gets worse rather than better, because generated values are fluent, confident, and indistinguishable from elicited ones unless the system records which is which.

What it does

What the product does about it

Three capabilities, all of them about keeping two kinds of claim distinguishable rather than about making either one better.

  1. 01

    Provenance on every row, not on the model

    Each probability row carries its source — elicited, expert, fitted, or mixed — and the tag survives into every answer computed from it. Provenance at the model level could not support this, because the average of three kinds of support is the one thing none of them is.

    What this does not establish: The tag records where a number came from, not how good it is. An elicited value from a careful workshop and one from a hurried meeting carry the same tag, which is a real limit and the reason the tag is a floor rather than a guarantee.

  2. 02

    Ask the calibrated-only question explicitly

    Project the model to the largest sub-network where every row is backed by a fit, and answer from that. A result computed from calibrated tables only is a narrower claim than one computed from the whole model, and it is worth having as a separate result rather than as a footnote on the first.

    What this does not establish: The projection is smaller than the model and usually answers a less interesting question — that is the cost of the guarantee, not a defect. Where the fitted rows do not cover the decision, the calibrated-only answer is unavailable rather than reassuring.

  3. 03

    Keep estimation and elicitation in separate response shapes

    External estimator fits are queued and returned through their own endpoints, with their own fields — estimator, version, sample size, interval, assumptions — rather than being folded into the causal result. A doubly-robust estimate and an exact elimination result are different claims, and behind one values field they become indistinguishable to the consumer that reads it.

    What this does not establish: The estimator integration is a separate, narrower surface than the causal engine, and it is deliberately not the default path. Where a customer wants a causal forest, the answer is the handoff to a stack they already run rather than a bundled one.

Said plainly

When not to buy this

If the model is fitted from data by a team that already tracks its training data, versions and validation, this adds a governance layer over a different layer and the honest answer is that you may not need it. And if the assurance requirement is satisfied by a registry entry, this is considerably more than that, at a cost that only repays when somebody has to defend a specific number.

The record

What the record keeps

The distinction that a registry record cannot hold: which parts of a model were measured, which were asserted, and what a human changed by hand.

  • The provenance tag on every probability row, and the sub-network it makes available
  • Each manual override as an event, with the value it replaced
  • The refutation results per effect, including the inconclusive ones
  • The refusal, where a question was not answerable — stored as a result rather than as an absence

Bring the model you have to explain

The session is most useful when someone has already challenged a number. We will show what the system can and cannot say about where it came from.