Skip to main content

Asking the Auditor

The Auditor is the agent you use when you want independent assurance rather than an opinion. Pick Auditor in the Chat with row on the landing, or open its workspace from the roster, and ask it to check the books. It has a Chat tab and nothing else, because an agent that only reads has nothing to stage and nothing to upload. A routine full sweep runs six families of check and reports what it found. The seventh, close_gated, runs only when the request names it or a period-close schedule selects it. All seven declared families have a runner; the full-sweep list is narrower only because the seventh needs an explicit finished period. It changes nothing, and its own answer says so.
Asking is only half of it. The same checks also run every night on a schedule, and what they find lands in a durable register you work through the Audit workspace rather than by asking again. Working the exception register is that half.
An Auditor conversation reporting the results of a full integrity sweep

A full sweep. All checks passed, with the numbers behind each one.

The six routine families

A note on “1 in-flight row”. That is the correct, healthy answer while a document is sitting at the posting gate. It only becomes a finding if the Auditor says a row is stuck.
A note on “inconclusive” from the reconciliation family. The graph it reads is refreshed on a schedule, and a reconciliation over a graph older than six hours is reported inconclusive rather than clean. That is the correct answer, not a failure: it means the projection has stopped, and nothing cross-system has been verified since it did.
The check family keyed invariant in the code is the GL invariant sweep, and the name is accurate: it re-checks the GL invariants over entries that are already posted. It is a different thing from the Close checksums, which reconcile the sub-ledgers against the GL and report rather than refuse.
The seventh family is explicit-only. close_gated covers the 26 Close checksums that only become true after a period has ended. It runs from its monthly job or a question naming one of its controls, not from the routine full sweep. A full sweep deliberately leaves it out rather than printing a permanent “could not verify” line under every answer, and a job that names it on purpose is told so by name.
Two skips you will see named in the answer, and they are correct. The continuous Close sweep says “AP-CONTROL is the recon family’s, AR-CONTROL is the recon family’s”.Those two facts are checked by another family in the same sweep, and reporting them twice would put two rows in the register for one problem. The skip names its owner rather than going quiet, so you can tell a deliberate skip from a gap.

Why you can trust it

The Auditor has no write path at all, and the database itself would refuse a write from it. That is a stronger claim than “it does not write”. “It does not write” is a property of the code, which could change. A read-only session is a property of the connection: even a bug in the agent could not produce a write, because the database rejects it. And the channel does not assume it: it puts the session read-only, then asks the server to confirm it and refuses to hand out a connection that will not confirm. A check that cannot get a provably read-only channel reports inconclusive rather than reading your book through a session that could also write to it. The four mechanisms behind that are on the Auditor’s page.
There is a second reason to trust the hash-chain check specifically, and it is the more interesting one.The recompute reuses the ledger writer’s own hash helpers. It does not carry a second implementation of the checksum formula.If it did, the verifier could silently drift from the writer: the writer’s hashing changes, the verifier keeps checking the old formula, and the sweep goes green forever while checking nothing. That is exactly the paste-over-value failure class, one layer up. Because the Auditor recomputes with the writer’s own code, it cannot drift.

When to run it

Before any close

A book whose chain is broken cannot be certified closed on top of. The Accountant’s close checklist runs this sweep as its second step for exactly that reason.

After any unusual day

A bulk import, a migration, a manual intervention, a restore. Anything that touched the database by a route other than the writer.

As often as you like

It is read-only, so running it has no cost to the book. There is no reason to ration it.

When something looks wrong

Ask it directly. It answers questions about integrity in plain language and shows the numbers.

What it cannot tell you

The Auditor proves the book is internally consistent and untampered. That is not the same as proving it is correct.
  • It cannot tell you a supplier invoice was booked to the wrong account, because a wrong account still balances.
  • It cannot tell you an invoice is fraudulent, because a fraudulent invoice posts exactly like a real one.
  • It cannot tell you a number was mis-extracted, because it does not read the source documents.
Those are what the two human gates are for, and what the Close checksums reconcile against external evidence.
Being clear about this is the point. An assurance tool that implies it checks more than it does is worse than no assurance tool, because it buys confidence it has not earned.