Requirements Catalogue

This is the normative backbone of the architecture: the numbered, testable control requirements that the pillars implement, the templates capture evidence for, and the crosswalks map to external standards. Where the earlier documents explain what control means and why, this document states what is required.

How to read a requirement

Every requirement has a stable ID and a normative statement:

ACA-<pillar>-<n> e.g. ACA-09-02

• ID: ACA + two-digit pillar (07–16) + sequence. IDs are stable; requirements are never renumbered, only deprecated.
• Statement: written with SHALL (required), SHOULD (expected unless justified), MAY (permitted), in the RFC 2119 sense.
• From tier: the lowest risk tier at which the requirement applies (see below). It also applies to every higher tier.
• Boundary: the minimum boundary source expected: Declared, Evidenced, Verified, Enforced.
• Crosswalk: the external provisions it helps satisfy (see mappings/).

Each pillar document (07–16) is the authoritative source for its own requirements and their guidance; this catalogue is the consolidated, citable index.

Risk tiers

Requirements are graduated by tier. Tier is set in pillar 07 from a use case's consequence (See/Decide/Do) and autonomy.

T1 Low-risk productivity or public-data use     public or non-sensitive data, no decision impact, no tool or action capability
T2 Internal productivity with enterprise data   internal enterprise data or vendor AI for productivity, no decision influence or actions
   or vendor AI
T3 Decision-supporting AI                        influences human decisions, judgments, or records
T4 Action-capable AI                             can call tools, trigger workflows, or perform actions in enterprise systems
T5 High-impact autonomous or regulated AI        affects employment, credit, legal, safety, healthcare, regulated, or hard-to-reverse outcomes

Tier is set from the highest material risk driver, not an average. A requirement marked From T3 applies to T3, T4, and T5, not T1 or T2.

Tiers and pillars: depth, not on/off

Tiers do not map one-to-one to pillars. All ten pillars remain relevant at every tier; what rises with the tier is the depth of control each pillar requires. The rule is simply: control depth scales with the risk tier, and the highest material risk driver sets the tier.

A pillar does not "switch on" at a threshold. Containment, for example, applies even at Tier 2, where it may mean disabling a vendor feature; at Tier 4 it means revoking an agent identity, cancelling pending actions, and rolling back changes. Same pillar, very different depth.

Which pillars become decision-critical at each tier:

Read as a progression: Tiers 1–2 control what AI can See (inventory, identity, data, inputs); Tier 3 controls what it can Decide or influence (output, accountability, assurance, evidence); Tier 4 controls what it can Do (identity, action authority, logging, rollback, containment); Tier 5 proves the whole chain — from access through decision and action to evidence and recovery — can be defended and reconstructed.

So the From tier on each requirement below marks where that specific control becomes a distinct, required provision, not where its pillar begins to matter. Lower tiers still exercise the same pillars at lighter depth, and a "-" in a pillar's tier-guidance table means "no distinct required control at this tier," not "pillar absent."

The catalogue

Representative requirements per pillar. This set is normative and versioned; it grows as the pillar documents are completed, and full guidance for each lives in its pillar.

07, AI Inventory & Classification

08, AI Identity & Access Control

09, Data Boundary Control

10, Prompt & Input Control

11, Output & Decision Control

12, Tool & Action Control

13, Human Accountability Model

14, AI Assurance & Testing

15, Monitoring, Logging & Evidence

16, Incident Containment & Recovery

Using the catalogue

• Assessing a use case: tier it (07), then apply the requirements at or below that tier, recording the boundary source achieved for each.
• Proving control: each requirement's boundary column is the bar; a requirement met only at Declared when Verified is expected is a finding.
• Mapping obligations: the crosswalks tie these IDs to NIST AI RMF, ISO/IEC 42001, EU AI Act, SR 11-7, NYDFS, and OWASP, so one pass serves many.

Machine-readable form

This catalogue is also published as data, generated from this document, in controls/:

controls/aca-requirements.yaml
controls/aca-requirements.json

Assessment tooling, agents, and GRC systems can consume that single source rather than re-transcribing the requirements. This document remains authoritative; the data files are built from it and checked against every pillar's table. A future version is expected to add an OSCAL profile.

Next: 07 · AI Inventory & Classification

Version 0.1.0 · Licensed under the terms in LICENSE.md.