Conformance

A system conforms to ARCS if all applicable controls for the declared conformance profile are implemented, required documentation exists, lifecycle posture is defined, custody surface is disclosed, preservation posture is supported, and non-creation claims are auditable where asserted. Conformance is evaluated per deployment, not per organization. Materially different deployments may create different record surfaces, custody conditions, retention behavior, and vendor dependencies, even where they are operated by the same organization.

16.1 Scoping

A conformance claim may be scoped to a defined subset of the operator's AI systems, but only under explicit conditions. Scoping permits bounded claims where systems are separable, but it does not permit omission of record-bearing dependencies or custody-relevant interactions. Specifically:

(a) the scope is explicitly stated in the conformance statement;

(b) the scoped systems are independently identifiable and assessable; and

(c) any material interaction between scoped systems and systems outside the declared scope is disclosed in the conformance statement.

Scoping does not permit exclusion of material record surfaces. A system that transmits records to an out-of-scope system must disclose that transmission as a custody event, even if the receiving system is not itself assessed.

16.2 Conformance profiles

ARCS defines three conformance profiles. A profile claim requires implementation of all controls assigned to that profile, including conditional families where the stated applicability conditions are met. Conformance may be declared by operator self-attestation, internal audit, or third-party assessment. All required controls must have supporting documentation available upon request.

Foundation Profile. Requires implementation of ARCS-LIF, ARCS-CUS, and ARCS-TAX, with ARCS-NCR required only if non-creation or non-retention is claimed. The Foundation Profile establishes baseline record identification and surface mapping sufficient to begin governance. Organizations may declare Foundation conformance while implementing remaining families.

Minimum Profile. Requires implementation of all controls in ARCS-LIF, ARCS-CUS, ARCS-TAX, ARCS-OPB, ARCS-PUB, ARCS-PV, and ARCS-VER, with ARCS-NCR required only if non-creation or non-retention is claimed. ARCS-AGT and ARCS-DEL are required where the deployment meets the applicability conditions defined in Section 16.2.1. The Minimum Profile constitutes the institutional minimum for ARCS conformance.

Enterprise Profile. Requires all Minimum Profile controls plus Enterprise Enhanced controls. Enterprise Enhanced controls are defined in the Enterprise Implementation Profile. Universal Enhanced controls apply to all Enterprise Profile declarations. Conditional Enhanced controls apply based on the operator's declared risk factors as specified in the Enterprise Profile document.

16.2.1 Runtime family applicability

These applicability rules determine when conditional families become required for a declared profile.

ARCS-AGT is required if the operator deploys agentic or semi-autonomous runtimes that plan, route, delegate, or select tools after user initiation. ARCS-AGT is not required if the system is purely deterministic or prompt-response without delegated runtime behavior.

ARCS-DEL is required if the system retains instruction state, memory, delegation logs, or intermediate state across turns, agents, or sessions. ARCS-DEL is not required if no delegated execution, retained memory, or persistent agent state exists.

ARCS-NCR is required if the operator claims non-creation, non-retention, or a zero-data-retention posture. ARCS-NCR is not required if no such claim is made.

16.3 Maturity levels

Maturity levels are descriptive. Conformance profiles are operative. A maturity level describes the current depth and completeness of an implementation's governance posture. A profile defines the required control families for a conformance claim.

A maturity level does not by itself confer or deny profile conformance. An organization may exhibit characteristics associated with a higher or lower maturity level, but conformance depends on whether the controls required for the declared profile are implemented and supported. Maturity claims should therefore be used to describe present-state implementation depth, not as a substitute for profile claims.

When making an attestation or other conformance statement, organizations should declare both the applicable profile and the maturity level. The profile states the conformance posture. The maturity level states the implementation depth within that posture.

ARCS defines six maturity levels:

Level 0 - Undocumented record governance. Interaction records exist, but the implementation has not independently identified, mapped, or documented the record, custody, discovery, and review surfaces. Most organizations deploying AI systems are at Level 0 upon initial assessment. Level 0 reflects reliance on vendor policy statements without independent documentation, not the absence of all data governance.

Level 1 - Record identification. The implementation has identified the interaction records created by its operation. Record surfaces, custody, retention, and routing may remain undocumented. Corresponds approximately to ARCS-TAX and basic ARCS-LIF inventory.

Level 2 - Surface mapping and disclosure. The implementation has mapped where records exist, who holds them, and what review and routing conditions apply. Retention and deletion documentation may remain incomplete. Corresponds approximately to ARCS-CUS, ARCS-TAX, and ARCS-LIF, with review and routing disclosure.

Level 3 - Documented lifecycle governance. The implementation has documented how records move, persist, and are removed across the interaction lifecycle, including retention and deletion controls. Corresponds approximately to ARCS-LIF, ARCS-PUB, and deletion/routing controls.

Level 4 - Governance-grade implementation. Governance-grade lifecycle control across normal operating surfaces. The implementation has achieved governance-grade control of interaction records across the normal operating surfaces of the system. Level 4 marks the transition from internal documentation to externally reviewable governance. This is the institutional minimum for organizational accountability, defensible retention posture, and credible audit or legal review. A Level 4 implementation can demonstrate where interaction records exist, who holds them, and how long they persist, for all normal deployment modes, in a form reviewable by an auditor, procurement officer, or legal counsel. Corresponds to the Minimum Profile.

Level 5 - Full-surface governance. All known record surfaces are governed, including advanced runtime, derivative, delegated, and autonomous execution artifacts. No known material record surface remains undocumented. Independent verification is required. Level 5 claims SHALL identify the scope of agent runtime, delegation, memory, and derivative-record governance applied, including any material runtime conditions not fully specified by the current version of this standard. Corresponds approximately to the Enterprise Profile with agent runtime coverage.

16.4 Partial conformance

Partial satisfaction is a valid documented state. An implementation may declare partial conformance by listing the control families satisfied, provided partial conformance is not represented as Foundation, Minimum, or Enterprise Profile conformance. Partial conformance is appropriate for staged implementation, remediation planning, audit preparation, or other transitional governance states in which some but not all required families have been implemented.

Partial conformance declarations should identify families satisfied, families in progress, families not yet addressed, and the target profile.

16.5 Conformance statement requirements

A conformance statement is the formal record of a deployment's assessed governance posture at a specific point in time. It serves as the reference artifact for internal audit, external assessment, procurement review, and regulatory inquiry.

A conformance statement SHALL identify:

(a) system name;

(b) operator or deploying entity;

(c) ARCS version referenced by the claim;

(d) deployment mode and operating environment;

(e) version or configuration identifier;

(f) date or period of assessment;

(g) declared conformance profile (Foundation, Minimum, or Enterprise) and maturity level;

(h) scope and exclusions with justification;

(i) record-bearing components included in the assessment;

(j) external custodians, vendors, or dependencies included in scope;

(k) known non-conforming components, limitations, and compensating controls;

(l) assessor identity, role, and assessment type (self-attestation, internal audit, or third-party assessment);

(m) statement date and effective date.

A conformance statement shall be reviewed and updated when the assessed deployment undergoes material changes affecting its governance posture, including changes to vendors, record surfaces, retention rules, or system architecture. A statement that no longer reflects the current deployment should be updated or withdrawn.

16.6 Reference implementation

At least one reference implementation of ARCS lifecycle controls, including record classification, retention posture enforcement, sovereignty receipt generation, automated purge scheduling, and legal hold override, exists in production code as of the date of this publication. Reference implementations do not confer conformance on other deployments.