# ADCR: the AI Decision Check Record rulebook

An open rulebook for the record an AI system's decision leaves behind: what it must contain, what it must prove, and how a third party checks it without seeing the content or the people.

- [SPEC.md](SPEC.md): the rulebook (Community Specification License 1.0).
- [schema/](schema/): JSON Schema for the record, the export and the producer profile (Apache-2.0).
- [conformance/](conformance/): the profile, the reference verifier, the vector generator and the published vectors (Apache-2.0).
- [GOVERNANCE.md](GOVERNANCE.md): working group, scope, decision process, route to a formal standard.
- [NOTICE.md](NOTICE.md): licences and attribution.
- [LICENSE-CODE.txt](LICENSE-CODE.txt): Apache License 2.0, for the schemas, vectors, generator and verifier.
- [NOTICES.md](NOTICES.md): register of acceptances, withdrawals and patent exclusion notices under the licence.

## What it is for

Five readers, one record:

- The auditor working under ISAE 3000 (IDW PS 861, BSI AIC4) needs criteria that different practitioners apply the same way. [conformance/COVERAGE.md](conformance/COVERAGE.md) lists every rule that carries a MUST and the test vectors that exercise it: 57 of the 62 have a passing and a failing case, and the other five are about how the producer works or how a verifier runs, which neither an export nor a profile can show, so they are attested.
- The certification body needs the schema and the retention period in writing. The producer's profile (SPEC.md section 10) is that document.
- The data protection officer needs a log that touches employees and customers to be content-free and pseudonymous. Sections 5 and 7 of the rulebook say how. A keyed pseudonym is still personal data under the GDPR (EDPB Guidelines 01/2025 on pseudonymisation).
- The standards committee member needs clauses already tested and tied to the law. Section 9 of the rulebook maps each rule to the law and the audit standards.
- The engineer needs to know what to write from a gateway, a guardrail or an agent runtime. The schema and the interpretation guide say what.

## Conformance classes

| Class | Proves |
|---|---|
| Record | every required field, content-free |
| Law | each decision bound to a checked legal provision (ELI address, rule set digest, approval) |
| Chain | records sequenced and linked at write time |
| Anchor | the chain head dated by an eIDAS-qualified timestamp |
| Oversight | human actions on the system's proposal, linked to it |
| Rights | decision mode, legal basis, notice, contest, explanation inputs |
| Export | offline verification that names its own gaps |

## Running the reference verifier

From the unpacked `adcr-0.1.0` folder (the zip on the version page):

```
python3 -I conformance/adcr_verify.py path/to/export.json --trust-anchors anchors.pem
python3 -I conformance/run_vectors.py
```

The verifier works offline, on the export alone, with the Python standard library, for every class. The one step it does not do itself is the signature of each RFC 3161 timestamp token: it runs `openssl ts -verify` (OpenSSL 1.1 or later) for that, at the token's own time, against the trust anchors you pin from an EU trusted list. Without a usable OpenSSL it reports the signature as not checked and returns `unverified`, never `failed`. An export that carries tokens and is given no trust anchors is `refused`.

The vectors carry real tokens from a test timestamp authority in `conformance/vectors/keys/`. The reference verifier passes all 117 cases in 9 suites.

## Status

Version 0.1.0, development. The editor claims no conformance class for its own implementation (`classes` stays empty). Measured 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 (RGT-01..07 plus REC-18 `opt_out`) when decisions about a person and contest/notice/incident/opt-out events are written through the audit API. Classification (REC-17) and standalone fallback (REC-18) are written via `POST /v1/audit/classification` and `POST /v1/audit/fallback`. Legal holds are written via `POST /v1/audit/legal-hold` and listed in the producer profile. SPEC.md Annex C has the mapping and the measurement. A version is marked stable only after an implementation by people other than the editor has passed the vectors.

## Relationship to the ComplyEdge rule set

ComplyEdge publishes two open artifacts, and only one of them is the rulebook. This directory is the rulebook: the record format. The other is the ComplyEdge rule set (the Rego rules, one per legal provision, with approval records), which is what the ComplyEdge service runs. A record written under this rulebook names a rule set by digest; the ComplyEdge rule set is one such rule set.