# ACAM — Apeiris Controls Assessment Method **Version 0.1.0-draft** · Status: **draft for review** (pre-1.0; see §17 governance) · License: **CC BY 4.0** (adoption-with-attribution) · apeiris.ai > Design of record: `COVERAGE_ASSESSMENT_PLAN.md` v4 (§0 decision 8, §2–§7, §10, §11, §13, §14). > Blocker dispositions: `requirements/VALIDATION-FINDINGS-2026-08-06-acam-round3.md` (B1–B11). > Machine-readable half: `acam/acam-core.json` (the enums, the nine-cell table, and the cap > catalog as data). The exception-class taxonomy (A3) lives in `acam/ACAM-EXCEPTIONS.md` + > `acam/acam-exceptions.json` + the procedure register `acam/acam-procedures.json`. All of > these are one release unit and version together. > > **Drafting discipline (normative for this document itself):** every normative sentence in this > standard must pass the **noun-vs-procedure test** — it must name the procedure, schema > constraint, or computable rule that distinguishes the good state from its absence. A rule that > names only a desirable state is `documented`, not `implemented`. Each normative clause below > therefore carries an **Enforcement:** line naming its mechanism. Where the mechanism does not > exist yet, the line says so explicitly (three-column discipline: accepted / specified / > implemented — this v0.1-draft is column two for every rule; column three is tracked in > ASSESS-11 and the WS-B verifier work). --- ## Part I — Front matter ### 1. Scope ACAM (the Apeiris Controls Assessment Method) defines how an assessment of an organization's AI controls against the published Apeiris corpus is **recorded, computed, and verified**: - a closed **verdict vocabulary** (the ladder, its sub-states, and its failure tokens) with a deterministic computation rule (§6–§8); - **workpaper (documentation) requirements** including mandatory procedure blocks (§10); - **sampling, window, freshness, and expiry rules**, all fail-closed (§11–§12); - a numbered **cap catalog** — every fail-closed cap as a computable rule (§13); - **rollup and dominance rules** for obligations, domains, and scorecards (§14); - **dossier requirements** — identity, conflicts, review discipline, composites (§15); - **artifact-class rules** including global outcome invariance (§16); - **claim-language rules** — the approved and prohibited registers (§9, §16.4); - **versioning and compatibility** (§17). **What ACAM is not.** ACAM is not an audit standard, an attestation standard, a certification scheme, or a conformity-assessment scheme, and an ACAM dossier is none of those things. ACAM records the *state of controls and their evidence*; it does not express an opinion or a conclusion in the sense of the professional attestation literature. The quality intent of the program is stated once, verbatim, and applies everywhere (design of record §10): > Designed to exceed conventional assessment deliverables in **transparency, machine > readability, provenance, and repeatability**, while explicitly **not replacing independent > evidence inspection or professional attestation.** The self-serve gap — interviews, evidence inspection, sampling verification, professional skepticism, professional accountability — is declared in the Assurance Basis tiers (§9) and in mandatory cover language; it is never papered over. **Criteria availability.** ACAM's evaluation criteria are *available criteria* in the sense the attestation literature requires of any procedures-based engagement: the corpus (649 controls, each with a published `validation_objective`, `evidence_required[]`, and `blocking_effect`), this standard, and the machine-readable `acam-core.json` are published, versioned, signed, and free (CC BY 4.0). Any party can obtain the criteria, reperform the computation, and verify the signatures without a commercial relationship. Enforcement: the corpus manifest signature + `acam-core.json` published under the same key discipline; the deterministic verifier (WS-B B4) recomputes every verdict from the recorded inputs. ### 2. Conformance Four things can conform to ACAM: 1. **A dossier** conforms when it validates against the published dossier schema (WS-B B1) and every computed rung in it equals the rung the deterministic verifier recomputes from its recorded sub-states, workpapers, and declarations under §6–§13. Enforcement: schema validation + verifier recomputation; a mismatch is a conformance failure, not a warning. 2. **A verifier** conforms when it reproduces the reference results on the published defective-dossier test corpus (WS-B B5) — every planted defect detected, every clean specimen passed, byte-identical verdict output. Enforcement: the public test corpus is the conformance suite. 3. **An assessor tool** conforms when the dossiers it emits conform (1) and when it renders the claimed-vs-effective rule (§8), Assurance Basis co-rendering (§9), and failure-token dominance (§7.3) as specified. Enforcement: emitted-dossier conformance + the rendering rules, which are themselves verifier-checkable because the rendered values are recorded fields, not presentation-layer inventions. 4. **A review record or validation log** conforms to its artifact-class rules in §16. Enforcement: artifact-class schemas (WS-B B3) + the outcome-invariance checks in §16.1. Normative keywords: **must**, **must not**, **may** are used in their ordinary strict sense. Every "must" in this standard is bound to an Enforcement line; a "must" without one is a defect in this standard and should be reported. ### 3. Terms - **Control** — a published Apeiris corpus control, addressed by canonical URI (`apeiris:///controls/-`), pinned by corpus version and content hash. - **Rung** — a value of the closed ladder vocabulary (§6). - **Sub-state** — one of the two recorded per-control evaluation axes, `design` and `operating` (§7.1). - **Failure token** — `tested-exception`, `ineffective`, or `evaluation-impaired`: terminal tokens that are not rungs and dominate every aggregate they touch (§7.3). - **Blocking control** — a control whose `blocking_effect` is `blocks-deployment` or `blocks-runtime-action`. - **Workpaper** — the per-evidence-item documentation record of §10. - **Procedure block** — the mandatory `procedure_performed` record inside a workpaper (§10.1). - **Dossier** — the signed assessment artifact: scoping and methodology header + workpapers + computed verdicts, expressed as an AP-48 overlay targeting canonical control URIs and content hashes (§15.1). - **Draft dossier** — a schema-valid dossier with `status: draft`: the save file, the hand-off file, and the final artifact are one format (design of record §0 decision 8). - **Assessment window** — the mandatory scoping interval (start, end; ≤ 12 months) that bounds operating evidence (§11.3). - **Assurance Basis** — the engagement-metadata tier S/F/R (§9). It is not a property of any control's state and is never encoded in a rung token. - **Claimed rung / effective rung** — the self-selected rung versus the rung the verifier computes from evidence (§8). - **Population-governing control** — a control whose validation objective is evaluated over a population of items (accounts, models, agents, pipelines, changes, incidents), triggering the §11.1 declarations. - **Corpus currency** — the relation between the corpus version a dossier pins and the current published corpus release (§12.2). ### 4. The population-completeness principle Stated once, applied everywhere (design of record §6): > **Population completeness applies to evidence samples, to the criteria set (corpus > versions), to obligation-control relations, and to scope denominators.** Any computation > whose denominator is a population must declare how that population was enumerated, from what > system of record, with what basis; and any future trend or comparison feature must restate > across corpus versions or mark the comparison non-comparable. The four instantiations and their enforcement mechanisms: | Population | Declaration | Enforcement | |---|---|---| | Evidence samples | §11.1 sampling declarations incl. `population_enumeration_basis` | CAP-06, CAP-14, CAP-15; exception classes 4–6 | | Criteria set (corpus) | corpus version + manifest hash pinned in the dossier header | §12.2 currency stamping; verifier state computation | | Obligation-control relations | `sufficiency_relation` per edge; per-framework curation-coverage threshold | CAP-20, CAP-21 | | Scope denominators | mandatory scope enumeration + `out_of_scope_with_rationale` + absolute numerator/denominator display | §14.2 scorecard constraints; the §16.3 population-reconciliation exception class | --- ## Part II — The verdict model ### 5. Design intent The verdict model restores the design-effectiveness / operating-effectiveness boundary (the Type I / Type II distinction) that a single linear maturity scale erases, and it makes failure first-class: a control that was tested and did not hold must never be indistinguishable from a control that was never tested. ACAM states plainly that this vocabulary is standard design-/operating-effectiveness practice; the contribution is deterministic machine enforcement across an open AI corpus (design of record §2). ### 6. The ladder The closed rung vocabulary, in strict order: ``` not-covered < mapped < documented < design-effective < tested < effective ``` | Rung | Meaning | The procedure that distinguishes it from the rung below | |---|---|---| | `not-covered` | The control is in scope and nothing places it higher. | Default state; requires no record. | | `mapped` | The control is in scope and acknowledged (a claim exists), but no workpaper satisfies §10. | Presence of the control in the declared scope with a claimed state; verifier finds no qualifying workpaper. | | `documented` | ≥1 workpaper exists whose procedure block is satisfied (§10.1) with a non-empty `observation`, and the evidence is admissible under §11.3–§11.4. | Verifier evaluates procedure-block completeness + admissibility. Assertion-only evidence never reaches this rung (CAP-01). | | `design-effective` | `design = evaluated-sound` recorded with its supporting workpaper(s). | The design sub-state and its evidence reference; nine-cell table row 2 (§7.2). | | `tested` | `design = evaluated-sound` and `operating = tested-held`, but one or more effectiveness requirements (sampling minimum, window, freshness, reliability floor) is not demonstrated. | The nine-cell table cell (sound, held) with ≥1 cap from §13 applied. `tested` is the honest intermediate: operated and held, effectiveness not yet demonstrated. | | `effective` | `design = evaluated-sound`, `operating = tested-held`, and **no** cap in §13 applies: sampling meets the published minimum, all operating evidence is in-window and fresh, and the reliability floor (§10.2) is met. | The nine-cell table cell (sound, held) with the full cap catalog evaluating to no-cap. | Enforcement: the rung is **never recorded directly**. It is computed by the deterministic verifier from the recorded sub-states, workpapers, and declarations via the nine-cell table (§7.2) and the cap catalog (§13). A dossier that records a rung the verifier does not recompute fails conformance (§2.1). *(Mechanism: WS-B B4 verifier — specified here, not yet implemented.)* ### 7. Sub-states, the nine-cell computation table, and failure tokens #### 7.1 The two recorded sub-states Per control, two sub-states are recorded (each with the workpaper references that support it): - **`design`** ∈ { `not-evaluated`, `evaluated-sound`, `evaluated-deficient` } — has the control's design been evaluated against the control's published `validation_objective`, and was it found capable of achieving that objective if operated as designed? - **`operating`** ∈ { `not-tested`, `tested-held`, `tested-exception` } — has the control's operation been tested within the assessment window, and did it hold? A sub-state above its default (`not-evaluated` / `not-tested`) must cite ≥1 workpaper whose procedure block is satisfied; a sub-state with no qualifying citation is reset to its default by the verifier (fail-closed). Enforcement: schema requires the citation array; the verifier checks each cited workpaper against §10.1 before honoring the sub-state. #### 7.2 The nine-cell computation table (all nine cells defined) The computed result for every (design × operating) combination. "Floor" means the documentation-derived rung (`not-covered` / `mapped` / `documented` per §6), which can never exceed `documented`. | # | `design` | `operating` | Computed result | Definition of the cell | |---|---|---|---|---| | 1 | `not-evaluated` | `not-tested` | **floor** (≤ `documented`) | Nothing has been evaluated or tested. The rung is whatever the documentation state supports: `not-covered` with no record, `mapped` with a claim but no qualifying workpaper, `documented` with ≥1 satisfied procedure block. | | 2 | `evaluated-sound` | `not-tested` | **`design-effective`** | The Type I state: design evaluated and found sound; operation not yet tested. Distinct from `documented` by the recorded design sub-state and its evidence; distinct from `tested` by the absent operating test. | | 3 | `evaluated-deficient` | `not-tested` | **`ineffective`** | A deficient design cannot be operated into effectiveness. The failure token issues without waiting for an operating test; the deficiency carries its consequence classes (§7.4). | | 4 | `not-evaluated` | `tested-held` | **floor (≤ `documented`)** | An operating test result exists but the design was never evaluated. The result is recorded and preserved, but it cannot raise the rung past the missing design evaluation: a held test on an unevaluated design does not establish that the design achieves the objective. Fail-closed against rung-skipping. *(Draft decision D-1, flagged for founder review: the alternative — a distinct `operated-unevaluated` marker — was rejected to keep the ladder closed.)* | | 5 | `evaluated-sound` | `tested-held` | **`effective`**, reduced to **`tested`** by any applicable cap | The success path. The cap catalog (§13) is evaluated; if no cap applies the rung is `effective`; if one or more caps apply the rung is `tested` (or lower, if the cap names a lower ceiling). | | 6 | `evaluated-deficient` | `tested-held` | **`ineffective`** | The design is deficient; an operating test that held exercised a control that cannot, by design, achieve its objective. The held result is recorded; the token is `ineffective`. | | 7 | `not-evaluated` | `tested-exception` | **`tested-exception`** | An exception was observed. Exceptions issue regardless of design-evaluation state; nothing masks them. | | 8 | `evaluated-sound` | `tested-exception` | **`tested-exception`** | Sound design, failed operation: the canonical operating exception. | | 9 | `evaluated-deficient` | `tested-exception` | **`ineffective`** (operating exception retained) | Both axes failed. The token is `ineffective` (the design-level failure is the stronger statement); the operating exception is retained in the workpapers and **still participates in rollup dominance** (§7.3) — it is never absorbed. | Enforcement: this table ships as data in `acam-core.json` (`nine_cell_table`); the verifier implements it as a pure lookup, then applies the cap catalog. Both the table and the caps are covered by the defective-dossier conformance corpus (a specimen per cell). #### 7.3 Failure tokens and dominance Three failure tokens exist. They are **not rungs** — they are terminal tokens outside the ordered ladder that dominate every aggregate they touch: - **`tested-exception`** — an operating test was performed and the control did not hold (cells 7–8), or a sampling deviation on a blocking control forces it (CAP-08). - **`ineffective`** — the design is deficient (cells 3, 6, 9). - **`evaluation-impaired`** — the evaluation could not be completed: access denied, evidence nonexistent, a third party refused, or a scope limitation prevented the procedure. `evaluation-impaired` is recorded as a per-control condition with a mandatory `impairment_reason` (closed enum: `access-denied`, `evidence-nonexistent`, `third-party-refused`, `scope-limitation`) and **dominates rollups exactly as exceptions do** — an impaired evaluation is never rendered as any rung, and never as progress. Dominance rules (machine-evaluable; shipped as `dominance_rules` in `acam-core.json`): - **DOM-1** — a recorded exception (`tested-exception`) on a blocking control dominates every rollup it touches (obligation, family, domain, scorecard); it is never masked by a sibling's higher rung. Enforcement: rollup operators treat the exception as an absorbing element; the verifier recomputes every rollup and fails conformance on a masked exception. - **DOM-2** — `evaluation-impaired` dominates identically to `tested-exception` in every rollup. Enforcement: same operator path; the impaired condition is an absorbing element. - **DOM-3** — exceptions are append-only and immutable. **Remediation is an append-only sub-record rendered alongside the exception, never a rung**: no state transition erases a recorded failure. Enforcement: schema — the exception record has no mutable status field; a remediation sub-record references it; the verifier rejects a dossier whose exception count decreases across versions of the same engagement without a restatement record. - **DOM-4** — a failure token dominates any computed rung in any aggregate: an aggregate containing a failure token must surface it; a rendering that shows only the rung distribution without the failure-token counts fails the rendering rules (§14.2). Enforcement: the scorecard schema carries mandatory failure-token count fields. #### 7.4 Deficiency consequence classes (severity discipline) Failure tokens carry consequence, never assessor-assigned severity. Severity is expressed as **counted, published classes derived from procedures** — which procedure fired, on which `blocking_effect` class of control, with what population consequence. ICFR vocabulary (deficiency / significant deficiency / material weakness) and the word "material" are prohibited: ACAM has no ICFR machinery and must not borrow its register (§16.4). Enforcement: the deficiency record's `consequence_class` is a closed enum keyed to procedure IDs — the derivation and the eight-value enum are published in `acam/ACAM-EXCEPTIONS.md` §3 (+ `acam-exceptions.json` `consequence_classes`, A3); free-text severity fields do not exist in the schema. ### 8. Claimed vs effective rendering (the one-scale rule) The ACAM ladder is the single assessment vocabulary on every surface (design of record §0 decision 8). Any surface that lets a user self-select a state records it as a **claimed rung**; the verifier computes the **effective rung** from evidence. The two are distinct recorded fields and both are always rendered: - **R-1** — a claimed rung with no qualifying evidence renders its effective state as **`mapped`**, with the claim retained visibly beside it (never silently discarded, never silently honored). This is the assertion-only cap made ambient: mapped ≠ satisfied, taught by the UI. Enforcement: CAP-22; the dossier schema records `claimed_rung` and `effective_rung` as separate fields; a conforming tool renders both; the verifier recomputes `effective_rung` and ignores `claimed_rung` in every computation. - **R-2** — legacy scales (the six-level maturity scale, four-option family ratings) migrate by the published deterministic mapping (`none → not-covered`, `initial → mapped`, `developing/defined → documented`, `managed → tested` (claimed), `optimizing → effective` (claimed)); migrated values arrive as **claimed** rungs only. Enforcement: the migration map ships in `acam-core.json` (`legacy_migration`); storage keys are versioned; migrated state never populates `effective_rung`. ### 9. Assurance Basis (Tier S / F / R) The Assurance Basis records **who performed the assessment under what engagement conditions**. The axis is named Assurance Basis; it is engagement metadata, not a control state, and not an axis of anything the prohibited-terms register covers (§16.4). | Tier | Name | Meaning | |---|---|---| | `S` | Self-assessed | The organization performed its own assessment. | | `F` | Facilitated | An external assessor of record ran the process; the assessor's identity is recorded and bound (§15.2); evidence statements remain the organization's. | | `R` | Apeiris-reviewed | A signed review-lane record (§16.3) attaches to the dossier. | Rules: - **AB-1** — `assurance_basis` is a **required field inside the signed payload**. A dossier without it fails schema validation. Enforcement: schema `required`. - **AB-2** — a conforming verifier or renderer **must refuse to render any verdict without co-rendering its basis**. Enforcement: the verifier's output object carries the basis on every verdict node (not only the header), so a JSON projection that keeps the verdict keeps the basis; the rendering conformance check (§2.3) tests a basis-stripped projection and requires refusal. - **AB-3** — the basis is **never baked into the verdict token** (control state ≠ engagement metadata). No rung token variant encoding a tier exists in the closed vocabulary. Enforcement: the closed enums in `acam-core.json` are the complete token set; the contract gate rejects additions. - **AB-4** — `effective` under Tier S is **self-attested effectiveness** and is labeled as such wherever rendered. Enforcement: the renderer rule is checkable because the label is computed from two recorded fields (`effective_rung` + `assurance_basis`), both present in every projection per AB-2. --- ## Part III — Workpapers (documentation) ### 10. Workpaper requirements Per evidence item, beyond existence/location/type/freshness/owner, the workpaper records: #### 10.1 The procedure block (mandatory) - **`procedure_performed`** — closed enum: `inspection` · `observation` · `inquiry` · `reperformance` · `recalculation` · `confirmation` · `none-assertion-only` — **or** a machine-attested execution-log reference (`execution_log_ref`), so automated controls are first-class and human tickmarks are not forced onto CVT-style automated tests. Exactly one of the enum value or the log reference must be present. Enforcement: schema `oneOf`. - **`performed_by`**, **`performed_on`** — required. Enforcement: schema `required`. - **`observation`** — the recorded result of the procedure; **required non-empty for any control at `documented` or above**. Enforcement: CAP-02; verifier checks before honoring a workpaper. - **`exceptions_noted`** — required present (may be an empty list); a noted exception feeds the operating sub-state and the dominance rules. Enforcement: schema `required`. - **All-assertion-only evidence ⇒ the control caps at `mapped`, deterministically.** A control whose every workpaper has `procedure_performed: none-assertion-only` has no evidence in the ACAM sense. Enforcement: CAP-01; exception class 7 (`assertion-only-uncapped`) fires in the review lane when a dossier failed to apply it. - **`ipe_basis`** — required on every automated-class evidence item (and on the scoping system-of-record count, §11.1): how the completeness and accuracy of the entity-produced information the procedure relied on was established. Enforcement: schema conditional requirement; exception class 9 (`ipe-basis-absent`) fires on omission. - **`component_operator`** — required where the evidence concerns a component operated by another party: `self` · `subservice-carved-out` · `subservice-inclusive`. Boundary declarations feed the digest rules (§10.3) and the scope-limitation record types. Enforcement: schema conditional requirement; consistency with `digest_unavailable_reason` checked by the verifier (CAP-17). #### 10.2 Appropriateness (reliability classes) Verification classes carry a reliability rank: **automated > third-party > human-contemporaneous > attested**. Rules: - **AP-1** — controls whose `validation_objective` concerns operation require **≥1 automated- or third-party-class item** among their operating evidence. A control failing this floor cannot demonstrate operating effectiveness. Enforcement: CAP-03 (the reliability floor); exception class 8 (`reliability-floor-breach`). - **AP-2** — interview notes may never be the sole support on a blocking control, and this rule is non-overridable (§11.4, CAP-12). #### 10.3 Evidence digests (optional, strongly incentivized) - **`evidence_digest`** — a salted/HMAC-per-dossier SHA-256 of the actual artifact, computed locally (in-browser for the reference tooling); nothing transmitted; binds each claim to the exact bytes as of assessment time. Marketed as commitment / chain-of-custody support, never as "verification". Enforcement: the claim-language register (§16.4) prohibits "verified" phrasing for digests; the digest is verifier-checkable only against a re-presented artifact. - **`digest_scope`** — closed enum: `full-artifact` · `chunked-merkle` · `metadata-only`. **`metadata-only` never counts toward gating coverage** (CAP-16). - **`digest_unavailable_reason`** — required whenever `digest_scope: metadata-only`; closed enum: `third-party-custody` · `api-only-access` · `subservice-carved-out` · `legal-restriction`; must be consistent with the item's `component_operator` (CAP-17). - **Coverage semantics (two metrics, one fraction).** Content-integrity coverage (bytes committed via `full-artifact`/`chunked-merkle`) is reported **separately** from inventory/metadata coverage; the commitment unit is defined per evidence item. Coverage renders as an explicit **three-part fraction** — hashed / metadata-with-declared-reason / unaccounted — and the three parts summing to the declared evidence inventory is a **schema constraint, not a rendering convention** (CAP-19). Signed external provider manifests, partition-level merkle roots, reproducible registry IDs, and risk-based sampled rehashing are admissible commitment forms. Exception class 10 (`digest-scope-miscount`) **fires in both directions** — over-counted and under-counted coverage alike. - **`evidence_digest_coverage`** is reported on the dossier cover; the review lane gates on a minimum coverage for blocking controls (the numeric threshold is a calibration deferred to a versioned procedure-set release — the v0.1 register `acam/acam-procedures.json` does not yet set it; the taxonomy and predicates are A3, published). Boundary-limited systems (provider-held bytes) are **admitted with a scope-limitation record and a verdict cap** (CAP-18), never silently excluded from the lane. #### 10.4 Contradictory or limiting observations **`contradictory_or_limiting_observations`** — required **present-or-nil per control**: either ≥1 recorded observation that cuts against the verdict, or an explicit nil record. A dossier of hundreds of controls with zero limitations anywhere is itself a reviewable finding ("400 controls, zero limitations" is the finding); the review lane targets all-nil dossiers. Enforcement: schema requires the field on every control record (CAP-04 — absence fails validation); the review-lane procedure set includes an all-nil screen. #### 10.5 Compensating-control links **`compensating_control`** — a control→control link with a **mandatory rationale**. A compensating link **adjusts recommendation priority, never the verdict**, and is surfaced in rollups; it exists to protect the not-applicable path from abuse (an N/A'd or failed control with a claimed compensator stays visible with its compensator named). Enforcement: schema requires `rationale` on the link; the verifier's verdict computation has no code path that reads compensating links; the rollup renderer lists them. --- ## Part IV — Sampling, window, freshness, expiry, currency (all fail-closed) ### 11. Sampling and time rules #### 11.1 Mandatory sampling declarations On every population-governing control, the dossier must declare: - **population definition** (what the items are); - **`population_enumeration_basis`** — the keystone field: the system of record + the exact query/export + the date. The basis itself is a closed enum (B2): `provider-api-export` · `registry-export` · `cmdb-export` · `financial-system-tie` · `interview-assertion` · `estimate`; - **`ipe_basis`** on the system-of-record count wherever the count is automated (§10.1); - **≥1 independent corroborating count** from a different source where obtainable; where not obtainable, or where the basis is `interview-assertion`, the affected controls cap at `documented` (CAP-14, fail-closed); - **population size** · **control frequency** · **selection method** (closed enum: `full-population` · `random` · `systematic` · `haphazard` · `judgmental-with-rationale` · `management-selected`) · **sample size** · **deviations found** · **deviation disposition**; - **`variance_reason`** — wherever a declared count differs from a reconciled or corroborating count: a closed enum bound to computed rules (draft values, finalized in A2: `timing-difference` · `scope-boundary-difference` · `decommissioned-not-yet-removed` · `provisioning-in-flight` · `duplicate-record` · `source-refresh-lag` · `classification-difference`), each **quantitatively accounting for its share of the variance** with a linked evidence reference. Free text may accompany a typed variance, never substitute for one and never suppress the computation. The same structured-variance discipline applies to sample-size and coverage deviations (the escape hatch must not relocate). An absent, out-of-enum, arithmetically-unaccounted, or unevidenced variance fires exception class 4 (`population-reconciliation`) and is treated as a missing enumeration basis (CAP-15). The dossier cover carries the exact line: **"Population declarations internally consistent; completeness basis: ``; variances: N, all typed."** — stating exactly what was tested (internal consistency + declared basis), never population assurance. Enforcement: the cover line is generated from the recorded fields, not authored; the verifier recomputes it. **Denominator reconciliation (D3, corrected referent).** System-of-record object counts are declared once in the scoping header; every control-level population declaration reconciles against them with typed variances; the reconciliation is the first published check procedure of the review lane; the cover carries the consistency line above. What the reconciliation establishes is **internal consistency against a declared basis** — never completeness assurance of the population itself; the basis enum and corroborating-count rule are what address completeness, fail-closed. Enforcement: the reconciliation is a computed verifier check; exception class 4 fires on failure. #### 11.2 The minimum-n table ACAM publishes a **frequency/risk-keyed minimum-n table**, versioned and signed, with its assumptions stated verbatim: **5%/10% tolerable deviation, 0 expected deviations, 95%/90% confidence**, and the verbatim disclaimer that the table reflects **practice norms, not standards mandates, and is not represented as statistically valid inference for any particular population**. The table ships as the versioned annex **`acam/ACAM-SAMPLING.md`** + **`acam/acam-sampling.json`** (work package A2); this standard binds to it by reference and version pin. Rules that consume it: - **n below minimum ⇒ the control cannot exceed `tested`** (CAP-05). - **missing enumeration basis ⇒ the control cannot exceed `documented`** (CAP-06). - **`management-selected` or judgmental-without-rationale selection ⇒ the control cannot exceed `tested`** (CAP-07; the ceiling value is draft decision D-2, flagged for founder review — the design of record says "capped" without naming the rung). - **any deviation on a blocking control ⇒ `tested-exception` until extended testing is recorded** (CAP-08; the extended-testing record is an append-only sub-record per DOM-3). - Headline rollup line, mandatory when non-zero: **"N controls reached `effective` on samples below ACAM minimums"** — by construction this line must always read zero in a conforming dossier (CAP-05 prevents it); a non-zero value is exception class 6 (`sample-below-minimum-uncapped`) and marks a non-conforming producer. Enforcement: the line is verifier-computed; the exception class fires in the review lane. #### 11.3 The assessment window **`assessment_window`** (start, end; **≤ 12 months**) is a mandatory scoping field. Enforcement: schema `required` + arithmetic check. - **Rule W1 (non-overridable)** — operating evidence supporting `tested` or `effective` must fall inside the window. There is no override, no justification path, no counted-exception path. Enforcement: CAP-09; the verifier excludes out-of-window operating evidence before any rung computation. - **Rule W2** — design evidence may predate the window by **≤ 90 days** with a recorded justification; beyond that, or without the justification, it is inadmissible. Enforcement: CAP-10. #### 11.4 Freshness Freshness is keyed **window-first, evidence-type-second**, with change-frequency modifiers; the full re-cut table is in the A2 annex (`acam/ACAM-SAMPLING.md` §9), bound by version pin like the minimum-n table. Rules: - **F-1** — a stale evidence item is **unsatisfied**, and the rung is recomputed without it (CAP-11). Staleness never merely annotates. - **F-2** — interview notes may never be sole support on a blocking control; non-overridable (CAP-12). - **F-3** — freshness overrides (where the table permits them) are **counted on the dossier cover**; W1 and F-2 are non-overridable and appear in no override count (CAP-13). Enforcement: the override count is verifier-computed from the override records. ### 12. Expiry and corpus currency #### 12.1 Dossier expiry **`dossier_expires = assessment_window.end + 12 months`** — computed, never authored. Expiry is the **fourth verifier state**: a conforming verifier reports one of `ok` · `stale` · `unresolved` · `expired` per target, and `expired` for the dossier as a whole past `dossier_expires`. **The expiry arithmetic is fixed: stale operating evidence can never render `ok`** — the per-target state is the minimum (most restrictive) of the freshness state and the expiry state, so no combination of fresh signature and stale evidence reports `ok`. Enforcement: CAP-25; the verifier's state lattice ships in `acam-core.json` (`verifier_states`); the conformance corpus includes a stale-evidence-fresh-signature specimen that must report `stale`. #### 12.2 Corpus currency (anti scope-shopping) Signing a dossier against a non-current corpus release stamps **`corpus_currency: stale-at-signature`** plus the **version delta** (controls added, obligations added, objectives revised — restricted to the dossier's scope) on the cover. Such dossiers are **ineligible for Apeiris review absent a published justification**. Enforcement: CAP-24; the stamp is computed by the signing tool from `changelog.json` + the manifest, not asserted; the review-lane intake procedure checks it; exception class 2 (`corpus-anchor-version-hash`) covers mismatched or unpinned corpus references. --- ## Part V — The cap catalog ### 13. Fail-closed caps as numbered computable rules Every cap is a computable rule: **{condition over recorded fields} ⇒ {consequence in the closed vocabulary}**. The catalog ships as data in `acam-core.json` (`cap_rules`), and the verifier applies every rule on every computation — caps are not advisory. Rung ceilings use the §6 order; "cap at X" means the computed rung is `min(rung, X)`. Where a rule's consequence is a failure token, the token issues per §7.3. | Rule | Condition | Consequence | Source | |---|---|---|---| | CAP-01 | Every workpaper for the control has `procedure_performed: none-assertion-only` | rung ≤ `mapped` | §3 (plan), §10.1 | | CAP-02 | Any workpaper cited for `documented`+ has an empty `observation` | that workpaper does not qualify; rung recomputed without it | §3 (plan), §10.1 | | CAP-03 | `validation_objective` concerns operation and no operating evidence item is automated- or third-party-class | rung ≤ `design-effective` (reliability floor) | §3 (plan), §10.2 | | CAP-04 | `contradictory_or_limiting_observations` absent (not even nil) on any control | dossier fails validation | §3 (plan), §10.4 | | CAP-05 | Sample size below the published minimum-n for the control's frequency/risk key | rung ≤ `tested` | §4 (plan), §11.2 | | CAP-06 | `population_enumeration_basis` missing on a population-governing control | rung ≤ `documented` | §4 (plan), §11.1 | | CAP-07 | `selection_method` is `management-selected`, or `judgmental-with-rationale` with no recorded rationale | rung ≤ `tested` *(ceiling = draft decision D-2)* | §4 (plan), §11.2 | | CAP-08 | Any sampling deviation on a blocking control | `tested-exception` until an extended-testing sub-record is appended | §4 (plan), §11.2 | | CAP-09 | Operating evidence dated outside `assessment_window` | item inadmissible for `tested`/`effective`; no override (W1) | §4 (plan), §11.3 | | CAP-10 | Design evidence predating the window by >90 days, or ≤90 days without recorded justification | item inadmissible (W2) | §4 (plan), §11.3 | | CAP-11 | Evidence item stale under the freshness table | item unsatisfied; rung recomputed without it | §4 (plan), §11.4 | | CAP-12 | Interview notes are the sole support on a blocking control | supporting evidence insufficient; rung recomputed as if unevidenced; non-overridable | §4 (plan), §11.4 | | CAP-13 | Any freshness override applied | override counted on the cover (disclosure consequence; W1/CAP-12 never appear here) | §4 (plan), §11.4 | | CAP-14 | `population_enumeration_basis: interview-assertion`, or no independent corroborating count where one was obtainable | affected controls ≤ `documented` | §14/B2, §11.1 | | CAP-15 | Variance absent / out-of-enum / arithmetically unaccounted / unevidenced | treated as missing enumeration basis (≤ `documented`); exception class 4 fires | §14/B2, §11.1 | | CAP-16 | `digest_scope: metadata-only` | item never counts toward content-integrity (gating) coverage | §13–§14/B10, §10.3 | | CAP-17 | `metadata-only` without a `digest_unavailable_reason` consistent with `component_operator` | digest inadmissible; exception class 10 fires | §14/B10, §10.3 | | CAP-18 | Boundary-limited system (provider-held bytes) in scope | admitted with a mandatory scope-limitation record + rung ≤ `tested` *(ceiling = draft decision D-3)* | §14/B10, §10.3 | | CAP-19 | Three-part digest fraction (hashed / metadata-with-reason / unaccounted) does not sum to the declared evidence inventory | dossier fails validation (schema constraint) | §14/B10, §10.3 | | CAP-20 | Obligation→control edge with undeclared `sufficiency_relation` | fail-closed `min` operator for that obligation | §5 (plan), §14.1 | | CAP-21 | Framework curation coverage below the published per-framework threshold | obligation rollup suppressed for that framework (bulk heuristics may only tighten, never relax) | §13 (plan), §14.1 | | CAP-22 | `claimed_rung` present with no qualifying evidence | `effective_rung = mapped`; claim retained and rendered beside it | §0 decision 8, §8 | | CAP-23 | Conflicts declaration unanswered (any question) | dossier fails validation | §6 (plan), §15.2 | | CAP-24 | Corpus release at signature not current | `corpus_currency: stale-at-signature` + scoped version delta stamped on cover; ineligible for Apeiris review absent published justification | §6 (plan), §12.2 | | CAP-25 | Wall clock past `dossier_expires`, or any operating evidence stale | verifier state `expired` / `stale` per the state lattice; stale operating evidence can never render `ok` | §4/§13 (plan), §12.1 | Enforcement, catalog-wide: `cap_rules` in `acam-core.json` is the normative machine form; the verifier evaluates every rule on every run; the defective-dossier conformance corpus contains ≥1 triggering specimen per rule; a verifier that misses any specimen fails conformance (§2.2). *(Mechanism status: rules specified here and in `acam-core.json`; verifier + corpus are WS-B B4/B5 — not yet implemented.)* --- ## Part VI — Rollups, scorecard, aggregation ### 14. Rollups and rendering constraints #### 14.1 Obligation rollups Obligation rollups require the corpus-side **`sufficiency_relation`** on every obligation→control edge — `alternative` · `cumulative` · `partial-contribution` — selecting the operator per obligation: - `alternative` ⇒ **max** over the addressing controls' results; - `cumulative` ⇒ **min** over the addressing controls' results; - `partial-contribution` ⇒ **"N of M contributing"** rendered as a fraction, never collapsed to a single rung. Rules: - **RO-1** — undeclared relation ⇒ fail-closed **min** (CAP-20). `relation-undeclared` is a distinct recorded status from `insufficiently-evidenced`: the first is a corpus-curation gap, the second an evidence gap; conflating them misattributes the client's posture. Enforcement: the rollup record carries which status applied per obligation. - **RO-2** — obligation rollups are **suppressed** for any framework whose curation coverage is below the published per-framework threshold (CAP-21); bulk-heuristic relation assignments may only tighten (toward min), never relax. Enforcement: the threshold and coverage figures come from the signed ASSESS-4 curation artifact; the verifier suppresses, it does not warn. - **RO-3** — failure-token dominance (DOM-1/DOM-2) applies inside every operator: max over alternatives never masks an exception on a blocking control. Enforcement: the operators are defined over the token-extended lattice in `acam-core.json`, where failure tokens are absorbing. #### 14.2 Scorecard constraints - **SC-1** — the **verdict-distribution shape is primary**; the headline is the one non-launderable ratio: **"X of Y in-scope obligations have evidence behind their mapping."** Enforcement: the scorecard schema's headline field is computed, not authored. - **SC-2** — percentages ship **only** with: mandatory scope enumeration (systems, units, enumeration basis each); absolute numerator/denominator display ("412 of 649", never a bare percent); a scope-change line item on reassessment; and `out_of_scope_with_rationale` on the cover. Enforcement: schema — the percent field cannot validate without its numerator/denominator/scope-enumeration siblings. - **SC-3** — **no synthetic index.** No single blended score exists in the vocabulary. Enforcement: the closed schema has no such field; the contract gate rejects additions. - **SC-4** — failure-token counts render on every scorecard (DOM-4). Enforcement: mandatory fields. #### 14.3 Entity-risk declaration Scoping records ordinal signed inputs — **consequence class (financial/safety/rights) · autonomy · reversibility · population exposed · regulatory classification** — feeding recommendation weights and sampling minimums. Judgment is made visible and challengeable, not removed. The axis value sets, fail-closed defaults, and risk-tier derivation are normative in `acam/ACAM-ENTITY-RISK.md` + `acam/acam-entity-risk.json` (A5). Enforcement: schema-required scoping fields; the A2 minimum-n table keys on them; the recommendation weights that consume them are displayed per §14.5. #### 14.4 Aggregation pattern flags Deterministic pattern flags — an entire family at `mapped`; gaps concentrated on one owner role; a domain resting solely on attested-class evidence; `effective` on n=1 — are rendered as **judgment prompts requiring written, signed responses in the dossier**. Enforcement: the flags are verifier-computed (pure functions over the dossier); an unanswered flag is a validation failure; responses are signed dossier records. #### 14.5 Ranking arithmetic Recommendation-ranking arithmetic is **display non-optional in every export**. ACAM commits to publishing a rank-stability analysis under weight perturbation plus practitioner calibration of the top-20 **before** the ranking is marketed as more than a default sort. Enforcement: export schema carries the arithmetic; the marketing constraint is a claim-language rule (§16.4) until the analysis is published. --- ## Part VII — Dossier requirements ### 15. Dossier form, identity, review, composites #### 15.1 Form The dossier is an **AP-48 overlay**: evidence-observation payloads + verdicts + a scoping/methodology header, targeting canonical control URIs and content hashes, signed with the producer's own Ed25519 key. The schema is published into the contract mirror as a deliberate release act (WS-B B6). The **draft dossier is the save file**: partial assessments export and re-import as schema-valid drafts from day one, no account required; the save file, the hand-off file, and the final artifact are one format. Enforcement: one schema with a `status` field (`draft` / `final`); the only validation difference is which requireds bind at `final`. #### 15.2 Identity binding and the conflicts declaration (shipped together, never separately) - **ID-1** — assessor keys bind to a verifiable organizational identity via DNS TXT / `.well-known`. Enforcement: the binding is verifier-checked (resolve + match), not asserted. - **ID-2** — the **machine-readable conflicts declaration** is mandatory and ships in the same schema release as identity binding: per control family — designed/implemented/operated/advised on any in-scope control? fee contingent on any outcome? financial or reseller interest in any cited vendor? safeguards applied? — extended per the round-2 set: prior-period involvement · affiliate/subcontractor scope · fee concentration · who-selected/who-pays · assessor dependency on client product · partner compensation/reciprocal referrals · post-signing duty-to-update. **Unanswered ⇒ the dossier fails validation** (CAP-23). Verified identity without conflicts disclosure is worse than anonymity. Enforcement: schema `required` over the full question set; no partial declarations. - **ID-3** — a **bright-line prohibited-conflicts list** exists whose entries are grounds for **refusal, not disclosure**: a declaration matching a prohibited entry fails validation rather than rendering as a disclosed conflict. The list is published with the conflicts schema: `acam/ACAM-CONFLICTS.md` + `acam/acam-conflicts.json` (A5). Enforcement: verifier evaluates declarations against the published list. - **ID-4** — **engagement-level conflict aggregation**: composite engagements evaluate the prohibited list and concentration thresholds against the **aggregate** across assessors (3 assessors × 25% fee concentration = 75% at engagement level, invisible per-assessor). Enforcement: the aggregation is arithmetic over the per-assessor declarations; verifier computes it. #### 15.3 Review discipline - **RV-1** — **`reviewed_by != assessor_of_record`** is a schema constraint on every dossier. Enforcement: schema. - **RV-2** — **`review_extent`** (closed enum: `none` · `administrative` · `procedure-reperformance` · `full-reperformance`) plus `review_date` are recorded on all dossiers and **rendered on the face of every record**; during any beta the honest value `none` is stated plainly. Enforcement: schema-required; face-rendering checkable per the AB-2 pattern (the value travels with every projection). #### 15.4 Composite dossiers (multi-assessor) Frozen into the schema before first release (later = breaking change). Requirements: - **CO-1 (scope disjointness/coverage)** — every in-scope control is claimed by exactly one contributor or explicitly `unassigned`; the verifier emits the unassigned count. Enforcement: computed partition check. - **CO-2 (contradiction detection)** — deterministic contradiction-**detection** records (never resolution): where contributions conflict, the conflict is recorded as data. Enforcement: verifier-computed records; a composite with undetected recorded contradictions fails the conformance corpus. - **CO-3 (countersign semantics)** — closed enum `assembled` · `reviewed` · `accountable`; **`assembled`** attests exactly: contributions received + signatures verified + scopes reconciled + lead procedures executed — **never** adoption of contributor judgment. Enforcement: enum in schema; the semantics text is in-payload so no projection strips it. - **CO-4 (competence basis)** — per-assessor `competence_basis` recorded. Enforcement: schema. - **CO-5 (contribution binding)** — a canonical contribution manifest of immutable content hashes is cryptographically bound to the countersignature (a merkle root is one admissible implementation; the invariant is specified, not the data structure). Enforcement: verifier recomputes the binding. - **CO-6 (withdrawal/revocation)** — `contribution-withdrawn` / `contribution-revoked` states define the post-repudiation dossier state deterministically. Enforcement: state machine in schema; verifier applies it. - **CO-7** — engagement ID + corpus/procedure-set pins + deterministic contribution ordering. Enforcement: schema + canonical ordering check. - **CO-8** — per-assessor scope/identity/conflicts + immutable per-assessor signatures + a named engagement-lead countersignature (D4). Enforcement: schema + signature verification. --- ## Part VIII — Artifact classes and outcome invariance ### 16. Artifact-class rules #### 16.1 Global outcome invariance (invariant 9) **No signed artifact class may exist, in any lane or tier, that only ever renders favorably.** Every artifact class carries adverse states of identical prominence, the shared exception-class vocabulary (§16.3), and expiry/revocation semantics; and no subscription may be structured such that unfavorable outputs are a churn event with a dollar value — outcome-invariance applies to recurring revenue in substance, not just episodic fees. Enforcement: (a) schema level — every artifact-class schema must define its adverse states before the class validates against the contract; (b) test level — the conformance corpus includes an adverse specimen per artifact class; (c) commercial level — invariant 6 of the design of record (no fee, discount, credit, or refund varies with outcome), asserted in the review-lane fee terms. #### 16.2 The automated validation log (B1 shape) The subscription-tier machine artifact is the **"automated validation log — not reviewed"**: - **VL-1** — outcome-symmetric by construction: a failed run emits an identically prominent log, classed by the same exception vocabulary. Enforcement: one emitter code path; the adverse specimen in the conformance corpus. - **VL-2** — **client-key signed**, with an optional Apeiris counter-timestamp issued from a dedicated high-volume intermediate; **never an Apeiris issuer signature**. Enforcement: the log schema's signature block names the client key; the counter-timestamp field cannot carry an issuer-class key ID (key hierarchy is partitioned by artifact class, ASSESS-8/B4). - **VL-3** — carries the machine flag `not-for-relying-party-use: true` plus in-artifact copy; expiry, as-of, and revocation semantics are defined for the class. Enforcement: schema `const: true` on the flag; expiry arithmetic per §12.1. - **VL-4** — "passed" and "receipt" are prohibited in the class name, filename, first line, and mark policy. Enforcement: the claim-language register (§16.4) + the artifact-class naming check in the emitter's tests. #### 16.3 The ACAM Dossier Conformance Check (review-lane record, summary) Machine token `apeiris:dossier-conformance-check:v1`. Scope: **dossier conformance only, never control effectiveness.** The signed record contains: the versioned+hashed procedure set · per-procedure findings · scope · named intended users · the in-payload canonical statement (counsel-reviewed; explicitly negates audit/attestation/certification/conformity-assessment and the supervisory review/validation register) · `signed_as_of` · expiry — and a **completion-status enum containing no findings summary**: ``` procedures-completed · procedures-completed-with-scope-limitation · unable-to-complete · expired · revoked ``` Findings live **only** in the per-procedure findings arrays, keyed to the published v1 **12-class exception taxonomy** (class identifiers are normative here; the per-class machine-decidable predicates, detecting procedure IDs, consequence-class derivation, worked examples, completion-status binding, and mutual-exclusivity rules are published in **`acam/ACAM-EXCEPTIONS.md`** + `acam-exceptions.json` + the procedure register `acam-procedures.json` — work package A3, part of this release unit): 1. `schema-or-type` · 2. `corpus-anchor-version-hash` · 3. `signature-or-identity` · 4. `population-reconciliation` (fires on absent / out-of-enum / arithmetically-unaccounted / unevidenced variance) · 5. `unsupported-enumeration-basis` · 6. `sample-below-minimum-uncapped` · 7. `assertion-only-uncapped` · 8. `reliability-floor-breach` · 9. `ipe-basis-absent` · 10. `digest-scope-miscount` (fires both directions) · 11. `window-or-freshness` · 12. `disclosure` — plus two record types that **display but never count**: `observation` and `scope-limitation` (the latter records an Apeiris-side fact, not a client fact). Classes are machine-decidable, mutually exclusive, severity-free (procedure-derived consequence classes only; assessor-assigned severity prohibited), and traceable to procedure IDs. - **RC-1** — the zero case renders as a **count** — "0 of 12 exception classes triggered across N procedures" — **never as an enum token** (a favorable aggregate token retains the negative-assurance form the attestation literature prohibits). Enforcement: no such token exists in the closed enum; the renderer computes the count line from the findings arrays. - **RC-2** — an in-payload appropriateness disclaimer states that Apeiris makes no representation that the procedure set fits any user's purpose. Enforcement: schema-required field with a pinned canonical text hash. - **RC-3** — the class list ships with a **public test corpus of deliberately defective dossiers**, which doubles as the verifier conformance suite (§2.2). Enforcement: one artifact, two obligations (WS-B B5). - **RC-4** — fees are for the review, never contingent on the outcome; no fee, discount, credit, or refund may vary with the review outcome. Enforcement: commercial invariant, asserted in published fee terms and checkable against them. - **RC-5** — no review record issues without identity binding + conflicts declaration (§15.2) and the full §7 (design of record) precondition list. Enforcement: intake gate of the review-lane runbook (WS-G). - **RC-6** — issuance-regardless-of-termination and the publication policy are made observable: published aggregate lane statistics from day one including paid beta, plus ≥1 redacted adverse specimen whose publication consent is pre-signed at intake as a published acceptance criterion; "demonstrated" is defined as both. Enforcement: the aggregates pipeline (WS-D D5) + the intake consent record. #### 16.4 Claim language (the register) ACAM extends the corpus scope-claim discipline (`scope-claim-policy.schema.json`: approved scoped phrasings enumerated, disallowed phrasings structurally forbidden at the field level) to assessment artifacts: - **Prohibited terms (machine list, `prohibited_terms` in `acam-core.json`):** the word "independence" and the phrase "independent review"/"independent validation" (the supervisory banking register) · "certified"/"certification" · "compliant"/"compliance determination" · "conformity assessment" · "CE marking" · "audit opinion"/"attestation" (as descriptions of ACAM artifacts) · "material"/"material weakness"/"significant deficiency" (ICFR register without ICFR machinery) · "guarantees" · "complete coverage" · "passed"/ "receipt" (validation-log register, VL-4) · watch-list: "effective challenge" (SR 11-7 register). Near-neighbor variants are in scope of the machine list. - **Approved register:** rung tokens and failure tokens rendered with their Assurance Basis (AB-2/AB-4); "designed to exceed conventional assessment deliverables in transparency, machine readability, provenance, and repeatability, while explicitly not replacing independent evidence inspection or professional attestation" (the §1 quality claim, the one permitted use of the adjective); counted-class statements ("N of 12 exception classes triggered"); scoped statements binding every figure to its numerator, denominator, and enumeration basis (SC-2). - Enforcement: the machine list ships in `acam-core.json`, extended by the full phrasebook `acam/acam-phrasebook.json` (A4 machine half — term/register/prohibition-class/replacement, watch list, approved phrasings); rendering surfaces and artifact emitters run it as a structural check (the `validate-framing.mjs` pattern; the enforcing check extension is the PHRASE-GATE control-core task); the canonical statement and disclaimers are counsel-reviewed before first issuance (A4 tail). --- ## Part IX — Versioning and governance ### 17. Versioning, compatibility, release acts - **V-1** — ACAM versions by **SemVer**. The prose standard, `acam-core.json`, the exception-class taxonomy (`ACAM-EXCEPTIONS.md` + `acam-exceptions.json` + `acam-procedures.json`), and the annex tables (`acam-sampling.json`, freshness re-cut) version together as one release unit; a dossier pins the ACAM version it was computed under, alongside its corpus version pin. Enforcement: the dossier schema requires both pins; the verifier evaluates under the pinned rules. - **V-2** — **compatibility window: 12 + 12 months, aligned to the window/expiry cycle** so no in-flight dossier is orphaned: a dossier's assessment window may span ≤ 12 months (§11.3) and its verifier life extends 12 months past window end (§12.1); therefore every ACAM MAJOR or MINOR release remains supported for verification for **at least 24 months after its successor ships** — the maximum window plus the maximum post-window life. A verifier must verify any unexpired dossier under the dossier's pinned ACAM version. Enforcement: the published support table per release; the conformance suite retains prior-version specimens for the support period. - **V-3** — **methodology changes are versioned release acts**: any change to an enum, a cap rule, the nine-cell table, a dominance rule, the minimum-n table, or the freshness table is a new ACAM version, never an in-place edit. Breaking changes (removed/renarrowed vocabulary, weakened fail-closed default, changed cap consequence) require a MAJOR bump. Enforcement: the contract-diff gate pattern (the corpus `validate-contract.mjs` discipline) applied to `acam-core.json` against its blessed baseline. - **V-4** — pre-1.0, changes are founder-controlled with a written RFC-opening trigger (design of record §13 governance); no advisory council exists before real adopters. Trend or comparison features across corpus or ACAM versions must restate or mark non-comparable (§4). Enforcement: governance note in every pre-1.0 release; the restatement rule is a schema constraint on any future trend artifact. --- ## Annex A — Deliberate non-contents of this release (where the rest lives) | Deferred item | Work package | |---|---| | ~~Minimum-n table values + freshness re-cut table~~ — **shipped**: `acam/ACAM-SAMPLING.md` + `acam/acam-sampling.json` | A2 (done) | | Exception-class predicates, detecting procedure IDs, worked examples, defective-dossier corpus | A3, B5 | | Canonical statement + appropriateness disclaimer final texts (counsel) — drafts in `legal/drafts/`; the machine phrasebook is published (`acam/acam-phrasebook.json`; PHRASE-GATE enforcement pending) | A4 | | ~~Entity-risk axis value sets + conflicts question set finalization + prohibited-conflicts list entries~~ — published: `acam/ACAM-ENTITY-RISK.md` + `acam/ACAM-CONFLICTS.md` (+ machine halves); draft decisions C-1..C-5, E-1..E-4 remain flagged | A5 | | Minimum-n table values + freshness re-cut table (`acam-sampling.json`) | A2 | | Defective-dossier test corpus (the A3 worked examples in `acam-exceptions.json` are its seeds) | B5 | | Canonical statement + appropriateness disclaimer final texts (counsel) | A4 | | Entity-risk axis value sets + conflicts question set finalization + prohibited-conflicts list entries | A5 | | Dossier / composite / review-record / validation-log JSON Schemas | B1–B3 | | The deterministic verifier | B4 | | Sufficiency-relation curation (~334 obligations) + per-framework thresholds | ASSESS-4 / F1 | | Census + enumeration units + canonical crosswalk (scale claims) | ASSESS-6 / F4, B11 | | Instrument applicability metadata (`obligation_modality`, `entity_scope_predicate`, three-lane display, SR 26-2 as non-scoreable `reference`) | ASSESS-9 / F3 | ## Annex B — Draft decisions flagged for founder review - **D-1** (nine-cell cell 4): operating `tested-held` with design `not-evaluated` computes the documentation floor (≤ `documented`) rather than a distinct marker. - **D-2** (CAP-07): the ceiling for `management-selected` / unrationalized judgmental selection is `tested` (the design of record says "capped" without naming the rung). - **D-3** (CAP-18): the verdict cap for boundary-limited systems is `tested`. - **D-4** (CAP-03): the reliability-floor consequence is a `design-effective` ceiling. - **D-5** (§11.1): the draft `variance_reason` enum values (finalized in A2). - **D-6** (§7.3): `evaluation-impaired` is modeled as an overriding per-control condition with a reason enum, keeping the sub-state enums at 3×3, rather than as a fourth value of each sub-state.