A file that records what happened to it, and who could reach 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.
These are implemented mechanics of licensed software, not a service: the platform issues no assurance, attestation or opinion and holds no certification (the legal page states the terms).
Changes are recorded, and the database refuses to rewrite the record
The audit trail cannot be edited through the application or by the database role it runs under, and the binder prints the outcome of the last verification of its chain. 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. A file whose bytes and declared type match one already on the engagement is refused, naming the existing file, unless the auditor states why it is recorded again.
- 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.
A recorded mismatch holds the sign-off of every control that cites the file until the file is replaced or unmapped and no quality-review result of the control is cleared with it, and a file with a recorded mismatch cannot clear a result.
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.
- AT SIGN-OFF
At a control’s sign-off the platform re-reads each mapped evidence file not verified since it was last mapped and compares its SHA-256 with the hash recorded at upload.
A file this check finds not matching, or cannot read, stops the sign-off and is named, and each file it checks is recorded as verified, with its audit row, in the transaction that locks the control.
Where more than 25 files await this check, the sign-off is refused, naming each of them, and they are verified on the Evidence step first.
A file whose latest re-verification recorded a mismatch holds the sign-off until it is replaced or unmapped and no quality-review result is cleared with it; the quality review's Evidence Integrity check also reports it at high severity, and acknowledging that result does not clear the hold.
- STORAGE
- A firm’s administrator can check the firm’s evidence records against the store, and each record whose file the store does not hold is listed. A file a deletion left in the store shows on a re-check, and is removed only once no evidence record in the firm points at it; the request is recorded before the store is asked, and the outcome once it answers.
- 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 confirming, 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.
A verification states what it rests on: a walk of the whole chain end to end, or a walk of the entries written since the last verification, anchored to the entry that walk ended on and recomputing that entry’s own hash; an anchored outcome states the date the chain was last walked end to end. Binder § 12 prints the outcome and its basis.
- 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 or editing an AI result (and, under an earlier release, accepting it in bulk) first saves its prior state as a version, with the action and the person that superseded it.
A version is never updated. It is removed only with its control, when the control is taken out of the engagement’s scope under a stated reason, or with its engagement or its workspace when either is deleted; each such removal is recorded in the audit trail in the same transaction, and the database refuses any other removal by the application.
- CORRECTIONS
A population’s source record, an evidence file’s name, a draw’s recorded sampling factors, the sample reference of an exception raised on a sampled item, and the attribute an exception is recorded against (other than one raised from an AI result or a rule test) 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.
- REMOVED WORK
- When a first draw, a re-draw or a population replacement deletes a control’s exceptions and quality-review checks, each is recorded in full in the audit row of that change, inside its transaction: every narrative of an exception, and a check’s result with the auditor’s acknowledgment and note.
- CONCURRENT EDITS
- Where two sessions edit the same part of a control — its conclusion, its evidence expectations, its scoping, its system assignment or the entity’s own description of the control — the server refuses a save made on a screen that loaded that part before the other change, and does not overwrite it.
- 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 carries one engagement’s slice of the tenant-wide audit chain in two files, row for row: an audit-trail file that names people and records in words, and a chain file holding the fields each row’s hash is computed over, as the database hashed them, so each hash can be recomputed outside the platform wherever the database hashed its times in UTC.
The export recomputes every row before it ships and states, row by row and as a count in its manifest, which rows recompute; a row whose payload was redacted is flagged and does not.
The manifest counts the chain links that point to a row in the file, start the chain, or point to rows outside the file, which belong to other engagements or to the firm itself, since the chain is firm-wide. The chain is verified by the platform’s verifier against the stored rows.
In the application, each engagement’s audit trail can be read and filtered, and the entries the filters select exported as CSV.
Re-perform the sample and the data procedures, and read the model’s conditions, from the record
A reviewer a year later needs the inputs, not a statement that they were kept.
- its seed
- the version of the selection algorithm that drew it
- 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
- a README naming the routine in the source that re-performs a draw derived from a seed
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 data procedures
- INPUTS
- Each run records the fingerprint of every population and file it read, and the keys, columns and parameters the auditor chose.
- VERSION
- Each run records the version of the code that performed it, who ran it and when, and the fingerprint of its result.
- RE-RUN
- A run can be performed again on its stored inputs, and the platform records whether the result is identical.
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.
Binder § 6 prints each draw’s inputs and the outcome of its most recent re-draw check, with who made it and when. A judgmental selection, and any item the auditor adds to a random sample, 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.
- Auditor: The AI runs only on an auditor’s action, never on a schedule.
- Model: For each attribute of a sample, the model proposes PASS, FAIL, INCONCLUSIVE or NOT APPLICABLE, with a rationale and the evidence it quotes. It never concludes on a control and never signs one off.
- Platform: No PASS and no NOT APPLICABLE the model proposes is final without the auditor. The platform never upgrades a FAIL.
- Auditor: The auditor decides each row on its own: confirms the model’s proposal with a note, decides differently, or accepts the result as inconclusive.
- Platform: The result records who decided and when, and a confirmation is written to the result and to its audit row in the same transaction.
Rules the platform applies to AI results
- EVIDENCE FIRST
The platform runs no AI test on a sample with no mapped evidence: a test of that sample alone is refused, and a run over several samples leaves it out, so no result is recorded for it.
On a sample with mapped evidence, an attribute with none mapped to it is recorded inconclusive by the platform, 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.
- HOLDS
Where a PASS or not-applicable answer quotes text the evidence it was shown does not contain, rests on a value only the population listing carries, or concerns a sample the evidence does not locate, the platform records the result as inconclusive, held by the platform, and the binder prints the model’s own answer beside it. No PASS the model proposes is final until the auditor confirms it.
An answer given with no rationale, or fewer than ten characters of one, is recorded as inconclusive whatever it was, a FAIL included. Where the quote, value, coverage or location checks question a FAIL, the FAIL is kept.
- CHECKS MATCHED
On the 9 attributes with a declared rule, the platform itself finds each fact the rule names as the whole value at the place in the evidence the model cites, all on one record of the sample’s own.
A rule names the date of the act and the date it is measured against, who performed it and its recorded status; or two people who must differ.
Where the platform computes that the dates are in the order the rule requires, or that the two names differ as written, and no other field of the record writes a value, a state, a flag, a count or a word the platform reads as denying the act, the answer is shown as “Checks matched — your decision”, with each fact cited, its file and its place.
It also shows what the platform did not check: whether the cited facts are the ones that answer the attribute, other rows, blocks or files about the item, what other fields of the record mean beyond a value or a word that denies, a state, a flag or a count, prose, and who the person named is or their authority.
Nor does it check whether the file is complete, accurate and authentic as the client produced it: the report or query that produced it is not checked here, and deliberately altered files, including text whose shown letters differ from its stored text, are not detected beyond the PDF checks under What the auditor reads.
The auditor confirms it with a note, which starts as the platform’s own sentence and may be kept or replaced, or decides otherwise. Every other PASS, and every not-applicable answer, is held the same way, the model’s proposal, its confidence and its quotation shown beside the result.
- COVERAGE
The coverage check reads a PASS against each interval of the period wherever the criterion or the attribute names a recurrence, whatever the rationale says, and also where the rationale says the control operated across the period on a control with a stated cadence or a periodic frequency; a sample that is itself one occurrence of a control sized on that recurrence is read only where its rationale says so.
It records that PASS as inconclusive in the same way where the records shown leave an interval without a record, where the intervals cannot be read, or where mapped evidence that could carry a dated record was not shown to the model. A criterion naming the year end is read as an annual recurrence over the period tested.
A PASS saying the control operated across the period, on a criterion that names no recurrence or cadence for a control not sized on a periodic frequency, is flagged for the reviewer as well.
- LOCATED
- Wherever the document’s text can be searched, an extracted fact is checked against it 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.
- ENDPOINT
- Inference calls go only to the provider’s API endpoint named in the code, and the application refuses to start when an environment variable would redirect those calls, add headers to them or log their bodies.
- 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. Where an attribute is judged on an access review as a whole, an AI verdict never replaces the result the auditor recorded for the review: a verdict that agrees is recorded beside it, and one that differs is refused.
- POLICY OWNER
- The confidence thresholds are the firm’s adopted policy, adopted only by the firm’s administrator or a designated engagement partner. A threshold below the platform’s reference default needs a recorded justification, and until a firm adopts a policy the reference default applies, labelled as not adopted by the firm.
- BULK
- Every AI answer on the Testing step is decided by the auditor, one at a time: the step offers no bulk acceptance. A result accepted in bulk under an earlier release keeps that record, marked as accepted in bulk and not individually reviewed, and the review signature acknowledges any such result never opened individually.
- PRIOR
- An auditor’s earlier corrections reach the model only as context in its prompt, only from the same engagement (never from another client’s file or 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.
Model and provider
The showcase’s model registry holds Claude Haiku 4.5, Claude Sonnet 5 and Claude Opus 5.
AI inference: Anthropic Claude API, under Anthropic's commercial terms — no model training on customer data. The provider retains API inputs and outputs for a limited period under those terms; zero data retention is not enabled on this deployment's account. No retention period is claimed here that this deployment does not control.
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).
How the AI was tested
What the platform enforces on every AI answer, how the AI was tested, and the rules in force.
- WHEN THE AI RUNS
- The AI runs only on an auditor’s action, never on a schedule; each test answer proposes a result for one attribute, and counts toward a conclusion only once the auditor has decided it.
- AUDITOR DECIDES
No PASS and no NOT APPLICABLE the model proposes is final without the auditor: each is stored as INCONCLUSIVE, with the model’s proposal, its confidence and the reason the platform holds it kept beside the result.
The auditor decides each row on its own: confirms the model’s proposal with a note, decides differently, or accepts the result as inconclusive.
On an answer whose checks matched, the note starts as the platform’s own sentence, which the auditor may keep or replace with what they checked; on any other answer the auditor writes the note, of at least 10 characters.
The result records who decided and when, and a confirmation is written to the result and to its audit row in the same transaction.
- FAIL
The platform never upgrades a FAIL.
A FAIL the model gives is stored as FAIL, and is kept where the quote, value, coverage or location checks question it.
An answer cut short, or one the platform cannot read in the required format, is read as FAIL where the word fail stands in it in any form, even “did not fail”, or as a result other than PASS that it names, and is not asked again.
A FAIL given with no rationale, fewer than ten characters of one, or one longer than the record holds, is stored as INCONCLUSIVE, never as a PASS.
Only the auditor’s override, with a note, turns a FAIL into another result; the auditor may also record their own result for the attribute instead, and a re-run records the model’s answer on that run under the same rules.
- SCOPE
- For each attribute of a sample, the model proposes PASS, FAIL, INCONCLUSIVE or NOT APPLICABLE, with a rationale and the evidence it quotes. It never concludes on a control and never signs one off.
- METHOD
The model is tested through the platform’s own Testing step, on demonstration engagements built from synthetic evidence, and each answer is compared with the expected result recorded for that check.
The latest run on the Testing step was held to four tests: no PASS or NOT APPLICABLE is stored as final; every check whose expected result is FAIL is recorded FAIL; no answer reaches “Checks matched” where PASS is not the expected result; and every quotation in an answer proposing PASS, and in a recorded FAIL, is checked against the bytes of the evidence, and every statement the check flags is read by hand.
The latest run on the Testing step is recorded with its date, the guard rules it ran under and its counts; each of its results the model answered records the prompt and the guard rules it was given under, and every answer stays in the platform’s results. Every change to the prompt or the rules is entered in the prompt change log with its reason.
The prompt and the guard rules in force are later than the latest run with the model; each change since is entered in the prompt change log with its reason and how it was checked, by the platform’s own tests and not by a run of the model.
This page describes the method, not a score: figures from a run hold only for the prompt and rules that run used.
A licensee’s quality or risk team can ask for the records of the latest run.
- RULES IN FORCE
The rules in force are dated 17 October 2026.
The location check on a cited fact reads a table written with column separators, and it also reads the first column of a table a file’s text writes without column separators, as a PDF’s often does: a fact cited there is checked against the cell on its row.
The text the platform reads from a PDF keeps a wide space between two columns as a column separator, and the check reads a label and its value standing in two such columns as one field, and every column of a table whose header stands in three or more such columns, each cell under its header.
A PDF row in which a cell, a form label or a form value goes on in a line of its own, and a field whose value may go on in the next line of any file’s text, are not read as the whole value, except where the check does not see the value go on, each case named under what the auditor reads.
- WHERE CHECKS MATCHED APPLIES
- “Checks matched — your decision” marks a proposed PASS on which every check the platform applies matched. It exists on the 9 of the 132 shipped attributes that carry a declared rule, where the attribute’s text, its control’s objective and its frequency are the ones the rule was declared on, so a tailored criterion leaves its attribute without it. The mark never replaces the auditor’s decision: every proposed PASS, marked or not, is held for it.
- WHAT THE AUDITOR READS
Each of these is held for the auditor with its reason, never shown as “Checks matched”: a JSON fact whose key path names no one value or whose record does not name the sample alone; a label and its value laid side by side in a PDF with no colon or equals sign between them, where the PDF’s text does not keep them as two columns; a record whose key stands under a column not named as the population’s key.
The first line of a value is read as the whole value where the platform does not see the value go on: a PDF cell going on at the next page’s top, lower than two font sizes and the row spacing, at the row’s left above its row or where rows sit as close as a cell’s lines, or in every cell; rotated text; a next line opening a field, list item, heading or table row of its own.
An identifier followed by a full stop and digits alone, as a version is written, is read as one name, not as another item’s identifier. Word documents are read as text: body, tables by row and column, headers, footers, notes and comments.
A PASS citing one is held for the auditor, each part named, where its body has deleted or hidden text, a drawing, a checkbox, a drop-down or computed field, a table row with a merged cell, image or nested table, where a note or comment is not read whole, or where the file was last read before tables were read this way.
A PDF’s text layer is read with each page’s drawing checked beside it.
A PASS citing one is held, each page named, where a page holds an image, a mark other than rules and boxes, an annotation or form field that shows something, no text while others have some, text hidden, covered, too faint or small, or, in a simple font, drawn as other letters than stored, or the file carries a hidden layer, an XFA form or scripts.
Where a file’s text writes a table without column separators, as a PDF’s often does, its first column is read by row, and a fact cited under another of its columns is held for the auditor with its reason.
Where a vulnerability’s remediation rests on a later authenticated full scan, the model may answer INCONCLUSIVE instead of applying the prompt’s rule for reading that scan; that answer is held for the auditor as the model gave it, and no check changes it.
The checks test the facts the model cites as written; whether those facts answer the attribute is the auditor’s judgment, so every row is read by the auditor and a right answer may be held for that reading.
Confidence is the model’s own figure, not a calibrated probability, and a re-run may answer differently: the default testing model takes no temperature setting.
- CHANGE CONTROL
Every change to the testing prompt is an entry in the prompt change log, under a version of its own.
The prompt version and the guard-rules version in force (prompt dated 12 October 2026, rules dated 17 October 2026), the fingerprint of the exact system message, the model requested and the model that answered are recorded on every result, and each model the platform can call has a model card.
Under the guard rules in force, each result of a model call on an item records in which mapped files the sampled item was located, and an answer proposing PASS or NOT APPLICABLE on an item no mapped file locates on its own record is held for the auditor.
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 32 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, and the file cites the standards of the framework the engagement is conducted under.
Signing off a not-effective conclusion without its deficiency evaluation.
Severity is classified as a deficiency, a significant deficiency or a material weakness before the conclusion locks, and an effective conclusion is neither saved nor signed off while a saved deficiency evaluation stands, whatever its classification: a deficiency, a significant deficiency or a material weakness. Where the auditor classifies differently from the platform’s computed classification, the reason is recorded and the binder prints both.
A review signature from any account that prepared the control: one that signed it off, created its population or drew its sample, mapped its evidence, or 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. A signer can withdraw their own review signature, under a stated reason recorded in the audit trail, until the engagement is finalized.
Finalizing an engagement that lacks the engagement partner’s sign-off, a review signature, a roll-forward, or the justification for a recommended control it does not test.
Each signed-off control needs a review signature unless the engagement carries a single-auditor declaration, which also stands in place of the partner’s sign-off.
An engagement flagged for an engagement quality review also needs the concurrence of a quality reviewer independent of the work, which no declaration replaces; a sign-off or a concurrence counts only when given after the work it covers. A recommended control recorded as not covered needs its own severity evaluation, and each control needs the quality-review checks its category requires.
When the last control is signed off, the platform finalizes the engagement by itself only when these conditions hold.
Finalizing, or exporting the final binder, while a severity evaluation or a record of deficiencies in combination saved before the period ended stands as provisional.
Once the period has ended, each is confirmed as of the period end under a stated reason, or revised; on an engagement with an interim date, a control’s evaluation saved or confirmed before its roll-forward was last recorded is confirmed again.
Before finalizing, an interim export is available once the engagement is in review with an interim date and every control is signed off or concluded “Not Concluded — Scope Limitation”, and the binder it produces is marked interim and not finalized.
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. While the engagement is open again, dated addenda can be added to that record; none can be edited or removed, and the cover prints them with the platform’s count of the work done since the reopen.
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.
Rewording a test attribute — its name, description, criterion or evidence expectation — once work stands against it.
A manual or AI result on the active sample, the latest rule test on the attribute, where it measured every row it selects on the population on file, a conclusion saved on the control, or an AI run in progress on the control refuses the change, so the workpaper never prints wording the recorded work was not measured against.
Until then, any criterion can be tailored to the client’s policy under a stated reason, recorded in the audit trail with the before and after.
A criterion the template left open, with only AI verdicts recorded against it, is tailored in place under a stated reason: each verdict stays in the result’s history under the criterion it was tested against, the binder marks it, and its sample is re-run, or given the auditor’s own result, before the control is concluded.
Who can reach a file, within a firm and between firms
Within a firm
An engagement’s file is reachable by the people designated to it — preparer, reviewer, engagement partner or engagement quality reviewer — by the person who opened it, and by the firm’s administrators.
Revoking a designation withdraws the access it gave at the next request; a firm administrator or an active engagement partner can also withdraw, with a reason, the access of the person who opened the engagement.
Anyone else gets the answer given for a file that does not exist, so a restricted client’s name is not disclosed, and the attempt is written to the audit trail. In a demonstration workspace, every member reaches every engagement; its use is limited to synthetic data by a condition of use, not by a technical control.
- Reachable by:
- the people designated to it — preparer, reviewer, engagement partner or engagement quality reviewerRevoking a designation withdraws the access it gave at the next request.
- the person who opened itA firm administrator or an active engagement partner can also withdraw, with a reason, the access of the person who opened the engagement.
- the firm’s administrators
- Anyone else:
- gets the answer given for a file that does not exist, so a restricted client’s name is not disclosed
- the attempt is written to the audit trail
In a demonstration workspace, every member reaches every engagement; its use is limited to synthetic data by a condition of use, not by a technical control.
Between firms
Row-level security, enabled and forced on the tenants table and on every table in which the application’s database role reads or writes a firm’s rows, binds each row to the session’s tenant inside the database; that role is neither the tables’ owner nor exempt from row-level security.
Two further tables carry a firm’s id without row security, because the application’s role holds no privilege on either: each firm’s audit-chain head, written only by the audit trail’s own trigger, and the record that an AI result’s history was deleted, written only by a database function that takes the firm from the transaction’s own tenant setting. 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.
On pushes to the main branch and pull requests into it, continuous integration attacks one tenant’s records from another on a disposable database, as the application’s own database role, and runs the platform’s request handlers against a real PostgreSQL database with row-level security in force.
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 display name, and tells two accounts that share one apart by the order they joined the firm; the identifiers the hash chain is computed over are carried only in its companion chain file. In both files, e-mail addresses and recorded IP addresses in audit payloads are replaced with a marker, and each such row is flagged. 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 …
- under row-level security
- OBJECT STORE: Evidence files in a private store …
- an authenticated download proxy that checks the tenant on every request
- AI INFERENCE: Evidence documents for fact extraction …
- RETRIEVAL: None. The platform uses no vector index or retrieval store.
- COORDINATION: Rate-limit counters keyed by network address or tenant …
- no evidence files or audit trail
- EMAIL: Messages sent through this site’s contact form.
- IDENTITY
- Sign-in sessions and user profile data.
- DATABASE
- Engagement records, extracted evidence text, each account’s name and e-mail address, the record of each account’s acceptance of the demonstration terms, 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
- None. The platform uses no vector index or retrieval store.
- COORDINATION
- Rate-limit counters keyed by network address or tenant, with the store’s analytics feature turned off, 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.