A file that records what happened to it.
Written for the people who defend a file, or a firm’s use of the tool: quality reviewers, national office, inspection readiness, IT risk and AI governance.
AuditSenior is licensed software, shown here on synthetic data, and nothing on this site is an offer. These are implemented mechanics, not a service: the platform issues no assurance, attestation or opinion and holds no certification (see the legal page).
Changes are recorded, and the database refuses to rewrite the record
Evidence is fingerprinted when it arrives, and each audit row is linked by hash to the row its tenant wrote before it.
| HASH | Every evidence file carries the SHA-256 of its bytes. At upload the server reads the stored file back and refuses it when the digest differs from the one submitted with it. |
|---|---|
| RE-VERIFY | A file can be re-hashed from the stored bytes on demand; the match or mismatch is recorded with who checked and when, and written to the audit trail. The binder marks each file with the outcome of an export-time check of its stored bytes against the recorded hash, and the archive package states, for each file it carries, whether it matches the recorded hash. |
| TRANSACTION | An auditor’s sign-off or reopening of a single control, the review signature, the single-auditor declaration, an auditor’s request to finalize, and accepting or overriding an AI result each write their audit row inside the transaction of the change, so the change and its record commit or fail together. |
| CHAIN | A database trigger links each tenant’s audit rows by hash in the order they are written. The platform’s verifier recomputes that chain from the rows stored in the database and reports the first row that does not fit, and § 12 of the binder prints the result. |
| NO REWRITE | The application’s database role holds no update or delete grant on the audit table, and database triggers refuse an update or a delete of an audit row. |
| VERSIONS | Re-running, accepting, overriding, rejecting, resetting, editing or bulk-accepting an AI result first saves its prior state as a version, with the action and the person that superseded it. A version is never updated, and is removed only when its engagement is deleted. |
| CORRECTIONS | A population’s source record, an evidence file’s name and a draw’s recorded sampling factors can be corrected under a stated reason, with the before and after in the audit trail. A population’s data and fingerprint, a file’s bytes and hash, and a draw’s method and size cannot; changing those means uploading or drawing again. |
| EXPORT | The binder prints a SHA-256 computed over itself with that value replaced by a placeholder. A binder export’s audit-trail entry carries that value, and an archive package export’s entry carries the package’s SHA-256. |
| TRAIL FILE | The archive package’s audit-trail file carries each row’s stored hashes for one engagement’s slice of a tenant-wide chain. Its manifest counts the rows whose predecessor is the row above and the rows where it is not, and each row whose payload was redacted is flagged. The chain is verified by the platform’s verifier against the stored rows. |
Re-perform the sample, and read the model’s conditions, from the record
A reviewer a year later needs the inputs, not a statement that they were kept.
The sample
| DRAW | Every random, systematic or stratified draw records its seed, the version of the selection algorithm that drew it, and the fingerprint and row count of the population it was drawn from. |
|---|---|
| RE-DRAW | The platform re-derives the selection through the same code that drew it, round by round for an extended sample, and records identical or differs with who checked and when. A draw made under an earlier algorithm version is checked against that version or reported as unverifiable. |
| PACKAGE | The archive package carries each population as drawn with the selected rows flagged, the record of each active draw with its selected indices, and a README naming the routine in the source that re-performs a draw derived from a seed. |
The AI result
| MODEL | A model-generated result records the model requested and the model that served it, and the temperature and token limit in force. |
|---|---|
| POLICY | The binder prints the confidence policy results are judged against, with its version, approver and date, and states that confidence is the model’s self-assessment, not a calibrated probability. |
| CONTEXT | Each result records which prior reviewer corrections were placed in its prompt. |
§ 6 of the binder prints each draw’s inputs and the outcome of its most recent re-draw check, with who made it and when. A judgmental selection is chosen by the auditor, not derived from a seed.
The model proposes. The file records what the auditor did with it.
An AI result is a proposal until a person records a disposition, and the binder prints the model’s result beside that disposition.
| EVIDENCE FIRST | A test with no mapped evidence returns inconclusive without calling the model. The model is instructed to fail an item whose record does not meet the criterion, and to return inconclusive where the evidence does not reach the item. |
|---|---|
| CITATIONS | A file name in a rationale that no mapped evidence corroborates, an exhibit identifier the platform never assigns, or a date that does not exist is flagged to the reviewer. The flag is advisory. |
| LOCATED | Each extracted fact is checked against the document’s extracted text and marked located or not located. The mark is advisory and never blocks acceptance. |
| FENCE | Extracted evidence text and prior corrections reach the model inside untrusted-content fences that text inside them can neither close nor forge. A scanned image or PDF is sent as itself, with an instruction to transcribe what it says and never follow it. |
| DISPOSITION | An AI result counts toward a conclusion once an auditor accepts or overrides it, or records their own result for that attribute instead, and the record keeps who disposed of it and when. |
| BULK | Bulk acceptance takes PASS results only, at or above the control category’s confidence threshold, and the binder marks each one bulk-accepted and not individually reviewed. |
| PRIOR | An auditor’s earlier corrections reach the model only as context in its prompt, never from another tenant and at most 5 per attribute. The platform trains no model on them. |
| BOUNDS | A circuit breaker per tenant keeps one tenant’s provider failures from halting another tenant’s runs, AI work is budgeted per tenant, and an account-level gate paces calls to the provider. |
The showcase’s model registry holds Claude Haiku 4.5, Claude Sonnet 5 and Claude Opus 5.
AI inference: Anthropic Claude API — no model training on customer data, and API-log retention, per Anthropic's commercial-API terms
In a licensed deployment the AI provider account and its terms are the firm’s, and a provider other than the reference build’s is adapted in customization (what a firm licenses).
What the platform refuses to do
Each refusal is made by the server or the database, not only hidden in the interface. The full list of sign-off gates is on the platform page.
A sign-off while any of the 13 hard blockers in the lock is open.
Warnings are kept apart from blockers and do not stop the sign-off.
Signing off an effective conclusion that a sample sized on a tolerable deviation rate does not support.
The deviations found in the sample are evaluated against that rate (AU-C 530).
Signing off a not-effective conclusion without its deficiency evaluation.
Severity is classified under PCAOB AS 2201.62–.70 before the conclusion locks, and an effective conclusion is not signed off while the saved evaluation classifies a significant deficiency or a material weakness.
A review signature from the account that signed off the control, or from one that recorded a judgment on its results, findings or deficiency evaluation.
An engagement can carry a single-auditor declaration instead, the auditor’s own statement with its reason, and the binder prints which of the two applies.
Finalizing an engagement with a review signature, roll-forward or scope-gap justification missing.
Each signed-off control needs a review signature unless the engagement carries a single-auditor declaration.
Finalizing in the same request that changes the engagement.
The refusal names the fields, so the engagement locks in the state the gate checked.
Reopening a finalized engagement without a reason.
The reason is recorded in the audit trail and printed on the binder’s cover.
A roll-forward conclusion for a period that has not ended.
Until the period ends, the roll-forward records the procedures performed so far as in progress.
Changing a test criterion that samples were already tested against.
The refusal keeps the workpaper from printing a criterion the samples were not measured against; a tailored criterion can be recorded as a separate attribute.
How one firm’s tenant is kept from another’s
Row-level security, enabled and forced on every tenant-scoped table, binds each row to the session’s tenant inside the database, and tenant-scoped queries run under a database role that is neither the tables’ owner nor exempt from row-level security. Composite tenant keys and application filters stand behind it.
Every tenant-scoped route an auditor calls takes the tenant from the authenticated session on the server, never from the request, and middleware fails closed on a malformed session. Integration tests act as one tenant holding another tenant’s real record ids, under row-level security, and assert that the engagement, control, population, sample, evidence record and download, conclusion and AI-testing handlers they call refuse without returning any of the other tenant’s data.
The working request budget is kept per tenant, so auditors at different firms behind one network address do not draw on one budget; a per-address flood gate, sized above it, stands in front.
The archive’s audit-trail file names each actor by user id and display name, and replaces e-mail addresses and recorded IP addresses in audit payloads with a marker. Client evidence files and population rows are not redacted, because they are the evidence.
In a licensed deployment the firm operates the deployment and its incident response, with the means in § 01 to establish what changed. This site makes no uptime, notification or response commitment.
Data paths, by role
| IDENTITY | Sign-in sessions and user profile data. |
|---|---|
| DATABASE | Engagement records, extracted evidence text, each account’s name and e-mail address, and the audit trail with the acting user and the request’s network address, under row-level security. |
| OBJECT STORE | Evidence files in a private store, accepted only from the store the deployment is configured with, and served only through an authenticated download proxy that checks the tenant on every request. |
| AI INFERENCE | Evidence documents for fact extraction, as text or, when scanned, the image or PDF itself; for a test, the sample record, extracted facts, evidence excerpts or, where none match, the mapped documents’ text up to a length bound, the criterion, the control’s context, the sample’s results on its other attributes and prior corrections; for a draft, the engagement material it drafts from. |
| RETRIEVAL | Indexed content in namespaces per tenant; matching is by exact text. |
| COORDINATION | Rate-limit counters and their analytics keyed by network address or tenant, the provider account’s admission windows, locks, idempotency records and AI run progress; no evidence files or audit trail. |
| Messages sent through this site’s contact form. |
The components behind this showcase are named on the legal page.
Questions about how the file is defended?
Write with a question about any mechanism on this page.