For auditors
For auditors and certifiers
Criteria you can cite and records you can check, without seeing the content. This page is for the person who has to sign off on how a company's AI decisions were made: an auditor, a certification body, a DPO or a buyer's reviewer.
1. The problem you are handed
- • There is no fixed checklist yet. The AI Act asks high-risk systems to keep logs (Art 12, Art 19) and deployers to keep them (Art 26), but the logging standards are still drafts. You still have to decide what counts as evidence.
- • An instruction is not evidence. "The model was told not to do that" says nothing about what happened on a given call. You need a record of each decision and the rule that made it.
- • You should not need the content. Copies of every prompt and answer create a second store of personal data, which is its own GDPR problem. You need to know which text a decision was about, not to read it.
2. What you can cite
ADCR, the AI Decision Check Record, is an open Rulebook for what an AI decision record must contain and prove under EU law. It is written to be named the way ISAE 3000 work names criteria: the company's system description cites a title, a version and conformance classes, and you test the records against the published vectors.
ADCR 0.1.0, classes <list>
Version 0.1.0 is in development, so cite the version you tested against. It becomes stable only after an implementation by people other than its editor passes the vectors. It is not a certification, nobody has endorsed it, and you are free to disagree with any rule in it.
The rule behind a decision
ADCR does not say which rules to apply. Each ComplyEdge record names the rule set that decided it (bundle_id and bundle_digest), and each rule carries the citation of the provision it applies, so a finding can point to a rule set version, a rule and an article. That rule set is separate from the Rulebook and open, with each rule's provision and approval status published under its digest.
3. What you can check
The ComplyEdge record of each decision
One record is written per checked call, in the ADCR form. It holds the decision and its basis, never the text. The main fields:
| Field | What you can check with it |
|---|---|
| record_id, occurred_at | Which decision, and when (UTC, milliseconds) |
| deciding_system | Which AI system was checked, as the company names it, and its version |
| verdict, action | What was decided, and what was done: passed, blocked or flagged |
| rules_fired | Which rules fired, each with its version, the provision as an ELI address and the text it cites |
| rule_set | The digest of the rules that decided, and where each rule is published |
| commitments | Which text it was about, as a value keyed per company (hmac-sha256-1), never the text |
| user, subject | Present only if the company sends them, and only as keyed pseudonyms |
| retention | How long the record is kept, and when it may be erased |
| chain | The record's place in the company's hash chain, set when it was written |
Annex C of the Rulebook maps every field to where ComplyEdge takes it from. Why each field exists and how long it is kept is in the DPO pack.
What it meets, and on what condition. On exports from its real write path, the Rulebook's reference verifier found classes Record, Law, Chain and Export met only for checks where the company sends the decision context (which AI system, the data categories, the purpose), and Oversight for reviews made in the dashboard. Anchor is met only with a test timestamp authority, and Rights is not met. The producer profile claims no class. Ask any producer for its conformance claim and check it yourself with the reference verifier.
A sample of decisions, against the company's own copy
The company keeps the event_id of every check (the record's record_id) next to its own copy of the prompt or output. For the samples you pick, it sends the pair to POST /v1/audit/verify (or the SDK's verify_input), and the answer says whether that record was about exactly that text. ComplyEdge never stores prompts or outputs, so the text comes from the company and is not kept.
POST /v1/audit/verify
{"event_id": "...", "text": "the company's copy"}
200 {"event_id": "...", "match": true, "text_hash_alg": "hmac-sha256-1"}
If the company has deleted its key, the records it covered can no longer be matched to any text, and the answer says when the key was deleted rather than returning a bare "no match". Step by step: how audit reconciliation works.
The whole record set, offline
Every plan can export its records, and in the ADCR form (GET /v1/audit/export?format=adcr) each record carries its chain fields: it joined a per-company hash chain at the moment it was written. On Enterprise the export also carries a completeness attestation that the period is complete, and the time stamps over the chain head. Every hour the chain head of each account that moved is time-stamped by Sectigo, an EU qualified time-stamp authority that receives only a hash, and kept in write-once storage. You check the export on your own machine with the Rulebook's reference verifier, with no account and no network call:
python3 -I conformance/adcr_verify.py export.json --trust-anchors anchors.pem --profile profile.json
It comes in the Rulebook download and needs Python 3 and nothing else for the chain checks. Checking a time-stamp signature also needs OpenSSL 1.1 or later and the trust anchors you pin yourself from the EU Trusted List; the LibreSSL that macOS ships cannot run that check, and the verifier says so rather than guessing. It does not look up whether a certificate was later revoked; check the provider's revocation list or the Trusted List history if you need that. The profile is the published producer profile. The verdict is verified, unverified (only informational findings, such as no time stamp yet), failed or refused (a required input such as the trust anchors was not given), with each finding named per record. Any edit, deletion or reordering of a record after it was written shows up this way.
Records written before the chain existed are labelled as such in the export rather than shown as verified.
4. The auditor view
Described, not yet built
A read-only view a company could grant to its auditor, showing the record set, the rules and the verification results for a chosen period, without access to the account or to any content. It does not exist yet. Today the same checks are done with the export and the verify call above.
5. What the record does not prove
- • It covers only the calls routed through the service. A call the company never sent leaves no record, so the record set is complete only for routed calls. Ask how routing is enforced.
- • The SDK fails open by default. With
fail_mode="open", if the service cannot be reached the call goes ahead without a check. A company that needs every call checked sets it to closed; ask which one is set. - • Tamper-evident means detectable. The chain makes an edit, deletion or reordering show up on verification; it does not make one impossible.
- • Integrity is not attribution. The hash chain proves the sequence was not altered after write; it does not prove who asserted a record. ComplyEdge does not sign records and applies no qualified electronic seal. Each hourly chain-head statement carries a ComplyEdge origin signature (ADCR CHN-05), checkable with the published public key of its region (US key, EU key); it is attribution only, never an eIDAS Art 35(2) seal. The qualified time stamp dates the chain head; it is not a seal by us.
- • What a block proves differs by rule. Some rules decide on the regulated act itself; others fire on text saying a control is missing. The rule set publishes which is which.
- • ComplyEdge is not an auditor or a certification body. It produces evidence for your review; the judgement is yours.
6. Downloads
- • ADCR 0.1.0, the Rulebook text, with the crosswalk to the law and the audit standards
- • ADCR 0.1.0 as a PDF, with a table of contents and page numbers
- • The Rulebook, schemas, verifier and test vectors, as one zip
- • Every file in 0.1.0, one by one
Check a record yourself
Download the Rulebook, run the vectors, and verify an export offline. No call with us required.