Auditor pack

This page is for auditors who test system-generated evidence: SOC 2 and ISO examiners, internal audit, regulators, and litigation-support teams. It covers how to get the full population, how to test it for completeness and accuracy, which obligations each artifact is designed to support, and a template a customer's qualified person can adapt. For AI reviewers, the machine-readable version is auditor.json.

1. Population, completeness and accuracy

Test	How	Where
Full population	Every proof each validator cluster has written, with its time, verdict and hash. Export it as CSV, or read the signed index directly.	Incidents → Export the full population · /evidence/hourly-proof/index.json · /evidence/hourly-proof-mr02/index.json
Completeness: nothing removed	Each proof carries the SHA-256 of the one before it, and the transparency log's Merkle tree must contain every earlier checkpoint. Removing, editing or reordering a proof breaks both.	Transparency log · verify_hourly_proofs.py
Completeness: nothing missed	Proofs are numbered without a gap, and every stretch longer than 45 minutes with no proof written is listed with its length.	Incidents → Completeness
Accuracy: the record is what was signed	Recompute each record's SHA-256 and check its Ed25519 signature against the pinned key. Signatures on the quorum certificates are checked against the member keys pinned in the signed index.	Auditor console · Verification run
Continuous monitoring, by you	Run the independent log monitor hourly on your own machine or in your own CI. It keeps its own copy of every checkpoint and raises ALARM on a fork or rewrite.	verify_tlog_monitor.py · GitHub Actions workflow
Point in time	Each transparency-log checkpoint is timestamped by two outside RFC 3161 timestamp authorities (FreeTSA, DigiCert), and the cain-mr-01 chain head is anchored daily in Sigstore Rekor.	Transparency log · Rekor anchors
Customer decision records	The customer exports a record with /fabric/decisions/<id>/signed-record and runs verify_decision_record.py. It checks ENCODING, DIGEST (recomputed), KEY and SIGNATURE. A changed verdict fails DIGEST, and a changed verdict with a recomputed digest fails SIGNATURE.	Verify your own evidence
Change history of the evidence pipeline	The repository commit and deployment that produced the current state, the dated changelog, and the known-limitations list.	/now.json · changelog

2. Control-to-evidence map (self-assessed)

Obligation or framework	What it asks for (summary)	Evidence here, designed to support it
EU AI Act Art. 12: record-keeping	Automatic logging that allows traceability (risk situations, post-market monitoring, deployer monitoring)	Signed, hash-chained decision records per agent action; per-tenant listing and export; transparency log
EU AI Act Art. 19 and Art. 26(6): log retention	Providers and deployers keep logs for at least six months	Append-only records with no deletion path; retention is set per deployment and is not yet a configurable control on this site
EU AI Act Art. 72: post-market monitoring	Systematic collection and analysis of performance data, including interaction with other AI systems	Continuous verification every 15 minutes (failures included), incident history from signed proofs, agent-run (trajectory) views
EU AI Act Art. 73(6): serious incidents	Do not alter the system in a way that affects later evaluation before informing authorities	Records cannot be edited without detection (hash chain, signatures, checkpoints, outside timestamps); a dedicated "frozen snapshot" control is not built yet
NIST AI RMF 1.0: MEASURE and MANAGE	Track, measure and manage AI risks with documented evidence	Signed claims register with statuses and limits, tamper lab, live decision trials, known-limitations list
US FRE 902(13)/(14)	Self-authentication of machine-generated records and copies via certification by a qualified person (hash comparison)	Published SHA-256 for every file, signed records, the template below

3. Certification template for your qualified person (FRE 902(13)/(14))

CERTIFICATION OF RECORDS GENERATED BY AN ELECTRONIC PROCESS OR SYSTEM
(Fed. R. Evid. 902(13) / 902(14)), DRAFT FOR COUNSEL REVIEW

I, [full name], certify as follows:

1. I am [title] at [organization]. I am familiar with how [organization] uses the CAIN-42 runtime
   and how its decision records are produced and kept, and I am qualified to make this certification.

2. The attached records ([list: decision ids / bundle file names]) were produced by the CAIN-42 runtime
   for tenant [tenant id] in the regular course of [organization]'s activity.

3. Collection. On [date, time, timezone] I downloaded each record from
   [URL, e.g. https://cainstudio.online/fabric/decisions/<id>/signed-record] using our API key.
   I computed its SHA-256 at collection: [hash per record, or attached hash list].

4. Verification. On [date] I ran the published verifier verify_decision_record.py
   (SHA-256 of the verifier file: [hash]) against each record with the decision-signing key fetched from
   [URL] (key id [id]). It reported ENCODING, DIGEST, KEY and SIGNATURE as PASS for every record.
   [For evidence bundles: verify_keystone.py with the issuer key pinned by fingerprint [SHA256:...].]

5. Before this certification was signed, I computed the SHA-256 of each copy again and it matched the
   collection-time hash in paragraph 3. The copies are therefore identical to the records as collected.

6. [Optional] The records fall inside transparency-log checkpoint [origin, size, root] of
   clawx.click/tlog, timestamped by [TSA] at [time] (token attached).

I certify under penalty of perjury that the foregoing is true and correct.

Signature: ______________________   Date: ____________   Place: ____________

Copy the text above, or use auditor-902-template.txt.

4. What an auditor cannot get here yet

• An independent third-party audit report. None has been completed.
• Independent witness cosignatures on the transparency log. There are 0 so far, and the log has not yet been accepted by a witness network.
• A SOC 2 report, an ISO/IEC 42001 certificate, or eIDAS qualified timestamps. The timestamps here are RFC 3161 tokens from FreeTSA and DigiCert.
• Validators run by anyone other than FIRME AI CORPORATION.

Something here doesn't hold up? Report it. Corrections are published as new, superseding evidence, never as silent edits.