# ACAM — the Apeiris Controls Assessment Method

**Version 0.1.0-draft · CC BY 4.0 · apeiris.ai**

ACAM is an open, versioned, signed standard for recording, computing, and verifying an
assessment of an organization's AI controls against the published Apeiris corpus (649 controls
across 12 domains, each with a published validation objective, required evidence, and blocking
posture). We are building it so that an assessment is a **deterministic, machine-verifiable
artifact** rather than a spreadsheet of opinions: two recorded sub-states per control (design /
operating) compute a rung on a closed ladder through a published nine-cell table and a numbered
fail-closed cap catalog; failures are first-class tokens that dominate every rollup; every
population names its enumeration basis; and any conforming verifier recomputes every verdict
from the recorded inputs.

ACAM is not an audit standard, an attestation standard, a certification scheme, or a
conformity-assessment scheme. Its quality intent: designed to exceed conventional assessment
deliverables in transparency, machine readability, provenance, and repeatability, while
explicitly not replacing independent evidence inspection or professional attestation.

## The release unit

| File | Role |
|---|---|
| `ACAM-SPEC.md` | The standard: scope, terms, the verdict model, workpaper rules, sampling/window/freshness/expiry, the cap catalog, rollups, dossier requirements, artifact classes, claim language, versioning. |
| `acam-core.json` | The machine-readable half: the enums, the nine-cell computation table, the cap rules, and the dominance rules as data. Recursively sorted keys, ASCII only — the canonical byte form a verifier consumes. |
| `ACAM-SAMPLING.md` | The sampling/window/freshness annex (work package A2): population definition requirements, the minimum-n table with its statistical assumptions and disclaimers stated verbatim, selection-method rules (seeded reproducible draws), deviation handling and extended testing, W1/W2, and the freshness re-cut table. Rules SAMP-01..30. Band keying: the entity-risk `risk_tier` derivation lives in `ACAM-ENTITY-RISK.md` (A5) and supersedes the annex's pre-A5 stopgap (D-A2-5). |
| `acam-sampling.json` | The annex's machine-readable half: the minimum-n and freshness tables, selection-method and deviation rules as data. Same byte discipline as `acam-core.json`. |
| `ACAM-CONFLICTS.md` + `acam-conflicts.json` | Annex (A5): the conflicts declaration — question set CONF-01..11, the bright-line prohibited-conflicts list (refusal, not disclosure), engagement-level aggregation math, duty-to-update mechanics, and the identity-binding pairing rule. |
| `ACAM-ENTITY-RISK.md` + `acam-entity-risk.json` | Annex (A5): the five ordinal signed entity-risk axes (aligned to `assurance-target.schema.json` where fields exist), the fail-closed defaults, and the risk-tier derivation feeding the A2 sampling minimums. |
| `acam-phrasebook.json` | Annex (A4 machine half): the prohibited-claims phrasebook — term/register/prohibition-class/replacement, the watch list, and the approved scoped phrasings; enforcement extension is the PHRASE-GATE control-core task. |

The files version together as one release unit; a dossier pins the ACAM version it was computed
under alongside its corpus version pin.
| `ACAM-EXCEPTIONS.md` | The exception-class taxonomy v1 (work package A3): the 12 machine-decidable classes of the ACAM Dossier Conformance Check, the two displayed-never-counted record types, the consequence-class derivation, the completion-status binding, and the count-rendering rule. |
| `acam-exceptions.json` | The taxonomy as data: per-class predicates (fields + condition), detecting procedure IDs, consequence classes, worked triggering examples (the B5 defective-dossier corpus seeds), record types, the completion-status binding, and the B1 field-requirements hand-off. |
| `acam-procedures.json` | The Conformance Check's published procedure-set skeleton (PROC-01..12) — versioned and hashed at release; the signed check record pins its version + SHA-256. |

These files version together; a dossier pins the ACAM version it was computed under alongside
its corpus version pin. The sampling annex (`acam-sampling.json`, minimum-n + freshness tables)
ships in a subsequent release (work package A2).

## Versioning and compatibility

- **SemVer.** Any change to an enum, a cap rule, the nine-cell table, a dominance rule, or an
  annex table is a new ACAM version, never an in-place edit. Breaking changes (removed or
  narrowed vocabulary, weakened fail-closed default, changed cap consequence) require a MAJOR
  bump.
- **12 + 12 month compatibility window.** An assessment window may span up to 12 months, and a
  dossier's verifier life extends 12 months past window end. Every MAJOR/MINOR release
  therefore remains supported for verification for **at least 24 months after its successor
  ships**, and a conforming verifier verifies any unexpired dossier under the dossier's pinned
  ACAM version. No in-flight dossier is orphaned by a release.
- **Pre-1.0:** the draft is founder-controlled with a written RFC-opening trigger; expect
  breaking changes between 0.x releases; the draft-decision register (ACAM-SPEC Annex B) lists
  the open calls.

## License and adoption

ACAM is published under **CC BY 4.0** — adoption-with-attribution. Anyone, including
competitors and assessment firms, may adopt, implement, extend, or embed ACAM, commercially or
otherwise, provided attribution to Apeiris (apeiris.ai) is preserved. The open standard is
never hobbled: the corpus, this standard, the dossier schema, and the verification tooling
remain complete, free, and sufficient for anyone to build and run their own full assessment.
What Apeiris operates commercially (workspaces, reviews) sells continuity, coordination, and
review — never the knowledge.

To adopt: implement the enums and rules in `acam-core.json`, validate against the
defective-dossier conformance corpus when it ships (work package B5), and cite the ACAM version
you implement. Corrections and challenges are invited — the standard's own discipline (every
normative rule names its enforcing procedure) applies to feedback: name the rule, the input,
and the divergence.