# Governance of the ADCR rulebook This document is the Governance.md and the Scope.md that the Community Specification License 1.0 (`LICENSE-SPEC.md`) names: it sets out the Working Group, the Scope, how a version becomes an Approved Specification, and how notices are filed. ## Working Group Name: ADCR Working Group. Editor: ComplyEdge, as the first implementer. The editor's role is to maintain the text, run the vectors and publish releases; it has no veto beyond that of any other contributor once a second implementation exists. ## Scope The Working Group develops a specification of the record written when an AI system's request, output or action is checked against a rule and a verdict is reached, by a machine, a person or both; the integrity properties of that record; and the material (schema, vectors, verifier, interpretation guide) a third party needs to evaluate such records against legal and audit criteria in the European Union. Out of scope: the classification of AI systems, the content of any rule set, model training records, infrastructure logs, and the content of checked texts. ## Decision process - Changes are proposed as GitHub issues in the public repository [ComplyEdge/complyedge](https://github.com/ComplyEdge/complyedge/issues), titled `Rulebook change: `. Each proposal names the rule it changes, the clause of law or the criterion it rests on, and the vector it adds or changes. - A change is accepted when the editor and at least one other implementer approve it. Until a second implementation exists, the editor records its own approval and the reason in the issue. The editor makes accepted changes in the next version; a published version is never edited. - A major version requires a public comment period announced in the repository before merge. - The prose of SPEC.md governs. The vectors are evidence of how a rule is read, not a substitute for it: a MUST that no vector exercises is still binding, and the missing vector is a gap to close (conformance/COVERAGE.md lists them). A dispute about a reading is raised as an issue in the same repository; it is settled by a change to the prose and, where possible, a new vector that fixes the reading. ## Versioning and stability Semantic versioning. Stability levels: `development` (any rule may change at a minor version), `stable` (rules change only at a major version; see SPEC.md PRF-04 for the stability condition). The schema URL carries the version. ## Contributions Every contributor accepts the Community Specification License 1.0 for contributions to the specification text and the Apache License 2.0 for contributions to the schema, vectors and verifier, by submitting a contribution. Patent terms are those of the Community Specification License 1.0, sections 2 and 3. ## Draft and Approved Specifications A version published at stability `development`, including 0.1.0, is a Draft Specification under the licence. A version published at stability `stable` is an Approved Specification under the licence (9.2). The stability of each version is stated in its SPEC.md. ## Notices The licence's Notices.md file is `NOTICES.md` in this directory. An implementer's acceptance (licence 2.1.3.3), a contributor's withdrawal (2.3) and a patent Exclusion Notice (3.1, 3.2 and 9.7) are made, under the licence, by a commit to `NOTICES.md`. The specification's source repository is not public, so the editor makes that commit: send the notice as a GitHub issue in the public repository [ComplyEdge/complyedge](https://github.com/ComplyEdge/complyedge/issues), titled `Rulebook notice: acceptance`, `Rulebook notice: withdrawal` or `Rulebook notice: exclusion`, with the content the licence requires for that notice. The editor commits it to `NOTICES.md` verbatim, with the issue link and the date the issue was opened. Under the licence the notice is made on the date of that commit. The register published with each release copies `NOTICES.md` as it stands. ## Route to a formal standard The editor's stated path is: an open profile with two independent implementations, then a liaison with the national mirror committees of CEN-CENELEC JTC 21 so that the record vocabulary can be mapped onto EN 18229-1 (logging) and EN 18229-3 (human oversight) when they are published, and a mapping annex to ISO/IEC 24970 when its text is public. The field names in this rulebook are deliberately neutral until then. ## Independence The rulebook is not a certification. Reading it does not make a reader an auditor, and passing its vectors says only that a verifier reproduces the expected findings on the published cases.