Don't take our word for it. Check it.

• —Traced: the figure appears in a source. You see the document and the line, with the figure highlighted.
• —From your message: you supplied it. It is never presented as evidence.
• —Not in the sources: it was calculated or came from general knowledge. A correct total is still marked this way — that is the number to check before you rely on it.

The check is exact matching in code, not the model's opinion of itself. It folds formatting (“$1,200.00” matches “1200”) but never rounds. The receipt under the answer can be copied into a working paper or file note.

• —Steps that change something — saving, sending, writing to a system — can require a named person's approval before they run.
• —The replay shows who decided, and when. A refused step is shown as refused, not quietly dropped.
• —Inputs and outputs are visible only to the person whose conversation it was; others see the steps and receipts.

Each entry stores a SHA-256 hash computed over its contents — its id, time, organisation, user, event type, action and details — and the previous entry's hash. The database refuses edits and deletions of audit rows; the one exception is the retention period your organisation sets, and each retention purge is itself recorded, with the entry the chain resumes from. If a row were changed anyway, by someone with privileged access, its hash would no longer match, and every later link would break.

What the verifier checks

• —Every entry's hash, recomputed from its stored contents, matches the hash stored with it.
• —Every entry's “previous hash” is the hash of the entry immediately before it in sequence — so a deleted or inserted row shows as a gap.
• —The newest entry matches a signed record of the chain's head kept outside the database — so rows cut off the end are caught too.

To be precise about what this is: tamper-evident, not tamper-proof. It does not stop someone with full database access from altering a row; it makes the alteration detectable. By default, if every audit store is unavailable at once, the action goes ahead and the gap is logged as critical. Deploys that need strict compliance are set to stop the action instead.

• —Onshore, offshore or not configured — judged from the deploy's configuration, such as endpoint hosts and regions.
• —In Australian-residency mode, an offshore service that would carry client content is refused or switched off rather than used quietly. Infrastructure that can't be refused call by call is reported instead.
• —The report says ready only when nothing is offshore.

We don't claim every part of every deploy runs in Australia today — the sample above shows what the report says when something doesn't. Commercial deploys run in Australian-residency mode, and each deploy's report shows exactly where its data goes. Every deploy publishes this report; ask for it.