Reconciliation

Why it matters

Finance has done this for centuries. You do not trust your own ledger because you wrote it. You match it against the bank statement, the record of what truly settled, and only the lines that agree are considered closed. Notice who supplies what. You do the matching, but the bank hands you the statement. You do not climb inside the bank's vault to watch the money move. An autonomous agent needs the same discipline. Its confidence, its passing evals, and its logs are all its own ledger. They describe what it believed it did. Reconciliation is the moment you hold that belief up against the settled result and see whether they tie out.

Consider an agent that approves an insurance claim. Every internal check is green: the policy is active, the documentation is complete, the amount is within limits. Weeks later the claim is reopened on appeal and overturned. The decision looked right at the time and was wrong at settlement. Without reconciliation, that reversal never travels back to the decision that caused it, and the agent keeps approving the same way.

Business context

Reconciliation is already a line item in most enterprises. Finance, operations, and audit teams match records against an independent source of truth at every close. Extending that discipline to an autonomous decision is less a new practice than applying an old one to a new actor. For a leader it is the difference between reporting what agents claim they did and reporting what actually settled, and the settled version is the only one an auditor or a board will accept.

Where it fits

Reconciliation is the mechanism underneath Outcome Intelligence. It is how an estimated result becomes a proved one, and it is what makes a business outcome usable as a signal rather than a number in a report.

How the comparison works

Provy is the one doing the reconciliation, but it does not go and read the settled result for itself. Two things get compared, and you supply both. The first is a short contract, written before the run: a plain checklist of what a good result means, one condition at a time, each a simple statement like the amount matches or the ticket did not reopen. The second is the settled result, reported back to Provy after the run and tagged to the same work item, whether that is an invoice, a ticket, or a trade. Your system of record sends it, or a person does.

With both in hand, Provy compares them condition by condition. The run counts as a success only when every condition held. One condition that failed is enough to mark the run failed, the same way a single line that does not agree keeps a reconciliation open. Until a real result has been connected back, the honest verdict is "not measured," never a quiet pass.

When it applies

Whenever the truth of a decision arrives later than the decision itself: claims that can be appealed, forecasts that a real number eventually confirms, approvals a downstream audit can reverse. If a decision is right or wrong the instant it is made and never changes, you can grade it on the spot. Most real work is not like that. The outcome shows up on a delay, and reconciliation is how you go back and settle the score.

Common misunderstandings

It is not the same as testing. A test asks whether the decision looked right against a known answer; reconciliation asks whether it turned out right against the real result.

It is not a one-time audit. A single check settles one decision. The value comes from doing it on every decision, as each outcome arrives.

It is not about blaming the agent. Reconciliation establishes whether the outcome tied out, which is the first step to separating a bad decision from a world that moved.

Related concepts

In the product