ADCR, the open Rulebook for AI decision records

1. Who it is written for

• • The auditor working under ISAE 3000 (IDW PS 861, BSI AIC4), who needs criteria that different practitioners apply the same way. 57 of the 62 rules that carry a MUST have a passing and a failing test vector; the coverage file names, rule by rule, the cases that exercise it and the five rules only the producer or the verifier can attest.
• • The certification body, which needs the schema and the retention period in writing. The producer's published profile is that document.
• • The data protection officer, who needs a log that touches employees and customers to hold no content and no names. Texts are kept as keyed commitments and people as keyed pseudonyms.
• • The standards committee member (prEN 18229-1, through UNE or NEN), who needs clauses that are already tested and tied to the law. The crosswalk maps each rule to the AI Act, the GDPR and Spain's AESIA guides, and the governance document sets out the route to a formal standard.
• • The engineer, who has to write the record from a gateway, a guardrail or an agent runtime. The schema and the interpretation guide say what to write.

2. Seven conformance classes

A producer, an export or a verifier claims one or more classes. Each class is a named set of rules.

3. How to cite it

• • In a system description: name the title, the version and the classes, as ADCR 0.1.0, classes <list>, naming only the classes the system meets, with the producer's profile URL.
• • As a conformance claim: Conforms to ADCR <version>, classes <list>, vector set <version>, run on <date>, implementation <identifier>. A third party must be able to reproduce it from the public vectors.
• • In each record: the field rulebook holds https://complyedge.io/rulebook/0.1.0. That address serves version 0.1.0 as published; a later version gets its own address and never overwrites it.

4. Check an export yourself

The reference verifier needs Python 3 and OpenSSL 1.1 or later, and nothing else: no account, no key, no network. From the unzipped download, with the timestamp trust anchors you trust and the producer's profile:

It checks every class. For class Anchor it parses each RFC 3161 token and checks its signature with OpenSSL against the trust anchors you pin; an export that carries tokens is refused without them. Given the profile, it also checks the export against it. It passes all 117 published test vectors in 9 suites, and their tokens are real ones from a test timestamp authority.

The text is licensed under the Community Specification License 1.0; the schemas, the vectors and the verifier under Apache-2.0.

5. Status and how it changes

A version is marked stable only when an implementation written by people other than the editor has passed the vectors for classes Record, Law and Chain. Until then it stays in development.

A change names the rule it changes, the clause of law or the audit criterion it rests on, and the vector it adds. Once a second implementation exists, the editor has no veto beyond any other contributor's. The working group, the decision process and the route towards a formal standard are in the governance document.

6. ComplyEdge, the first implementation

ComplyEdge writes its audit records in the ADCR form, and Annex C of the Rulebook maps each of its fields and reports what the reference verifier found on exports from its real write path. It meets Record, Law, Chain and Export only when the caller sends the decision context, Oversight for reviews made in its dashboard under the same conditions, Anchor only with the test timestamp authority, and Rights (including contest, notice, incident and opt-out) when those events are written through the audit API. Classification and standalone fallback events are written on Enterprise. Legal holds are written on Enterprise and listed in the producer profile. Its profile claims no class.

The rule set it runs

ADCR does not say which rules to apply; a record names the rule set that decided by its content digest. The rule set ComplyEdge runs is separate and open: one Rego rule per legal provision, with an ID that usually names the provision (rego-art5-1c-001 applies Regulation (EU) 2024/1689, Article 5(1)(c)); each rule's citation is the authority, because two IDs are kept from earlier versions. Each record carries bundle_id and bundle_digest, the version and digest of the rules that decided.

The rule set it runs today has 136 rules, 136 of them approved by a named reviewer, most through agent-delegated review, which each rule's approval line states. A rule that is not approved still decides, so its provision should not be read as checked. Every rule and its approval is published under the rule set's digest.

7. What it is not

• • It is not a certification. Passing its vectors says only that a verifier reproduces the expected findings on the published cases.
• • No regulator, standards body, auditor or certification body has endorsed or adopted it. It is not a harmonised standard and gives no presumption of conformity. EN 18229-1, EN 18229-3 and ISO/IEC 24970 are mapping targets once their texts are public.
• • It does not classify an AI system as high-risk, and it does not say which rules an organisation must apply.
• • Some questions are left to counsel, and the Rulebook names them: whether a qualified timestamp over the chain head covers every record beneath it, and whether destroying a key satisfies the GDPR right to erasure for the records that remain.
• • It is not legal advice.