ARCS - Automated Record Custody Standard

Section navigation

Per-deployment conformance Scoping Conformance profiles Partial conformance Runtime family applicability Maturity levels Statement requirements Reference implementation

Profiles

Assessment

Normative source and operational guidance

Normative conformance requirements are defined in Standard Section 16. In case of conflict between this page and Section 16, the normative text controls.

This page provides operational guidance, profile summaries, and attestation support. Profile detail pages are available for Foundation, Minimum, and Enterprise.

Per-deployment conformance

ARCS conformance is evaluated per deployment, not per organization. A single organization operating multiple AI systems produces separate conformance statements for each materially different system or configuration. This is because materially different deployments may create different record surfaces, custody conditions, retention behavior, and vendor dependencies, even where they are operated by the same organization.

Scoping

A conformance claim may be scoped to a subset of an 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.

1.Scope must be explicitly stated in the conformance statement.

2.Scoped systems must be independently identifiable.

3.Material interactions with out-of-scope systems must be disclosed.

4.Outbound transmission to an out-of-scope system must be disclosed as a custody event.

5.Scoping cannot exclude material record surfaces from governance.

Conformance profiles

Profiles are operative. 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.

Profile	Required families	Assessment
Foundation Profile v1	if claimed	Self-attestation
Minimum Profile v1	if claimed+/	Self-attestation or audit
Enterprise Profile v1	All Minimum families + Universal Enhanced + Conditional Enhanced controls	Self-attestation, audit, or third-party

Foundation: Baseline governance for core record surfaces. Record identification, custody mapping, and taxonomy.

Minimum: Operational governance suitable for production deployments requiring legal defensibility and audit readiness.

Enterprise: Full-surface governance including enhanced and conditional controls for multi-vendor, multi-jurisdiction environments.

Partial conformance

Partial satisfaction is a valid documented state.

An implementation may document partial satisfaction of requirements without claiming full profile conformance. Partial satisfaction shall not be represented as Foundation, Minimum, or Enterprise conformance. It 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.

A partial conformance statement should identify: families satisfied, families in progress, families not yet addressed, and the target profile. Partial conformance is appropriate when an operator has implemented some but not all required families, or has satisfied requirements at a higher maturity level for some families but not others. For statement structure, see the Attestation Template.

Runtime family applicability

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

Family	Applies if	Not required if
ARCS-AGT	The operator deploys agentic or semi-autonomous runtimes that plan, route, delegate, or select tools after user initiation.	The system is purely deterministic or prompt-response without delegated runtime behavior.
ARCS-DEL	The system retains instruction state, memory, delegation logs, or intermediate state across turns, agents, or sessions.	No delegated execution, retained memory, or persistent agent state exists.
ARCS-NCR	The operator claims non-creation, non-retention, or a zero-data-retention posture.	No such claim is made.

Maturity levels

Maturity levels are descriptive. 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.

Level	Name	Description
0	No surface governance	Interaction records exist but are not identified, mapped, or documented.
1	Record identification	Material record classes are identified and distinguished from unrelated system data.
2	Surface mapping	Record and custody surfaces are mapped. Locations, vendors, and custodians are documented.
3	Documented lifecycle governance	Retention, deletion, routing, and preservation posture are documented. Lifecycle rules are defined per record class.
4	Governance-grade implementation	Governance-grade lifecycle control across normal operating surfaces. This is the institutional minimum for organizational accountability, defensible retention posture, and credible audit or legal review.
5	Full-surface governance	All known record surfaces are governed, including advanced runtime, derivative, delegated, and autonomous execution artifacts. Independent verification is required.

Level 4 is the institutional minimum for organizational accountability and defensible governance. Level 5 requires independent verification across all known record surfaces, including advanced runtime and autonomous execution artifacts.

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 contain:

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 profile 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

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.

For templates and worked examples, see: Annex AB (Example Conformance Statement), Annex AH (Example Legal Hold Procedure), and the Attestation Template. Full requirements are in Standard Section 16.

Reference implementation

A production reference implementation exists. The existence of a reference implementation does not confer conformance on other deployments. Each deployment must satisfy conformance requirements independently.