ARCS - Automated Record Custody Standard

Section navigation

Normative conformance requirements are 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.

Scoping

A conformance claim may be scoped to a subset of an operator's AI systems, but only under explicit conditions. Scoping does not permit exclusion of material record surfaces.

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. 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	LIF, CUS, TAX (NCR if claimed)	Self-attestation
Minimum Profile v1	LIF, CUS, TAX, OPB, PUB, PV, VER (NCR if claimed) + AGT/DEL where applicable	Self-attestation or audit
Enterprise Profile v1	All Minimum families + Universal Enhanced + Conditional Enhanced controls	Self-attestation, audit, or third-party

Runtime family applicability

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 an implementation's current governance depth. It does not by itself confer or deny profile conformance. A maturity claim should declare the corresponding profile.

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 control across normal operating surfaces. Institutional minimum for organizational accountability and legal defensibility.
5	Full-surface governance	All known record surfaces governed, including advanced runtime, derivative, and autonomous execution artifacts. Requires independent verification.

Level 4 is the institutional minimum for organizational accountability and legal defensibility. Level 5 requires independent verification of all known record surfaces including advanced runtime and autonomous execution artifacts.

Partial conformance

An implementation may document partial satisfaction of requirements without claiming full profile conformance. 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.

A partial conformance statement should identify: families satisfied, families in progress, families not yet addressed, and the target profile. Partial satisfaction shall not be represented as Foundation, Minimum, or Enterprise conformance.

Conformance statement requirements

A conformance statement shall contain:

a)System name

b)Operator or deploying entity

c)Deployment mode

d)Version or configuration identifier

e)Date of assessment

f)Declared profile and maturity level

g)Scope and exclusions with justification

h)Known non-conforming components

i)Assessor identity and assessment type

j)Record-bearing components included in the assessment

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.