The reconciliation loops this controller can close.

Each carries the policy and taxonomy governing it, the strategies it matches with in the order it tries them, the source files it expects, and any promoted rules in force. Read it before asking for a close: the loop decides what a "side", a "counterparty" and a "tolerance" mean, and nothing here is hardcoded in the engine.

Which periods' source files are on disk, complete or not.

Incomplete ones are listed with the missing filenames named. A close over a half-arrived period would report a clean month over rows that never came, so it is refused — but the fact that October is short one file is the useful answer, not an empty list.

Closes already recorded, by run id.

A run id is derived from the source bytes and the authority in force, so re-closing identical inputs under an unchanged policy reuses the id rather than creating a second record of one event.

Close one period: match, verify, post, record.

Note what this does not take. There is no policy argument, no tolerance, no rule set and no chart of accounts — a caller picks which loop and which period and nothing else, and everything that decides whether an answer is permitted is loaded from the loop's own signed bundles. You cannot widen a tolerance through this tool because there is no parameter through which to try.

Every posting it writes descends from a proof that was re-derived from raw records before anyone saw it; a match that fails re-derivation is dropped and its refusal recorded. The return value is read back out of the decision log the close just wrote, so what you see is what an auditor holding that file would see.

Match one period and return the proofs — no posting, no ledger, no log.

The matching stage on its own, for a caller that wants to check our arithmetic rather than have us close the books. Returns proven matches with their full proofs, everything the verifier refused, and the exceptions raised.

The records are not inlined — 543 rows of this toy corpus is ~342 KB, most of a context window. fetch_records pages them. But ignore them: ingest the same source files with the published adapter spec and verify against your own records. That is what verify_proof is for and it is the only version of this that proves anything about our honesty.

Matches page too, proofs included, because a caller here is calling for the proofs. match_page.next_offset is the cursor; it is null when you have them all, and total is always the real total.

A recorded close, rebuilt from its decision log.

Match rate with its tier split and its proof-tier split, what is blocked, what is waiting on a human, which authority it ran under and whether that authority's signature held. Blocking recall is reported absent rather than zero: it is measured against labelled true pairs and production has no labels — a zero there would be a claim we did not earn.

detail="summary" (the default) names each match and its proof_id without inlining twenty proofs; get_proof returns the one you want to read. detail="full" inlines them all and is ~59 KB. A projection, not a permission — it changes how much of the answer travels, never what it is.

One match with its full proof — every leg, its record ids and its subtotal.

What a verifier reads before calling verify_proof. The subtotals here are claims made by whatever produced the match; recomputing them from the records is the entire job, and verify_proof refuses a proof whose legs do not add up to what it says.

The records a loop reads, a budget at a time.

Here for completeness, and worth skipping: verifying our arithmetic against records we handed you proves the sum and not the honesty. The source files, the adapter specs and the policy are all published — ingest them yourself and verify against those.

The exception queue, ranked by cash impact x age and routed to an owner.

This is the tail, and the tail is the product. An item whose code has not been ratified carries a note saying so — a proposed category rendered identically to a promoted one would hide the one thing you need in order to know how much to trust it.

One exception with its evidence, its records and what it is allowed to do.

E14 unexplained means no strategy matched and the engine cannot say why. It carries the facts it has and leaves classification open on purpose: "I do not know" out loud beats a plausible guess routed to the wrong desk.

Everything needed to re-derive a close, and nothing that requires us.

Every decision with its proof, the rule version that fired, the human who approved the authority, the source document hashes and the adapter spec ids that read them. how_to_verify spells out the four steps; none of them touch our database or our network.

The typed decision log, event by event, hash-chained.

Append-only in the only sense a file can be: each event carries the hash of the one before it, so an edit, a deletion or a reorder breaks the chain and verify_journal says where. It does not prove custody — someone able to rewrite the whole file can recompute the chain over anything. What it closes is the partial edit and the truncated tail.

Paged: 62 events for a 22-payout month is 114 KB. total is always the real total, so "here is the log" and "here is the start of the log" stay distinguishable — which a bare list could not manage.

Re-derive one proof from records you hold. Stateless, and it trusts nothing.

The verifier fetches each record by id, recomputes every leg subtotal and the residual from those records, and compares against what the proof claims. It reads no stored residual, takes its sign convention from policy rather than from the proof, and refuses a proof whose claimed tolerance exceeds the policy ceiling. A proof that names a record you did not supply is refuted, not excused.

Name a loop to verify under that loop's published policy, or hand in a policy of your own. Exactly one — there is no default, because a verification that silently chose a policy would be deciding your constraints for you. The verdict says which you used: a lenient policy you brought along yields a verdict about your constraints and is stamped caller-supplied so it cannot be quoted back as ours.

This call is how you check our work without trusting us. Take a proof out of audit_export, ingest the source files yourself with the published adapter spec, and run it. If it disagrees with us, that is a finding about us.

Re-derive a whole recorded close from the source files on disk.

Re-ingests the sources with the published adapter specs, checks each document's sha256 against the hash the record pinned, and re-derives every proof in the log against those fresh records. Nothing is read from the memory of the process that ran the close, so this is the same thing an outside auditor does — done by us, on demand.

Three failure modes, reported apart because they mean different things. sources_match false means you pointed it at different bytes than the close ran on: your mistake, not our finding. refuted means the arithmetic does not hold: our finding. missing_proofs means the record has no proof to check, which is a gap in the evidence and deliberately does not pass.

Check a decision log's hash chain and its terminator.

The terminator states how many events precede it and what was decided; those are claims by the writer, and this checks them against the stream. A valid chain over a truncated log is still a valid chain, which is exactly why the terminator has to be there.

Ask whether a proposed code for an exception would be admissible.

Nothing is written. The proposal goes through the same checker the live triage path uses: the code must resolve in the registry and be assignable, the hypothesis must exist, the evidence must cite a record the exception actually names, and the exception's own label must not already rest on stronger evidence than a proposal can carry. A derived E09 — one the engine proved by enumerating two valid subsets — outranks any proposal and is refused here, which is the rule that stopped a model overwriting a proven answer with a guess.

A verdict of admissible: true means the proposal is well-formed and permitted, not that it is right. Making it so is accept_classification, which writes under the name on your credential.

End an exception in a journal entry: book, carry_forward, chase, write_off.

This moves money, and it is meant to. The item leaves the worklist, double entry is written, and the record carries your name and the fact that an agent put it there.

What it will still refuse, all of it from the loop's signed policy and none of it from you: a write-off above the per-item ceiling, one that would exhaust the close's write-off budget, a book on a code the taxonomy has not promoted, and any second disposition of an item already ended. There is no ceiling parameter and no chart parameter, so there is nothing to widen.

due_on is YYYY-MM-DD and applies to chase only.

Accept a proposed code for an exception, under your name.

propose_reclassification asks whether a code would be admissible and writes nothing. This is the other half: it records that somebody accepted it. Same checker, same refusals — a proposal may still not overwrite a code the engine derived, because a guess does not outrank arithmetic no matter who signs for it.

Accept the close. The terminal decision, and the strongest claim here.

Three refusals stand, and they bind an agent exactly as they bind a person at a screen, because none of them was ever a question about who was calling: books that do not balance, blocking items nobody has opened, and an unnamed signer. Delegating to an agent does not make an unopened item opened — read the worklist first, the same as anyone would.

The pack records that this signature arrived through an agent. That is not a hedge against you; it is what lets a reader a year from now tell the difference between a close somebody read and a close somebody automated.

The policy, vocabulary and promoted rules governing a loop — and who signed.

Codes carry their lifecycle state: naming one grants nothing, and only a promoted code may direct a posting. Rules carry the human who approved them and the policy that approval was granted under; an approval is re-checked against the policy in force wherever the rule acts, so a rule approved under an old policy does not quietly keep its permissions.

JSON Schema for the public, semver'd shapes — Record, Proof, Policy, Event.

Published so another system can build on them. They are versioned under ADR-002: a field change is a version bump, not an edit, because an independently-written verifier that stops working is the one failure this design cannot survive.