Data-inconsistency scan
FR-6: authored cross-checks over governed results
This scan checks source data quality — it cannot detect a computation error, and it is not a proof that a computed figure is correct.
Because both sides are computed deterministically from the same source by the same engine, a disagreement cannot be arithmetic. What the checks surface is source-data problems: orphan rows, late-arriving data and referential gaps.
Checks compare like-versioned figures — a metric whose definition version differs on either side is not a valid comparison (Appendix C).
POST /reconcile is net-new work not present in the shipped API (FR-6). It is scoped and scheduled as a new build item and carries schedule risk; this surface therefore runs against sample data in this build. The exact checks per domain are still to be confirmed with BoM (Open question 2).
How to read a failure
A failing check means two governed results that should reconcile do not — the problem is in the data, not the arithmetic, so triage starts at the source system. Scans read a replica under query governors, never live Core Banking OLTP; in this build they run on sample data.
Because the engine computes both sides from the same source with the same sanctioned SQL, the disagreement points at the data: an orphan row whose parent category was never created, late-arriving records that landed after one side was computed, or a referential gap between a transaction table and its dimension. Triage starts at the source system, not at the metric definition.
Equally, a full set of passes is not evidence that a figure answers the question that was asked. The engine computes the number and the model never emits it, but the model does choose which governed metric and which filters matched a question, and it can choose wrong. This scan cannot see a misroute.
In the delivered system each scan and the queries it runs are written to the audit trail. Here the scan is served from sample data, so nothing on this page evidences that control.