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

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_atWhich decision, and when (UTC, milliseconds)
deciding_systemWhich AI system was checked, as the company names it, and its version
verdict, actionWhat was decided, and what was done: passed, blocked or flagged
rules_firedWhich rules fired, each with its version, the provision as an ELI address and the text it cites
rule_setThe digest of the rules that decided, and where each rule is published
commitmentsWhich text it was about, as a value keyed per company (hmac-sha256-1), never the text
user, subjectPresent only if the company sends them, and only as keyed pseudonyms
retentionHow long the record is kept, and when it may be erased
chainThe 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

6. Downloads

Check a record yourself

Download the Rulebook, run the vectors, and verify an export offline. No call with us required.