Full Standard

ARCS defines governance controls for the lifecycle, custody, retention, preservation, and deletion of interaction records generated by automated systems during human-directed operation.

1.1 Covered Systems

This standard applies to AI assistants and AI agents, AI-enabled productivity software, ambient AI features embedded in enterprise software, API-based automated systems, multi-step automated pipelines, conversational AI systems, agent and toolchain-integrated systems, review and feedback and evaluation pipelines, and any other system that generates, retains, or derives artifacts from human-directed interaction where those artifacts may be subject to legal compulsion, regulatory inquiry, or preservation demand.

1.2 Applicability

ARCS obligations arise when an operator uses an automated system that generates interaction records. Applicability includes any context in which interaction records may be subject to discovery, subpoena, preservation demand, regulatory inquiry, audit, or internal investigation. An operator need not be involved in active litigation for ARCS to apply.

1.3 Non-Scope

ARCS does not govern model safety, training data, algorithm design, output quality, bias, fairness, or system behavior. Those properties are governed by separate frameworks. ARCS governs only the lifecycle and custody of records created during system use. Compliance with ARCS does not substitute for compliance with applicable data protection, security, records management, or sector-specific regulations.

The key words SHALL, SHALL NOT, MUST, MUST NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this standard are to be interpreted as described in IETF RFC 2119 and BCP 14.

This standard may be used with, but does not replace, the following frameworks. ARCS defines a distinct governance domain for interaction records that no current framework addresses.

The following terms are defined for use throughout ARCS. Defined terms appear in ordinary text; no special formatting is required once defined here.

3.1 Core Record Concepts

3.2 Surface Concepts

3.3 Lifecycle Concepts

3.4 Configuration and Deployment Concepts

3.5 Agent and Runtime Concepts

3.6 Evidentiary Instruments

The following terms describe governance artifacts and assessment instruments that depend on the foundational concepts defined in subsections 3.1 through 3.5 and 3.7. These terms are downstream of the primitives; they identify artifacts produced by the governance process, not the governance primitives themselves.

3.7 Entity Concepts

3.8 Surface Class Taxonomy

The surface taxonomy in ARCS identifies six classes of automated-processing surface whose records present the custody gap condition described in this standard. The AI interaction surface is the primary domain addressed by ARCS controls. The remaining surface classes (transactional, identity, sensor, operational, and control-plane) are documented to establish that the governance gap condition is not unique to AI systems and to support future extension of the standard.

3.9 Conformance Keywords

The following conformance keywords are used throughout this standard:

shall indicates a mandatory requirement.

should indicates a recommendation.

may indicates a permitted option.

No alternative terminology SHALL be used in conformance documentation unless cross-mapped to the canonical term defined in this section.

ARCS applies to any operator that uses an automated system in a context where interaction records are created, retained, or may be subject to legal process. Applicability is determined by record creation, not by system category.

4.1 In-Scope Systems

ARCS applies to operators using the following categories of automated system:

AI assistants and AI agents, including consumer and enterprise interfaces, coding assistants, research assistants, and autonomous agents with tool-call or action-taking capability.

AI-enabled productivity software, including word processors, email clients, document editors, spreadsheet tools, presentation tools, and project management software where AI features are enabled by default or opt-out.

Ambient AI features embedded in enterprise software, including smart compose, smart reply, meeting transcription, search-based recommendations, and automated summarization.

API-based automated systems, including systems that process operator prompts or instructions through vendor-operated APIs and generate interaction records as a result.

Multi-step automated pipelines that direct one automated system to interact with another, where the pipeline generates, transmits, or stores interaction records.

Any other system that generates, retains, or derives artifacts from human-directed interaction where those artifacts may be subject to legal compulsion, regulatory inquiry, or preservation demand.

4.2 Applicability Threshold

ARCS obligations arise when an operator uses an automated system that generates interaction records. An operator need not be involved in active litigation for ARCS to apply. The standard governs the default and preservation postures that determine whether records will exist if litigation or inquiry arises.

4.3 Non-Scope Boundaries

ARCS does not apply to system outputs consumed and immediately discarded by the operator where no record is retained in any custody location.

ARCS does not apply to automated systems that create no interaction records in any custody location, provided the operator can demonstrate non-creation under ARCS-NCR controls.

ARCS does not govern model safety, accuracy, bias, output quality, or system behavior. Those properties are governed by separate frameworks. ARCS governs only the lifecycle and custody of records created during system use.

4.4 Applicability to Vendors

ARCS obligations are placed on operators, not on vendors. However, operators cannot fulfill their ARCS obligations without cooperation from vendors within the custody surface. ARCS requires operators to document vendor behavior, obtain vendor commitments where possible, and disclose limitations where vendor behavior cannot be verified or controlled.

ARCS controls are organized into ten control families. Each family addresses a distinct governance domain for interaction records. Controls within each family are identified by a three-letter family code and a two-digit sequence number (e.g., LIF-01, AGT-07). ARCS v1.0 contains 92 controls across 10 control families.

ARCS uses a two-layer family structure. In the Standard, each family is defined as a governance domain with a distinct scope and boundary. In the Controls catalog, each family is expressed through its constituent control statements and related operational detail.

Each control family has a defined applicability scope. An operator satisfies the applicable families for its deployment and documents non-applicability for others.

The base families (ARCS-LIF through ARCS-VER) apply to all deployments subject to ARCS. ARCS-NCR applies only where non-creation or non-retention is claimed.

ARCS-AGT applies to any deployment in which an automated system operates across multiple steps, invokes external tools, or maintains state across steps within a session.

ARCS-DEL applies to any deployment in which an agent maintains state across sessions, operates with delegated authority, or executes autonomous action sequences without synchronous human review.

Purpose

ARCS-LIF defines the governance domain applicable to the lifecycle of interaction records. This family establishes requirements for creation, classification, retention, deletion, purge execution, and lifecycle-state transition. It applies wherever a record enters, persists within, or exits a governed environment, and ensures that lifecycle treatment is explicit, verifiable, and capable of review. The purpose of this family is to prevent lifecycle treatment from remaining implicit, discretionary, or dependent on undocumented system behavior.

Governance focus

• Conditions under which governed records are created or recognized
• Classification states relevant to retention and deletion treatment
• Declared retention periods and lifecycle-state transition
• Deletion and purge execution as governed actions rather than background assumptions
• Evidentiary record of lifecycle treatment where review is required

Boundary

ARCS-LIF applies at every point where a record is created, retained, reclassified, deleted, or otherwise subjected to lifecycle treatment within the governed environment. It governs the operator's handling of record persistence over time and distinguishes declared lifecycle treatment from mere system behavior. This family does not depend on publication, transfer, or legal hold in order to apply. It establishes the baseline lifecycle posture against which those later conditions may modify or suspend ordinary treatment.

The corresponding control statements for this family are maintained in the Controls catalog.

Purpose

ARCS-CUS defines the governance domain applicable to the identification and declaration of record custody. This family establishes requirements for identifying custodians, documenting propagation across vendor and system boundaries, and maintaining visibility into the surfaces through which records are held, processed, retransmitted, or otherwise made materially available. Its purpose is to ensure that custody is declared as an observable governance condition rather than inferred only from architecture diagrams, procurement records, or post hoc investigation.

Governance focus

• Identification of record custodians and materially relevant subprocessors
• Declaration of vendor and system surfaces through which records move
• Distinction between primary custody, delegated custody, and retransmission surface
• Visibility into multi-system propagation and boundary crossing
• Maintenance of custody declarations sufficient for review and audit

Boundary

ARCS-CUS applies wherever custody is distributed, shared, delegated, or extended beyond a single system boundary. It governs the visibility of holding and propagation conditions, whether persistent or transient, where those conditions are relevant to record treatment. This family is concerned with the existence and declaration of custody surface, not merely with contractual relationship or infrastructure ownership. Where records pass through systems that materially affect retention, access, transmission, or exposure, this family applies.

The corresponding control statements for this family are maintained in the Controls catalog.

Purpose

ARCS-TAX defines the governance domain applicable to the classification of interaction records. This family establishes requirements for assigning records to categories that determine lifecycle treatment, custody significance, boundary conditions, preservation posture, and downstream obligations. Its purpose is to ensure that governance treatment is attached to record type through declared taxonomy rather than through informal naming, application convention, or unexamined default behavior.

Governance focus

• Assignment of records to policy-relevant categories
• Taxonomy attributes that affect retention, deletion, preservation, or publication
• Distinction among transient, persistent, derivative, evidentiary, and other governed record classes
• Classification logic sufficient to support downstream governance decisions
• Consistency between taxonomy and declared lifecycle or custody treatment

Boundary

ARCS-TAX applies wherever differences in record type affect governance treatment. It governs the classification layer by which records are distinguished for policy purposes, including where similar technical artifacts carry different governance significance. This family does not require that every record class receive identical treatment. It requires that treatment-relevant distinctions be declared and maintainable. Where record handling turns on type, this family applies.

The corresponding control statements for this family are maintained in the Controls catalog.

Purpose

ARCS-OPB defines the governance domain applicable to the boundary of operator responsibility. This family establishes requirements for determining which records, systems, vendors, and processing contexts fall within the operator's declared governance scope. Its purpose is to ensure that statements about retention, deletion, custody, verification, and publication are made against a clearly defined perimeter rather than an indeterminate collection of adjacent technical dependencies.

Governance focus

• Declaration of the operator-governed perimeter
• Distinction between in-scope and out-of-scope systems or processing contexts
• Treatment of vendor services, delegated functions, and adjacent environments
• Consistency between governance claims and actual boundary definition
• Exclusion logic where systems or records are not governed by the operator

Boundary

ARCS-OPB applies wherever responsibility must be distinguished from downstream, inherited, external, or third-party processing conditions. It governs the perimeter within which the operator claims governance effect and outside of which separate custody or responsibility conditions apply. This family is concerned not with whether external systems exist, but with whether the boundary between operator responsibility and adjacent environments is declared sufficiently to support meaningful governance claims.

The corresponding control statements for this family are maintained in the Controls catalog.

Purpose

ARCS-PUB defines the governance domain applicable when interaction records cross from a governed environment into a published, exported, transferred, or externally accessible state. This family establishes the requirements that attach at the publish boundary, including boundary declaration, downstream lifecycle continuity, and the treatment of records that remain discoverable, retrievable, or propagable after transfer. Its purpose is to ensure that external release is governed as a distinct condition rather than treated as the end of record responsibility by implication.

Governance focus

• Declaration of publication, export, or external release conditions
• Treatment of records that remain discoverable or accessible after transfer
• Continuity of lifecycle obligation across publish-boundary events
• Distinction between internal persistence and external circulation
• Release conditions involving APIs, syndication, downstream delivery, or third-party exposure

Boundary

ARCS-PUB applies where records are made available beyond the operator's direct environment through publication, export, API delivery, syndication, transmission, or similar release mechanisms. It governs the transition from internal custody to wider circulation where the record may continue to exist, propagate, or be relied upon after crossing the original system boundary. This family applies whenever release alters the governance condition of the record by extending its accessibility beyond the governed environment.

The corresponding control statements for this family are maintained in the Controls catalog.

Purpose

ARCS-NCR defines the governance domain applicable to systems and workflows that are declared not to create governed interaction records, or to create only bounded transient artifacts that do not persist as governed records. This family establishes requirements for such declarations, the operating conditions under which they remain true, and the verification criteria necessary to distinguish non-creation from undeclared persistence. Its purpose is to ensure that non-creation is treated as a governed posture rather than as an informal assertion about system design.

Governance focus

• Declaration of non-creation posture
• Conditions under which transient processing does not become governed persistence
• Distinction between absence of record creation and unexamined record generation
• Identification and governance of residual artifacts that persist notwithstanding a non-creation claim
• Operating assumptions necessary to sustain a non-creation claim
• Evidence sufficient to review or verify that posture

Boundary

ARCS-NCR applies wherever an operator claims that governed records are not created, or are created only in bounded transient form that does not persist as a governed record. It governs the conditions under which such claims remain valid. This family does not apply merely because a system is lightweight, ephemeral in intent, or low-retention by design. It applies where the absence of governed record creation is itself being asserted as a meaningful governance condition.

The corresponding control statements for this family are maintained in the Controls catalog.

Purpose

ARCS-PV defines the governance domain applicable to preservation obligation, hold state, and suspension of ordinary deletion or purge treatment. This family establishes requirements for hold triggers, preservation scope, hold communication, and the treatment of records whose ordinary lifecycle must be interrupted for legal, regulatory, investigatory, or other declared reasons. Its purpose is to ensure that preservation conditions are governable, reviewable, and capable of overriding ordinary lifecycle automation where required.

Governance focus

• Initiation of preservation or legal hold state
• Definition of scope for affected records, systems, or custodians
• Suspension of ordinary deletion or purge treatment
• Communication and maintenance of hold condition
• Documentation sufficient to support later review of preservation posture

Boundary

ARCS-PV applies wherever ordinary lifecycle treatment must be suspended because a preservation obligation has attached. It governs the change in record posture that occurs when deletion, purge, or other routine lifecycle action can no longer proceed as scheduled. This family applies to the existence and maintenance of hold state, including its scope and operational effect, rather than to the substantive merits of the underlying dispute, inquiry, or proceeding giving rise to preservation.

The corresponding control statements for this family are maintained in the Controls catalog.

Purpose

ARCS-VER defines the governance domain applicable to the verification of declared record treatment. This family establishes requirements for evidentiary support, auditability, traceability, attestation, and the means by which lifecycle, custody, publication, preservation, and related governance claims may be tested against observable record. Its purpose is to ensure that declared posture can be substantiated through reviewable evidence rather than resting solely on policy language or interface-level assertion.

Governance focus

• Evidentiary support for declared governance claims
• Traceability between stated treatment and observable artifact
• Auditability of lifecycle, custody, publication, and hold conditions
• Attestation and verification mechanisms
• Record of governance events sufficient for independent examination

Boundary

ARCS-VER applies wherever governance claims must be substantiated rather than merely stated. It governs the evidentiary and review conditions under which an operator may demonstrate that declared treatment has actually occurred, or that declared boundaries and obligations are materially reflected in system behavior and retained record. This family applies across other domains of the Standard where proof, traceability, or independent review is required.

The corresponding control statements for this family are maintained in the Controls catalog.

Purpose

ARCS-AGT defines the governance domain applicable to agent-mediated execution and runtime-generated record conditions. This family establishes requirements for records arising from autonomous or semi-autonomous processing, including execution context, tool invocation, intermediate artifacts, runtime decision surfaces, and other record-bearing conditions specific to agentic operation. Its purpose is to ensure that records produced through delegated computational action are governed as first-order record conditions rather than treated as incidental byproducts of application behavior.

Governance focus

• Execution context associated with agent-mediated action
• Record-bearing consequences of tool invocation and delegated processing
• Treatment of intermediate artifacts, runtime traces, and execution-linked outputs
• Distinction between user-originated input, runtime transformation, and agent-generated artifact
• Governance significance of autonomous or semi-autonomous execution state

Boundary

ARCS-AGT applies wherever agent-mediated execution creates, transforms, carries forward, or materially conditions interaction records within the governed environment. It governs runtime-specific record conditions that arise from delegated computational action, including where those conditions are not fully captured by ordinary user-input or static application-state models. This family applies when execution flow, runtime context, or agent-linked artifact formation bears on lifecycle, custody, verification, or other governance treatment.

Agent runtime artifact taxonomy

The following artifact classes are defined for purposes of ARCS-AGT controls. Operators must classify all agent runtime artifacts into one or more of these classes.

Planning trace. The agent's representation of its intended execution path, including task decomposition, step ordering, alternative approaches considered, and reasoning about which path to pursue. Planning traces are deliberative records and SHALL be classified as ephemeral by default.

Tool call artifact. Any record created by or resulting from the agent's invocation of an external tool. Tool call metadata (tool name, timestamp, completion status, latency, error codes) is operational telemetry. Tool call content (arguments passed, responses received, content derived from operator prompts) is deliberative. These components SHALL be governed separately.

Intermediate result. The output of any step in a multi-step workflow that is not the final deliverable. Intermediate results are deliberative records and SHALL be classified as ephemeral unless the operator designates a specific output as a retained deliverable.

Execution trace. The sequence of steps, decisions, tool invocations, and state transitions executed during a session. Structural metadata is operational telemetry. Reasoning content is deliberative. These components SHALL be governed separately.

Error recovery artifact. Any record generated when the agent encounters a failure condition and adapts its execution. Error recovery artifacts are deliberative records. Error metadata (error codes, retry counts, affected tool) is operational telemetry and may be retained separately.

Session state artifact. Any record used to maintain continuity within a single agent session. Session state artifacts are ephemeral and SHALL not persist beyond session termination.

Security-sensitive tool output. Tool output whose content is operationally sensitive independent of its deliberative character. Requires decomposition: the final deliverable is persistent, deliberative intermediates are ephemeral, operational telemetry is retainable.

The corresponding control statements for this family are maintained in the Controls catalog.

Purpose

ARCS-DEL defines the governance domain applicable to delegated execution, persistent memory, and continuity of record across handoff, reuse, or retained contextual state. This family establishes requirements for documenting delegation chains, memory-bearing artifacts, execution inheritance, and other conditions in which record significance persists through autonomous continuation or retained state. Its purpose is to ensure that governance remains attached not only to a single interaction event, but also to the continuity of state carried forward across later action.

Governance focus

• Delegation chains through which action or responsibility continues beyond an initial interaction
• Persistent memory and retained contextual state with governance significance
• Continuity of record across reuse, inheritance, or resumed execution
• Distinction between isolated interaction output and state carried forward into later processing
• Responsibility conditions attached to memory-bearing artifacts and delegated continuation

Boundary

ARCS-DEL applies wherever records or materially significant state persist through delegation, memory, or continued execution beyond a single immediate interaction. It governs conditions under which retained context, inherited state, or delegated continuation carry governance effect forward across time or process boundary. This family applies when what matters is not only the initial record event, but the persistence and later use of state that continues to shape action, interpretation, or responsibility.

Governed persistence

Persistent agent memory is deliberative in content but requires persistence to function. The standard three-class retention model (ephemeral, session-bounded, persistent) does not adequately address this condition. ARCS-DEL introduces governed persistence as a fourth retention class.

A memory store classified as governed persistence SHALL satisfy all of the following: (a) retained on operator-controlled infrastructure or in a storage environment subject to the operator's deletion authority; (b) subject to a defined maximum retention period with automatic purge; (c) excluded from backup systems or synchronization that would create uncontrolled copies; (d) subject to preservation posture under ARCS-PV; and (e) not transmitted to governance infrastructure or third parties as part of receipt generation.

Delegation

An agent operating with delegated authority executes on behalf of the operator or user and may interact with external systems, commit resources, transmit data, or take consequential actions within the scope of its delegation. The record of what the agent was authorized to do, and by whom, is a governance artifact. Delegation artifacts are deliberative records.

Multi-agent and cross-operator considerations

Where a deployment involves multiple agents, each agent-to-agent interaction may generate its own artifact classes. The operator of the orchestrating system is responsible for documenting the custody surface of agent-to-agent communication records. Each agent in a multi-agent deployment SHALL have its artifact classes, retention posture, and custody surface documented independently.

The corresponding control statements for this family are maintained in the Controls catalog.

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.

Conformance to ARCS does not by itself establish privilege, confidentiality, immunity from discovery, immunity from preservation, immunity from liability, legal sufficiency under any specific jurisdiction, insurance coverage, or zero-record operation.

ARCS governs record architecture and disclosure. It does not govern legal outcomes. Legal advice regarding discovery, privilege, and compliance obligations should be obtained from qualified counsel.

ARCS does not define model quality requirements, privacy law compliance in general, information security certification in general, privilege doctrine, substantive discovery law, insurance coverage terms, product performance requirements, AI safety evaluation methodology, red-teaming or adversarial testing methodology, content moderation policy, data protection impact assessment methodology, or model documentation requirements. Where ARCS governs records created by such activities (safety review logs, evaluation datasets, moderation artifacts), the governance applies to the records, not to the activities that generated them.

ARCS does not require non-retention. It requires that retention decisions are explicit, documented, auditable, and architecture-aware. An implementation that retains all interaction records may conform to ARCS if the retention is documented, the custody surface is mapped, and the governance controls are operational.

ARCS does not require any specific retention duration, any specific architecture, any specific vendor, any specific security model, or any specific legal theory. ARCS requires disclosure, mapping, and documentation.

Conformance to ARCS does not establish compliance with any external regulatory framework, including GDPR, CCPA, HIPAA, the EU AI Act, NIST SP 800-53, ISO 27001, or SOC 2. ARCS may be used alongside those frameworks, and an implementation may satisfy overlapping requirements, but ARCS conformance and external regulatory compliance are independently evaluated.

ARCS is complementary to existing security, privacy, and records management frameworks. It addresses a distinct governance layer: the lifecycle and custody of interaction records created during automated system use.

ARCS does not duplicate, replace, or supersede any of these frameworks. An organization may be fully compliant with every framework listed here and still have no governance posture for interaction records. ARCS addresses that gap.

19.1 Version numbering

ARCS uses a major.minor version scheme. A major version increment (e.g., v1 to v2) denotes structural changes to control families, conformance levels, or the surface model that may require reassessment. A minor version increment (e.g., v1.3 to v1.4) denotes additions, clarifications, or expanded coverage that do not invalidate prior conformance claims but may introduce new requirements for higher conformance levels. Errata corrections that do not change normative requirements are denoted by a patch identifier and do not constitute a new version for conformance purposes.

19.2 Transition period

Conformance claims issued under a prior version remain valid for 12 months after publication of a new major version, provided the assessor documents a gap analysis identifying new requirements introduced by the current version. Claims older than 24 months without renewal or gap analysis are considered stale and SHALL not be cited as current conformance evidence.

Minor version increments do not trigger the transition period. An implementation conforming to v1.3 remains conforming through v1.x unless the implementation's declared conformance level requires controls introduced in a later minor version.

19.3 Amendment authority

Amendments to ARCS are published by Vega Commons Project, Inc. The amendment process includes public notice of proposed changes, a comment period for adopters and assessors, and a reconciliation review before publication. Emergency errata affecting the correctness of normative text may be published without a comment period, provided they are documented in the version history with the rationale for expedited publication.

19.4 Backward compatibility

New versions of ARCS SHALL not retroactively invalidate conformance that satisfied all requirements of the prior version at the time of assessment. Where a new version introduces requirements that would change the conformance status of an existing implementation, the transition period in Section 19.2 applies.

19.5 Conformance statement version reference

All conformance statements, attestation artifacts, and assessment reports SHALL reference a specific ARCS version number. Conformance claims that do not reference a version are non-conforming. Where an implementation undergoes reassessment, the new assessment SHALL reference the current version.

Standard: Automated Record Custody Standard (ARCS) v1.0 Published by: Vega Commons Project, Inc. Version: 1.0 Date: April 2026 Status: Normative conformance profile

1. Purpose

This document defines the Foundation Profile for ARCS (Automated Record Custody Standard).

The Foundation Profile identifies the smallest set of controls sufficient for an organization to establish that it has identified its interaction record surface and begun governing it. It is the entry point for organizations that have not previously treated interaction records as a governed record class.

The Foundation Profile is not a full implementation of ARCS; it establishes record identification, custody mapping, and taxonomy as governed activities. Organizations that require preservation, verification, operator boundary, or publish boundary controls should implement the Minimum or Enterprise profiles.

2. Scope

The Foundation Profile applies to any deployment that generates interaction records through automated or software-mediated operation, where the organization has determined that those records should be identified and classified but has not yet established the full lifecycle governance posture required by the Minimum Profile.

Typical Foundation deployments include early-stage AI adoption environments where the record surface has not been formally mapped, organizations beginning a governance assessment against ARCS, and environments where the immediate objective is identification and classification rather than full lifecycle control.

3. Conformance Model

A deployment conforms to the ARCS Foundation Profile if all required controls from the three core families are implemented, required documentation exists, and non-creation claims are auditable where asserted.

Conformance may be declared by operator attestation or internal assessment. The Foundation Profile does not require independent verification, though organizations may elect it.

4. Required Control Families

The Foundation Profile requires controls from three core families and one conditional family:

Non-Creation controls (ARCS-NCR) are required only if the deployment asserts non-retention or non-creation for any record category.

5. Families Not Required at Foundation

The following families are not required for Foundation Profile conformance. They are required at the Minimum or Enterprise level.

Organizations operating under regulatory obligations that require preservation, audit, or legal hold capabilities should implement the Minimum Profile rather than Foundation.

6. What Foundation Establishes

A Foundation-conformant deployment has identified the material record classes generated by its automated systems, mapped where those records persist and who holds custody, and applied a classification taxonomy that distinguishes record types by governance relevance.

These three activities are prerequisites for all higher-level ARCS controls. Lifecycle governance, preservation, verification, and operator boundary controls all depend on the organization knowing what records exist, where they are, and how they are classified.

7. Relationship to Minimum and Enterprise Profiles

The Foundation Profile is a strict subset of the Minimum Profile. Every control required at Foundation is also required at Minimum. An organization that conforms to the Minimum Profile automatically satisfies all Foundation requirements.

The Foundation Profile is intended as a transitional posture. Organizations should plan to advance to Minimum Profile conformance as their governance maturity increases. The Foundation Profile does not represent a permanent governance posture for deployments that generate records subject to regulatory retention, legal hold, or audit obligations.

8. Attestation

Foundation Profile conformance is declared through the ARCS attestation template with the following specifications: declared profile is Foundation, declared maturity level is 1 (Record identification) or 2 (Surface mapping), assessment type is self-assessment, and scope identifies all in-scope deployments and any exclusions with justification.

The attestation template is available at Attestation Template.

Standard: Automated Record Custody Standard (ARCS) v1.0 Published by: Vega Commons Project, Inc. Version: 1.0 Date: March 2026 Status: Normative conformance profile

1. Purpose

This document defines the Minimum Profile for ARCS (Automated Record Custody Standard).

The Minimum Profile identifies the minimum set of controls required for a system to claim conformance with ARCS. It is not a full implementation of all ARCS controls. It defines the smallest implementable subset sufficient to govern risk arising from automated interaction records.

The profile is intended for enterprise deployment, vendor implementations, audit review, procurement evaluation, and regulatory or insurance assessment.

2. Scope

The Minimum Profile applies to systems that generate or process interaction records through automated or software-mediated operation, including conversational systems, automated decision systems, AI-assisted workflows, orchestration platforms, multi-vendor service environments, monitoring and evaluation pipelines, and emerging automated technologies.

Interaction records may include prompts, responses, logs, execution traces, metadata, workflow artifacts, and derived outputs. The Minimum Profile governs the lifecycle and custody of these records.

3. Conformance Model

A system conforms to the ARCS Minimum Profile if all required controls are implemented, required documentation exists, lifecycle posture is defined, custody surface is disclosed, preservation posture is supported, and non-creation claims are auditable where used.

Conformance may be declared by operator attestation, audit review, vendor documentation, or third-party assessment.

The Minimum Profile defines baseline governance, not full assurance. Full ARCS implementation requires all control families and controls.

4. Required Control Families

The Minimum Profile requires controls from the following families:

Non-Creation controls (ARCS-NCR) are required only if the system asserts non-retention or non-creation for any record category.

5. ARCS-LIF: Record Lifecycle Controls

ARCS-LIF Record Lifecycle. Required.

Required controls:

LIF-01. Default retention posture defined for each record category.

LIF-02. Preservation triggers defined: litigation, regulatory inquiry, contractual audit, internal investigation.

LIF-03. Preservation scope defined: categories, systems, vendors, derived artifacts.

LIF-04. Deletion suspended across all custody layers during preservation posture.

LIF-05. User-visible deletion distinguished from backend retention; backend copies disclosed.

LIF-06. Multi-vendor preservation procedure defined.

LIF-07. Exit from preservation posture defined; auditable release procedure required.

LIF-08. Lifecycle documentation available for audit, procurement, and legal evaluation.

Recommended: LIF-09. Non-creation posture defined (required if NCR controls are claimed).

6. ARCS-CUS: Custody Surface Controls

ARCS-CUS Custody Surface. Required.

Required controls:

CUS-01. Custody surface defined across all layers: application, storage, logging, safety, backup, vendor.

CUS-02. Custodians identified: legal entity, system owner, vendor.

CUS-03. Record locations mapped: category to storage system, vendor, retention policy.

CUS-04. Multi-vendor propagation defined: which vendors receive records, what categories.

CUS-05. Vendor retention disclosed: duration, configurability, deletion control.

CUS-08. Backup and archive custody governed.

CUS-09. Custody surface documentation available for audit, procurement, and legal purposes.

Recommended: CUS-06. Vendor preservation behavior during legal hold defined. CUS-07. Derived artifact custody governed: embeddings, classifications, telemetry.

7. ARCS-TAX: Record Taxonomy Controls

ARCS-TAX Record Taxonomy. Required.

Required controls:

TAX-01. All required record categories defined for the system.

TAX-02. Deliberative records classified: prompts, instructions, reasoning traces, parameters.

TAX-03. Exported outputs classified: records delivered outside the custody surface.

TAX-04. Telemetry classified: operational logs, timing, success/fail indicators.

TAX-05. System logs classified: audit records, access logs, error logs.

TAX-07. Derived artifacts classified: embeddings, summaries, evaluation outputs.

TAX-09. Lifecycle rules defined per category: retention period and deletion behavior.

TAX-10. Taxonomy documentation available for audit and procurement.

Recommended: TAX-06. Safety and review records classified: moderation, content classification. TAX-08. Metadata category classified: timestamps, identifiers, routing data.

8. ARCS-OPB: Operator Boundary Controls

ARCS-OPB Operator Boundary. Required.

Required controls:

OPB-01. Operator boundary defined: all systems creating, transmitting, storing, or logging interaction records.

OPB-02. In-scope systems listed: applications, APIs, model providers, storage, logging, analytics, safety, backup.

OPB-03. Vendor inclusion rule defined: vendor is in scope if operator sends records to, causes records at, or relies on vendor for storage or deletion.

OPB-04. Out-of-scope systems documented: why excluded, what records exist, deletion control available.

OPB-05. Boundary change procedure defined: custody surface and retention posture updated when architecture changes.

9. ARCS-PUB: Publish Boundary Controls

ARCS-PUB Publish Boundary. Required.

Required controls:

PUB-01. Publish boundary defined: the point at which a record leaves the governed environment.

PUB-02. Export classification defined: deliberative records distinguished from exported outputs.

PUB-03. Post-publish retention rules documented.

PUB-05. API propagation governed: records transmitted through APIs to external systems.

PUB-06. Publish events and recipients documented for audit purposes.

Recommended: PUB-04. Preservation behavior for exported records defined.

10. ARCS-PV: Preservation and Legal Hold Controls

ARCS-PV Preservation and Legal Hold. Required.

Required controls:

PV-01. Preservation trigger defined: litigation, regulatory inquiry, audit, internal investigation.

PV-02. Legal hold process defined: authority, scope, notification, documentation.

PV-03. Preservation overrides deletion: routine deletion suspended during preservation posture.

PV-04. Preservation responsibility identified across operator and vendor boundaries.

PV-05. Multi-vendor preservation defined: vendor notice, compliance verification.

PV-06. Exit from preservation posture defined: authority required, auditable release.

11. ARCS-VER: Verification and Audit Controls

ARCS-VER Verification and Audit. Required.

Required controls:

VER-01. Documentation current: lifecycle and custody controls maintained.

VER-02. Internal verification: periodic confirmation that controls operate as documented.

VER-03. Vendor verification: vendor confirmation of retention, deletion, and preservation behavior.

VER-04. Preservation verification: preservation posture confirmed when triggered.

VER-05. Documentation available for audit, regulatory, or legal review.

Recommended: VER-06. Attestation: operator can attest to conformance; attestation does not replace documentation.

12. ARCS-NCR: Non-Creation Posture Controls

Non-Creation controls are required only if the system claims non-creation or non-retention for any record category. Systems that do not make such claims are not required to implement ARCS-NCR.

ARCS-NCR Non-Creation Posture. Required if claimed.

NCR-01. Non-creation declaration: auditable claim that a specific record category is not created.

NCR-02. Memory-only processing: category processed in volatile memory only, never written to storage.

NCR-03. Non-retention declaration: auditable claim that records are not retained beyond session.

NCR-04. Preservation posture interaction: how preservation obligations interact with non-creation claims.

NCR-05. Non-creation documentation: sufficient for procurement, audit, and legal evaluation.

13. Conformance Statement

A system may use the following conformance statement only if all required controls in this profile are implemented and documentation is available for audit, procurement, or regulatory review:

"This system conforms to ARCS Minimum Profile v1.0 (Automated Record Custody Standard)."

Conformance requires implementation of all Required controls in Sections 5 through 11. Recommended controls are not required for conformance. Non-Creation controls (Section 12) are required only if non-creation or non-retention is claimed.

Standard: Automated Record Custody Standard (ARCS) v1.0 Published by: Vega Commons Project, Inc. Version: 1.0 Date: March 2026 Status: Normative conformance profile

1. Purpose

This document defines the Enterprise Profile for ARCS (Automated Record Custody Standard).

The Enterprise Profile builds on the ARCS Minimum Profile v1.0 by defining additional controls appropriate for organizations that deploy automated systems at scale, operate across multiple business units or jurisdictions, contract with multiple AI or automation vendors, face material legal discovery or regulatory inquiry exposure, or are subject to insurance, audit, or procurement due diligence.

The Enterprise Profile does not replace the Minimum Profile. It extends it. All Minimum Profile required controls remain required in this profile.

2. Scope

The Enterprise Profile applies to organizations that deploy automated or AI-assisted systems with interaction records across multiple departments, business units, or subsidiaries; operate multi-vendor AI or automation environments involving two or more model providers, logging services, or orchestration platforms; maintain contractual obligations that may require audit, preservation, or production of interaction records; are subject to material regulatory oversight, insurance coverage requirements, or litigation exposure related to AI or automated systems; or have internal legal, compliance, or risk functions with governance responsibilities over automated systems.

3. Profile Structure

The Enterprise Profile uses two control tiers:

Enterprise Enhanced controls address complexity that arises from scale, multi-vendor environments, regulated industries, and material legal exposure. They are calibrated to what a reasonable enterprise risk or compliance function would implement given that context.

4. Required Control Families

The Enterprise Profile requires controls from all ARCS control families. ARCS-NCR controls are required if non-creation is claimed.

5. ARCS-LIF: Record Lifecycle Controls

ARCS-LIF Record Lifecycle.

Required controls: LIF-01 through LIF-08, as defined in the Minimum Profile.

Enterprise Enhanced controls:

LIF-E1. Retention posture reviewed and updated at defined intervals (at minimum annually or on material system change).

LIF-E2. Retention posture documented at business-unit or subsidiary level where systems vary.

LIF-E3. Lifecycle changes subject to internal approval workflow before implementation.

6. ARCS-CUS: Custody Surface Controls

ARCS-CUS Custody Surface.

Required controls: CUS-01 through CUS-09, as defined in the Minimum Profile.

Enterprise Enhanced controls:

CUS-E1. Custody surface map maintained as a governed document with version control and owner assignment.

CUS-E2. Vendor custody obligations incorporated into vendor contracts or service agreements.

CUS-E3. Custody surface reviewed when new vendors are onboarded or existing vendor services change materially.

CUS-E4. Cross-jurisdiction custody documented where records may be subject to different legal regimes.

7. ARCS-TAX: Record Taxonomy Controls

ARCS-TAX Record Taxonomy.

Required controls: TAX-01 through TAX-10, as defined in the Minimum Profile.

Enterprise Enhanced controls:

TAX-E1. Record taxonomy reviewed and updated at defined intervals or on material system change.

TAX-E2. Taxonomy applied consistently across business units or subsidiaries operating the same system.

TAX-E3. Taxonomy documented in sufficient detail for production in legal or regulatory proceedings.

8. ARCS-OPB: Operator Boundary Controls

ARCS-OPB Operator Boundary.

Required controls: OPB-01 through OPB-05, as defined in the Minimum Profile.

Enterprise Enhanced controls:

OPB-E1. Boundary definition maintained as a governed document with owner, version, and approval.

OPB-E2. Boundary reviewed at defined intervals and on acquisition, divestiture, or material architecture change.

OPB-E3. Governance responsibility for ARCS controls assigned to a named function (for example legal, compliance, or IT risk).

9. ARCS-PUB: Publish Boundary Controls

ARCS-PUB Publish Boundary.

Required controls: PUB-01 through PUB-06, as defined in the Minimum Profile.

Enterprise Enhanced controls:

PUB-E1. Publish events logged with sufficient metadata to support later identification and production.

PUB-E2. Third-party recipient data retention obligations incorporated into applicable agreements.

10. ARCS-PV: Preservation and Legal Hold Controls

ARCS-PV Preservation and Legal Hold.

Required controls: PV-01 through PV-06, as defined in the Minimum Profile.

Enterprise Enhanced controls:

PV-E1. Legal hold process integrated with legal department or outside counsel hold management workflow.

PV-E2. Vendor legal hold capabilities confirmed in writing at onboarding and reviewed annually.

PV-E3. Litigation hold notifications to vendors documented and retained.

PV-E4. Preservation scope includes business messaging and collaboration tools that may contain interaction record references.

11. ARCS-VER: Verification and Audit Controls

ARCS-VER Verification and Audit.

Required controls: VER-01 through VER-06, as defined in the Minimum Profile.

Enterprise Enhanced controls:

VER-E1. Verification cycle defined at fixed intervals (at minimum annually).

VER-E2. Verification scope includes all in-scope vendors with custody of interaction records.

VER-E3. Verification results documented and retained; material gaps escalated.

VER-E4. ARCS governance assigned to a committee, working group, or named responsible function.

VER-E5. ARCS controls integrated into enterprise risk management or GRC framework.

12. ARCS-NCR: Non-Creation Controls (If Claimed)

Complete this section only if the system claims non-creation or non-retention for any record category.

ARCS-NCR Non-Creation Posture. Required if claimed.

Required controls: NCR-01 through NCR-05, as defined in the Minimum Profile.

Enterprise Enhanced controls:

NCR-E1. Non-creation claims reviewed by legal or compliance function before assertion.

NCR-E2. Technical controls supporting non-creation verified by independent internal or external review.

13. Enterprise Conformance Statement

A system may use the following conformance statement only if all Minimum Profile required controls and all Enterprise Enhanced controls are implemented and documentation is available for review:

"This system conforms to ARCS Enterprise Profile v1.0 (Automated Record Custody Standard), incorporating all controls required by the ARCS Minimum Profile v1.0."

Use of this statement requires conformance with all Required and Enterprise Enhanced controls in Sections 5 through 11. NCR controls are required only if non-creation is claimed.

14. Relationship to Other Frameworks

Enterprise organizations typically operate within existing risk management frameworks. The following guidance supports integration:

This annex provides an extended glossary of terms used throughout ARCS. For normative definitions, see Section 3. This annex is informative.

Core Record Concepts

Interaction Record — Any artifact created, retained, transmitted, or derived by an automated system during or as a result of human-directed use, including artifacts held by the operator or by any vendor within the custody surface.

Deliberative Record — An interaction record that captures the reasoning process, intent, or decision-making sequence of the operator or user, as distinguished from final outputs or operational telemetry.

Derived Record — Any artifact created outside the primary system as a result of an interaction, including copied text, downloaded files, generated documents, stored notes, and database entries.

Intermediate Record — Artifacts created during system processing but not directly visible to the user, including agent traces, tool call logs, retrieval queries, and runtime state.

Material Record — Any interaction record reasonably likely to be relevant in discovery, audit, or governance review.

Surface Concepts

Custody Surface — The complete set of systems, vendors, and storage locations where copies of interaction records may exist.

Discovery Surface — The subset of the record surface reasonably susceptible to legal production.

Review Surface — The set of systems in which interaction records may be accessed by humans other than the user.

Unknown Surface — Any portion of the record or custody surface that cannot be conclusively documented.

Lifecycle Concepts

Default Retention Posture — The record categories, retention durations, and deletion behaviors that apply in ordinary system operation, in the absence of any preservation obligation.

Preservation Posture — The operational state that applies when litigation is pending or anticipated, a preservation demand has been received, or an investigation has been opened.

Non-Creation — An architectural condition in which a specific category of interaction record is not created, as distinguished from creation followed by deletion.

This checklist supports operator self-assessment against ARCS requirements. It is informative. For normative conformance requirements, see Section 16.

ARCS-LIF: Record Lifecycle Controls

• LIF-01: Default retention posture defined for each record category
• LIF-02: Preservation triggers defined
• LIF-03: Preservation scope defined
• LIF-04: Deletion suspended upon preservation trigger
• LIF-05: User-visible deletion distinguished from backend retention
• LIF-06: Multi-vendor preservation procedure defined
• LIF-07: Exit from preservation posture defined
• LIF-08: Lifecycle disclosure available for audit, procurement, and legal evaluation
• LIF-09: Non-creation controls defined where applicable

ARCS-CUS: Custody Surface Controls

• CUS-01: Custody surface defined across all layers
• CUS-02: Custodians identified
• CUS-03: Record locations mapped
• CUS-04: Multi-vendor propagation defined
• CUS-05: Vendor retention disclosed
• CUS-06: Custody surface defined during preservation
• CUS-07: Derived artifact custody governed
• CUS-08: Backup and archive custody governed
• CUS-09: Custody surface disclosure available

ARCS-TAX: Record Taxonomy Controls

• TAX-01: All required record categories defined
• TAX-02: Deliberative records classified
• TAX-03: Exported outputs classified
• TAX-04: Telemetry classified
• TAX-05: System logs classified
• TAX-06: Safety and review records classified
• TAX-07: Derived artifacts classified
• TAX-08: Metadata classified
• TAX-09: Lifecycle rules defined per category
• TAX-10: Taxonomy documentation available

ARCS-OPB: Operator Boundary Controls

• OPB-01: Operator boundary defined
• OPB-02: In-scope systems listed
• OPB-03: Vendor inclusion rule defined
• OPB-04: Out-of-scope systems documented
• OPB-05: Boundary change procedure defined

ARCS-PUB: Publish Boundary Controls

• PUB-01: Publish boundary defined
• PUB-02: Exported output classification defined
• PUB-03: Post-publish retention rules documented
• PUB-04: Preservation at publish boundary defined
• PUB-05: API propagation governed
• PUB-06: Publish events and recipients documented

ARCS-NCR: Non-Creation Controls (if claimed)

• NCR-01: Non-creation declaration documented
• NCR-02: Memory-only processing documented
• NCR-03: Non-retention declaration documented
• NCR-04: Preservation posture interaction defined
• NCR-05: Non-creation documentation available

ARCS-PV: Preservation and Legal Hold Controls

• PV-01: Preservation trigger defined
• PV-02: Legal hold process defined
• PV-03: Preservation overrides deletion
• PV-04: Preservation responsibility identified
• PV-05: Multi-vendor preservation defined
• PV-06: Exit from preservation posture defined

ARCS-VER: Verification and Audit Controls

• VER-01: Documentation current
• VER-02: Internal verification completed
• VER-03: Vendor verification obtained
• VER-04: Preservation verification completed
• VER-05: Documentation available for audit
• VER-06: Attestation available

Minimum required fields for a record surface map per Section 7. This template is informative.

Completion notes

Unknown surfaces must be documented as unknown, not omitted. An operator claiming Level 4 conformance must have no undocumented surfaces in the normal operating record set.

Minimum required fields for a custody surface map per Section 7. This template is informative.

Minimum required fields for a configuration exposure matrix per Section 5. This template is informative.

Completion notes

Each cell should describe the actual behavior, not vendor marketing language. Where behavior is unknown, mark Unknown. Where behavior differs by vendor within a mode, note the variance.

Minimum required fields for a feedback routing table per Section 6. This template is informative.

Completion notes

A routing event occurs whenever an interaction record enters a different lifecycle, system, or retention regime. All routing events must be documented, including automated routing triggered by system behavior rather than explicit user action.

Required evidence for an ARCS conformance claim. This checklist is informative.

Required documentation

• Record surface map (Annex C format or equivalent)
• Custody surface map (Annex D format or equivalent)
• Configuration exposure matrix (Annex E format or equivalent)
• Feedback routing table (Annex F format or equivalent)
• Retention documentation per record class
• Deletion documentation per record class
• Preservation override procedure
• Multi-vendor surface assessment (where applicable)
• Agent runtime documentation (where applicable)
• Non-creation documentation (where claimed)
• Conformance statement (Annex H format)

For Level 4 conformance

All items above plus evidence of:

• Internal verification completed
• Vendor verification obtained for all material custodians
• Preservation posture is operational

For Minimum Profile conformance

All Required items above.

For Enterprise Profile conformance

All items above plus:

• Governed document status for all maps and matrices
• Vendor legal hold capability confirmed in writing
• ARCS governance assigned to named function

ARCS CONFORMANCE STATEMENT

System name: _______________
Operator / deploying entity: _______________
Deployment mode(s): _______________
Version / configuration identifier: _______________
Date of assessment: _______________
Declared conformance profile: _______________

Excluded components (with justification):
_______________

Known non-conforming components:
_______________

Responsible assessor: _______________
Assessment type: [ ] Operator self-assessment  [ ] Internal audit  [ ] Third-party assessment

Record-bearing components assessed:
_______________

Record surface map version and date: _______________
Custody surface map version and date: _______________
Configuration matrix version and date: _______________
Routing table version and date: _______________

Preservation posture documented: [ ] Yes  [ ] No
Unknown surfaces identified: [ ] Yes  [ ] No  [ ] None
Fragmented custody: [ ] Yes  [ ] No

Non-creation claims made: [ ] Yes (NCR controls required)  [ ] No

Declaration: The undersigned attests that the above assessment was performed
in accordance with ARCS v1.0 (Automated Record Custody Standard).

Signature: _________________________ Date: _____________
Name: _____________________________
Title: _____________________________
Organization: ______________________

This annex provides guidance for organizations conducting or commissioning independent assessment of ARCS conformance. It is informative.

When independent assessment applies

Independent assessment is not required for Minimum Profile conformance. Organizations may self-assess against the Minimum Profile.

Independent assessment is recommended for Enterprise Profile conformance and for any conformance claim that will be presented to third parties in insurance, procurement, or regulatory contexts.

Assessor qualifications

An independent assessor should demonstrate:

Technical qualifications: understanding of AI system architecture, ability to read system logs and configuration files, familiarity with database systems and cloud storage.

Governance qualifications: understanding of records management principles, familiarity with discovery obligations and preservation requirements, understanding of multi-vendor custody fragmentation.

Professional qualifications: no undisclosed conflicts of interest with the operator, professional liability insurance or institutional backing where applicable.

Assessment scope

The assessor should review: record surface map, custody surface map, configuration exposure matrix, retention and deletion documentation, preservation procedures, agent runtime documentation where applicable, and any claimed non-creation verifications.

The assessor should verify that documented surfaces match actual system behavior where technically accessible.

Assessment output

The assessor should produce a written report identifying: the system assessed, the documents reviewed, the procedures performed, findings for each control area evaluated, and a conformance level recommendation with supporting rationale.

Limitations

Assessment confirms that controls appear to be in place at the time of review. It does not guarantee future behavior or vendor compliance beyond what was verified. Assessors are not responsible for legal outcomes or for changes in system behavior after the assessment date.

ARCS defines two conformance architectures that serve different purposes. This annex provides an approximate crosswalk between them for operators using both. This annex is informative. Neither model takes normative precedence over the other. The maturity levels and the conformance profiles are designed to evolve independently.

The two models and their roles

Maturity levels (Section 16.3) describe governance coverage — how completely an implementation has documented and governed its record environment. They answer: how far along are we? They are useful for strategic planning, reporting to boards and leadership, and benchmarking progress over time.

Conformance profiles (Section 16.2) describe control implementation — which specific control families have been satisfied. They answer: which controls are implemented? They are useful for procurement evaluation, audit, and contractual compliance requirements.

Neither model is superior. They serve different audiences and different purposes. Procurement and audit contexts generally prefer the profiles because individual controls are directly verifiable. Governance reporting and strategic planning generally prefer the maturity levels because they convey coverage at a glance.

Approximate crosswalk

The following table shows the approximate correspondence between maturity levels and conformance profiles. The relationship is directional, not definitional — satisfying a profile does not automatically confer a maturity level, and reaching a maturity level does not automatically satisfy a profile.

Level 4 as the institutional minimum

Level 4 corresponds to the Minimum Profile. An operator claiming Level 4 should be able to declare Minimum Profile conformance. Both designations indicate that the 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.

Level 4 is the institutional minimum for ARCS conformance. Lower levels represent governance in progress.

Level 5 and the Enterprise Profile

Level 5 corresponds approximately to the Enterprise Profile combined with agent runtime coverage. The Enterprise Profile does not by itself confer Level 5, because Level 5 requires no unknown surfaces and documented governance of advanced runtime artifacts, which are not required by the Enterprise Profile alone.

Foundation Profile and the maturity ladder

The Foundation Profile (ARCS-LIF, ARCS-CUS, ARCS-TAX) sits between Level 1 and Level 2 on the maturity ladder. It is sufficient to establish baseline record identification and surface mapping but does not require the full disclosure controls that distinguish Level 2 from Level 1. Organizations satisfying the Foundation Profile are typically at Level 1 to Level 2, progressing toward Minimum Profile conformance.

Using both models together

An operator may find it useful to declare both a maturity level and a conformance profile in a single statement. For example:

This system is assessed at ARCS Maturity Level 4 and satisfies ARCS Minimum Profile conformance.

Or, for partial progress:

This system is assessed at ARCS Maturity Level 2. The following control families are satisfied: ARCS-LIF, ARCS-CUS, ARCS-TAX. Remaining families are in progress.

These statements are complementary and independently verifiable.

This crosswalk maps ARCS control families to NIST SP 800-53 Rev. 5 control families. It is informative and does not establish normative equivalence. The crosswalk is intended to help organizations already operating under SP 800-53 understand where ARCS addresses gaps, complements existing controls, or operates in adjacent domains.

This crosswalk extends the appendix of VCP's NIST Public Comment (Docket NIST-2025-0035, Document No. 2026-00206, filed March 9, 2026), which proposed adaptations to AU, MP, SI, and AC for agentic AI interaction data.

Relationship summary

ARCS does not replace SP 800-53 controls. ARCS operates in the domain of interaction record lifecycle and custody, which SP 800-53 does not specifically address. An organization implementing both would use SP 800-53 for system security and ARCS for interaction record governance. The two frameworks are complementary.

Control family crosswalk

Key finding

The NIST filing's proposed SP 800-53 adaptations (AU-3 telemetry decoupling, MP-6 ephemeral sanitization, SI-7 memory boundary isolation, AC-3 gated retrieval) each have a corresponding ARCS control family or specific control. ARCS provides the governance-layer specification; SP 800-53 adaptations provide the security-layer implementation requirements. An organization satisfying the NIST-proposed SP 800-53 adaptations and ARCS controls together would have both the security architecture and the governance documentation required for defensible interaction record management.

Scope note

This crosswalk covers the relationship between ARCS and SP 800-53 Rev. 5 specifically. ARCS also has relationships to ISO 27001, ISO 42001, NIST AI RMF, EU AI Act, GDPR/CCPA/HIPAA, and SOC 2. Those crosswalks are addressed in separate context and instrument documents.

Standard: ARCS v1.0 Published by: Vega Commons Project, Inc. Status: Formal Annex Function: Verification and attestation procedures supporting ARCS implementation and conformance claims

Date: March 4, 2026

Classification: Governance Specification / Audit Protocol

Version: 4.0

Cross-references: ARCS-VER; Technical Enforcement; Conformance; Instrument materials

1. Purpose

This protocol defines the verification procedures used to evaluate whether an operator's AI interaction infrastructure implements the controlled existence requirements described in the ARCS standard. The objective is to establish whether prompt and response content classified as ephemeral is prevented from entering persistent storage systems within the operator's infrastructure. The protocol defines test scope, evidence artifacts, verification procedures, pass/fail criteria, and attestation outputs. This document does not define architectural requirements. Architectural requirements are defined in the ARCS standard and the Technical Enforcement Appendix.

2. Scope

The protocol applies to operator-controlled infrastructure that processes AI interaction sessions. It evaluates whether ephemeral interaction content is prevented from entering the following operator-controlled persistence surfaces: centralized logging systems, application telemetry systems, error monitoring systems, monitoring and observability pipelines, database storage layers, backup and snapshot systems, and long-term analytics storage systems.

The protocol evaluates operator-side infrastructure only. Vendor-side infrastructure operated by model providers or external API services is outside the scope of this protocol unless the operator explicitly includes those systems within the verification boundary.

3. Definitions

Ephemeral interaction content. Prompt and response content classified by the operator as non-persistent and intended to exist only for the duration of a session.

Persistent storage. Any storage system that retains information beyond the lifetime of a user interaction session. Examples include logs, databases, backups, message queues, analytics storage, and monitoring platforms.

Controlled existence. An architectural property in which ephemeral interaction content exists only within the execution context of a session and is not written to persistent storage.

Verification artifact. A record produced during testing that demonstrates configuration state, system behavior, or inspection results.

Sovereignty receipt. A cryptographic attestation artifact generated at session close documenting what retention class governed the session, what destruction schedule applied, and that the governance controls executed as specified. The receipt does not store interaction content.

4. Verification Categories

Verification is conducted across eight categories corresponding to known persistence surfaces within typical application infrastructure.

4.1 Application Logging

Verification confirms that prompt and response content is not written to centralized logging systems. Evidence includes logging configuration exports, redaction or drop-filter configuration, and test execution logs showing content exclusion. Inspection verifies that prompt content fields and response content fields are excluded from logging payloads, and that structured logging frameworks omit interaction payload fields.

4.2 Telemetry and Monitoring Systems

Verification confirms that monitoring pipelines do not capture interaction content. Evidence includes monitoring agent configuration, telemetry schema definitions, and sampled telemetry payloads. Inspection verifies that metrics capture operational signals only and that no prompt or response payloads appear in telemetry events.

4.3 Error Monitoring and Exception Reporting

Verification confirms that exception tracking systems do not capture interaction content. Evidence includes error monitoring configuration, example exception payloads, and payload redaction settings. Inspection verifies that exception reports do not include prompt text or response text, and that stack traces do not serialize interaction payloads.

4.4 Database and Application Storage

Verification confirms that ephemeral interaction content is not written to persistent database systems. Evidence includes schema inspection, query logging inspection, and database sampling reports. Inspection verifies that no prompt content is stored in persistent tables, no response content is stored in persistent tables, and session metadata does not contain serialized interaction content.

4.5 Backup and Snapshot Systems

Verification confirms that infrastructure backups do not contain ephemeral interaction content. Evidence includes backup configuration, snapshot sampling inspection, and retention policies. Inspection verifies that sampled backups contain no prompt or response payloads and that infrastructure backups contain only configuration and system state.

4.6 Session Lifetime Controls

Verification confirms that interaction content exists only within session memory during execution. Evidence includes session management configuration, execution flow documentation, and test runs demonstrating in-memory processing. Inspection verifies that interaction content is processed in memory and that session data is destroyed at session termination.

4.7 Sovereignty Receipt Integrity

Where operators generate sovereignty receipts, the verification process confirms the integrity of those receipts. Evidence includes receipt signature verification logs, key management description, and receipt samples. Inspection verifies that receipt signatures validate against the operator's declared key and that receipts reference the correct retention policy identifier. Sovereignty receipts represent attestations of execution events. They do not constitute independent proof of destruction outside the verification scope.

4.8 Legal Hold Override Mechanism

Verification confirms that the retention class switching mechanism required for legal holds operates correctly. Evidence includes documentation of the legal hold activation procedure, test execution of a retention class switch from ephemeral to persistent, verification that the switch is logged and auditable, and verification that the switch reversal (persistent back to ephemeral upon hold release) functions correctly. This category confirms that the operator can comply with preservation obligations without undermining the controlled existence architecture for non-held sessions. The legal hold override test is architecturally critical because without it, the entire controlled existence framework is vulnerable to the objection that non-retention constitutes evidence destruction by design.

5. Evidence Artifacts

The following artifacts are collected during verification: logging configuration exports, telemetry configuration exports, exception monitoring configuration, database schema inspection reports, snapshot sampling reports, session lifecycle test logs, receipt signature verification logs, legal hold activation and deactivation test logs, and change logs for logging and telemetry configuration. Artifacts must be sufficient for an independent reviewer to understand system behavior and to evaluate whether ephemeral interaction content enters any persistent storage pathway.

6. Pass and Fail Criteria

Verification fails if any of the following conditions are observed: prompt or response content appears in persistent logs, prompt or response content appears in monitoring or telemetry payloads, prompt or response content appears in exception reports or error monitoring systems, prompt or response content appears in database storage, backups or snapshots contain interaction payloads, receipt signatures fail verification where receipts are used, or the legal hold switching mechanism does not function as documented.

Verification passes if inspection and testing demonstrate that ephemeral interaction content does not enter persistent storage systems within the defined scope.

7. Verification Frequency

Operators implementing ARCS controls should perform verification under the following conditions: initial deployment of controlled existence architecture, material changes to logging or telemetry pipelines, material changes to AI interaction infrastructure, and periodic verification at least once every twelve months. Verification may be performed internally or by an independent assessor. Independent assessment is recommended for operators seeking third-party attestation for insurance, procurement, or regulatory purposes.

8. Attestation Output

Verification results may be summarized in an attestation letter. The attestation letter should include the verification scope, systems included within the verification boundary, verification date, summary of procedures performed, and a statement of observed results.

The attestation letter should not represent the verification as a guarantee of non-existence of all records. The attestation confirms only that the defined procedures were performed and that no persistent storage of ephemeral interaction content was observed within the verification scope and time period.

9. Limitations

Verification procedures evaluate system behavior within a defined scope and time period. Verification cannot guarantee the absence of records outside the scope of testing or within infrastructure not included in the verification boundary. Verification does not evaluate retention practices of external service providers unless explicitly included in the scope. Verification does not address legal hold compliance, which is governed by the operator's retention class switching procedures as described in the ARCS standard. Verification does not constitute legal advice regarding compliance with any specific regulatory framework. Organizations implementing ARCS should have legal counsel review the applicable retention requirements for their specific jurisdiction, sector, and data processing activities before relying on verification results for compliance purposes.

Vega Commons Project, Inc.

Verification and Attestation Protocol | v4.0 | March 4, 2026

This annex summarizes the legal and discovery context in which ARCS operates. It describes how AI interaction records intersect with existing discovery rules, privilege doctrine, and preservation obligations. This annex is informative and does not constitute legal advice. Organizations should obtain guidance from qualified counsel on jurisdiction-specific discovery, privilege, and compliance obligations.

M.1 Interaction records as electronically stored information

AI interaction records, including prompts, responses, reasoning traces, tool call logs, agent memory, and derived artifacts, qualify as electronically stored information (ESI) under existing civil discovery rules. Federal Rules of Civil Procedure 26, 34, and 45 govern the production of ESI in federal litigation. State equivalents apply in state proceedings. No court has recognized a general privilege for AI interaction records, and no court has held that the automated nature of the records exempts them from standard ESI treatment.

Records held by AI service providers (model providers, API hosts, infrastructure vendors) may be subpoenaed under Rule 45 or equivalent third-party production rules regardless of the operator's retention posture. The custody surface model defined in ARCS §7 (ARCS-CUS) addresses this exposure by requiring operators to map all locations where records may exist, including vendor-held copies.

M.2 Doctrinal boundaries: the retention exposure gap

Two judicial proceedings define the current doctrinal boundaries for AI interaction record discoverability.

The lower boundary (floor) is established by proceedings in which consumer AI interaction logs were treated as ordinary discoverable ESI, with no special privilege, no heightened showing requirement, and no distinction between AI-generated records and other electronic records. This establishes the baseline: consumer-tier AI interaction records are producible under standard discovery rules.

The upper boundary (ceiling) is established by proceedings in which attorney prompts to AI systems were analyzed under the work product doctrine. The court engaged with work product analysis under Hickman v. Taylor, requiring that the records be created by or at the direction of an attorney, in anticipation of litigation, and reflecting legal mental processes. This is a narrow exception that applies only when all three conditions are satisfied.

The space between these boundaries, the retention exposure gap, is the territory ARCS addresses. Records that fall within this gap are discoverable but not privileged. They include professional use of AI systems (legal research, medical reasoning, financial analysis), enterprise operational use, API-integrated workflows, and any interaction where the operator did not anticipate litigation at the time of use.

M.3 Structural doctrinal findings

The following propositions are supported across the reviewed case law and doctrinal authorities:

Interaction records qualify as ESI under existing discovery rules, and no special showing is required to obtain them. Provider logs held by third parties may be subpoenaed directly regardless of the operator's deletion posture. Privilege depends on retention architecture (how records are created, stored, and governed), not on platform labels or marketing claims. Work product protection is narrow and requires an attorney directing the work, anticipated litigation at the time of creation, and content reflecting legal mental processes. Consumer AI use has the least protection from discovery because the conditions for privilege or work product are almost never met. Enterprise deployment changes the custody surface and may create additional governance obligations, but does not eliminate discovery exposure. Litigation hold obligations may override deletion policies and retention architecture, and failure to preserve records subject to a hold may result in spoliation sanctions. The volume of retained records does not prevent discovery; courts routinely require production of large electronic record sets with proportionality analysis under Rule 26(b)(1). Feedback mechanisms, safety review systems, and content moderation processes may create additional records with distinct lifecycle characteristics that expand the discoverable record set. Professional use of AI systems (by lawyers, physicians, financial advisors, and other regulated professionals) increases exposure and may impose affirmative duties regarding retention awareness, competence in understanding AI system behavior, and disclosure of AI-assisted work product.

M.4 Relevance to ARCS control families

ARCS does not define privilege doctrine, discovery procedures, or substantive legal obligations. ARCS defines governance controls that produce the documentation and architectural posture an operator needs to respond to discovery obligations, preservation demands, and regulatory inquiries in a structured manner rather than an ad hoc one.

ARCS-LIF (record lifecycle) defines the retention posture that determines what records exist when a discovery demand arrives. ARCS-CUS (custody surface) maps where those records are located across vendor and infrastructure boundaries, which is the first question in any production response. ARCS-TAX (record taxonomy) classifies records by category, enabling proportional review and category-specific privilege analysis rather than undifferentiated production. ARCS-NCR (non-creation posture) documents architectural decisions to prevent record creation, which is legally distinct from post-creation deletion and carries different implications for spoliation analysis. ARCS-PV (preservation) defines the mechanism for suspending deletion when litigation hold obligations arise, and documents the scope and duration of the hold. ARCS-VER (verification) provides the attestation infrastructure for demonstrating governance posture to courts, regulators, and opposing counsel.

M.5 Preservation and spoliation

An operator that implements non-creation or non-retention architecture under ARCS-NCR should document the architectural decision, the record categories affected, and the date the architecture was deployed. If a litigation hold obligation arises, ARCS-PV requires suspension of deletion controls and notification to vendors. The documentation produced by ARCS-NCR and ARCS-PV collectively establishes that non-retention was an architectural design decision predating the litigation, not a destruction decision made after preservation obligations attached. This distinction is legally significant in spoliation analysis, where intent and timing are evaluated by the court.

ARCS does not guarantee that a non-retention architecture will be found legally sufficient. Courts evaluate preservation obligations based on the facts of each case, and an operator may be required to modify its architecture to preserve records in future interactions even if it did not retain records from past interactions. ARCS provides the governance framework for documenting the architectural posture and responding to preservation demands in a structured manner.

M.6 Cross-jurisdiction considerations

Discovery rules vary across jurisdictions. Common-law jurisdictions (United States, United Kingdom, Canada, Australia, Singapore) generally provide broader discovery rights than civil-law jurisdictions. The EU AI Act Article 12 mandates logging for high-risk AI systems, which creates affirmative retention obligations that interact with discovery exposure. ARCS control families apply regardless of jurisdiction, but the legal consequences of retention and non-retention postures are jurisdiction-specific.

Annex M is informative. It provides legal context for ARCS governance controls but does not modify the normative requirements of the standard. This annex does not constitute legal advice.

This annex describes the structural relationship between infrastructure governance for communications networks (the conduit model) and interaction record governance for AI systems (the custody model). The comparison identifies the governance principles that have been applied to prior communications infrastructure and the extent to which those principles have or have not been applied to AI interaction records. This annex is informative.

N.1 The conduit model for communications infrastructure

Communications infrastructure governance, developed across common carrier doctrine, telecommunications regulation, and internet governance frameworks, operates on the principle that the infrastructure operator (the conduit) does not own, retain, or unilaterally govern the content that flows through the infrastructure.

This principle has been implemented through several regulatory instruments across different technology generations. Common carrier doctrine, originating in English common law and codified in the Communications Act of 1934, establishes that infrastructure operators bear a duty to provide service impartially and that the operator's commercial interests do not override the user's interest in the content. Net neutrality principles, articulated by Wu (2003) and grounded in the end-to-end design principle described by Saltzer, Reed, and Clark (1981), extend conduit-content separation to internet traffic: the network transports data without inspecting, prioritizing, or retaining it. The Communications Assistance for Law Enforcement Act (CALEA) establishes that lawful interception of communications requires judicial authorization and probable cause, and that records of user communications are not retained as a default byproduct of infrastructure operation. Section 230 of the Communications Decency Act provides that the conduit is not liable for user-generated content that passes through its infrastructure.

The structural achievement of this framework is a governance architecture in which the conduit does not retain the content by default, compelled production of content requires judicial process with procedural safeguards, and the conduit's operational and commercial interests are subordinated to governed retention rules.

N.2 AI platforms as structural inversion of the conduit model

AI platforms operate under an architecture that inverts the conduit model on every structural dimension.

Regarding ownership of content: under conduit governance, the infrastructure operator does not own the content. AI platforms retain interaction records as vendor-owned data assets, governed by vendor terms of service rather than user-controlled lifecycle policies.

Regarding default retention posture: conduit governance presumes non-retention of content unless legal process compels otherwise. AI platforms retain interaction records by default, and non-retention requires user-initiated configuration on a per-platform, per-tier basis with no standardized verification mechanism.

Regarding compelled production standard: interception of ISP traffic requires a warrant, probable cause, and judicial authorization. Production of AI interaction records requires only a standard civil discovery request or subpoena, with no warrant, no probable cause showing, and no judicial pre-authorization required.

Regarding use of content: ISPs are generally prohibited from using the content of user communications for commercial purposes without consent and legal process. AI platforms use interaction records for model training, safety review, analytics, and product improvement as a standard business practice, governed by terms of service.

Regarding jurisdictional mapping: ISP infrastructure is regionally situated, and user traffic passes through infrastructure governed by the user's jurisdiction. AI platform infrastructure stores records in data centers the user did not choose, in jurisdictions the user cannot verify, under retention policies the user did not set.

N.3 The governance gap

Communications infrastructure has a governance framework, assembled across decades of regulatory development, that establishes how the conduit relates to the content. AI interaction records have no equivalent governance framework. No retention standard specifies defaults, limits, or lifecycle controls. No production standard constrains access to interaction records beyond the ordinary civil discovery rules that apply to all ESI. No framework requires the platform to separate the processing function (generating a response to the user's input) from the retention function (storing the record of what the user asked, how the user reasoned, and what the system produced).

In a typical AI deployment, two independent custody surfaces exist: the operator surface (interaction content traversing the operator's application stack, databases, caches, logs, analytics pipelines, backups, and observability tools) and the vendor surface (interaction content retained by the AI service provider for safety monitoring, abuse prevention, debugging, compliance, or legal hold). A vendor commitment not to use interaction content for model training does not address custody; training exclusion does not eliminate retention. Deployment-scale AI features generate more than visible chat history, including moderation flags, safety classifier outputs, abuse monitoring markers, human review queue records, operational logs, and metadata sufficient to link a user, a session, and an output to internal systems.

This gap compounds when interaction records propagate across vendor boundaries through connected-application architectures. Each integration point (API endpoint, tool connection, agent delegation) is a potential custody boundary where records pass from operator-governed infrastructure to vendor-governed infrastructure with no lifecycle controls. Multi-vendor propagation expands the custody surface in ways the operator may not be able to verify or constrain.

N.4 ARCS control families as the governance layer

ARCS addresses the governance gap by defining control families that correspond structurally to the components of the conduit governance model, translated from physical communications infrastructure to interaction record infrastructure.

ARCS-LIF (Record Lifecycle) establishes that retention is a governed decision rather than a platform default. Operators define retention posture, destruction schedules, and deletion triggers for each record category. Where conduit governance presumes non-retention unless legal process compels otherwise, ARCS-LIF requires that retention decisions be explicit, documented, and auditable, accommodating both non-retention architectures and deployments where retention is legally mandated.

ARCS-CUS (Custody Surface) requires operators to identify all custodians that hold interaction records, including platform vendors, tool providers, API endpoints, and downstream services. Where conduit governance benefits from the physical visibility of network infrastructure, AI interaction records may persist across vendor infrastructure the operator cannot inspect. Custody surface mapping produces the visibility that the conduit model assumes but that AI architectures do not provide.

ARCS-OPB (Operator Boundary) defines governance responsibility. Under conduit governance, regulatory obligations apply to the infrastructure operator by operation of law. ARCS-OPB establishes that the deploying operator, not the vendor, determines the governance posture for its AI systems, and that vendor terms of service do not override operator governance requirements.

ARCS-NCR (Non-Creation) applies verification requirements to non-retention claims. Under conduit governance, non-retention is verifiable through physical inspection of network infrastructure. ARCS-NCR requires that non-retention claims for AI interaction records be architecturally documented, independently verifiable, and distinguished from post-creation deletion.

ARCS-VER (Verification) establishes auditability. Where conduit compliance is verifiable by network inspection, AI record governance must be verified through the documentation, inspection, and testing mechanisms defined in the verification framework (see Annex L).

N.5 Scope of analogy

The conduit-custody comparison is a structural parallel, not a claim of legal equivalence. Communications infrastructure governance was developed through legislation, regulation, and judicial interpretation across multiple technology generations. AI interaction record governance is in an earlier stage of development. ARCS provides a governance framework that addresses the same structural concerns (retention defaults, custody mapping, production standards, verification) using control-based specification rather than legislative mandate. The comparison clarifies the governance architecture ARCS implements; it does not assert that AI platforms are or should be legally classified as common carriers.

Annex N is informative. It provides structural context for the ARCS governance framework but does not modify the normative requirements of the standard.

This annex compares the governance scope of ARCS with established AI governance, security, and privacy frameworks to identify where ARCS addresses a governance domain that existing frameworks do not cover. The comparison is factual and identifies structural differences in scope; it does not characterize any framework as deficient. Each framework addresses its intended governance domain. ARCS addresses a different domain: interaction record custody. This annex is informative.

O.1 Frameworks reviewed

The comparison covers FINOS AI Governance Framework v2 (Linux Foundation, October 2025), NIST AI Risk Management Framework 1.0 (January 2023), NIST SP 800-53 Rev. 5, ISO/IEC 42001 (AI Management System), the EU AI Act (entered into force August 2024), and SOC 2 Trust Service Criteria. Each framework was evaluated against five governance questions: whether it addresses interaction record retention as a governance variable, whether it addresses vendor-side custody architecture for interaction records, whether it addresses compelled production of retained AI interaction records, whether it addresses defense-cost exposure from discovery of retained records, and whether it addresses content-telemetry separation as a retention architecture control.

O.2 FINOS AI Governance Framework v2

The FINOS AI Governance Framework is published by the Fintech Open Source Foundation, a Linux Foundation project, and represents the operational governance consensus for AI in financial services. Its membership includes major global financial institutions. The framework identifies 23 risks organized across operational, security, and regulatory categories, with 23 corresponding mitigations.

FINOS coverage is comprehensive for model behavior risks (hallucination, bias, explainability, non-determinism), security risks (prompt injection, data poisoning, supply chain compromise, agent authorization bypass, MCP server governance, credential harvesting), and regulatory compliance (EU AI Act, MiFID II, FINRA guidelines). The agentic security coverage (risks 024 through 029) is among the most thorough publicly available treatments of multi-agent system security.

FINOS does not address interaction record retention as a governance variable. It addresses unauthorized data leakage (records leaving the system without authorization) and data poisoning (records being corrupted) but not the risk created by ordinary, authorized retention of correctly functioning records on vendor infrastructure. FINOS does not address which entity holds custody of interaction records after a session ends, how retention categories are defined across vendor infrastructure, or whether the operator has visibility into backend persistence. FINOS does not address lawful compelled production under subpoena or civil discovery, or the procedural defense costs that arise when retained records become subject to legal process.

FINOS references compliance-mandated logging (AIR-RC-022, citing MiFID II, SEC Rule 17a-4, and FINRA guidelines) but does not address the structural condition in which regulatory mandates create records whose existence generates legal exposure that the organization may not have the insurance coverage or governance infrastructure to manage.

O.3 NIST AI Risk Management Framework

The NIST AI RMF provides a voluntary framework for managing risks in the design, development, deployment, and use of AI systems. It is structured around four functions (Govern, Map, Measure, Manage) and defines characteristics of trustworthy AI including validity, reliability, safety, security, accountability, transparency, explainability, and privacy.

The AI RMF addresses organizational governance, risk identification, and measurement. It does not define interaction record retention as a governance variable, does not address vendor custody architecture for interaction records, and does not address compelled production or discovery exposure. The framework's privacy dimension addresses access controls and individual agency over data but does not extend to retention lifecycle governance for records generated during AI operation.

O.4 NIST SP 800-53 Rev. 5

SP 800-53 defines security and privacy controls for federal information systems. The ARCS-to-SP 800-53 crosswalk is provided in Annex K. SP 800-53 addresses audit and accountability (AU family), media protection (MP family), configuration management (CM family), access control (AC family), and system integrity (SI family). These controls address how records are protected, how access is managed, and how system behavior is monitored.

SP 800-53 does not define retention lifecycle controls for AI interaction records, does not address the custody surface model (records existing across multiple vendors with different retention postures), and does not address compelled production as a governance concern distinct from security. ARCS complements SP 800-53 by governing the layer below what SP 800-53 assumes: whether records exist, where they exist, and what happens when their existence creates legal obligations. See Annex K for the control-level mapping.

O.5 ISO/IEC 42001

ISO 42001 specifies requirements for an AI management system (AIMS) and provides a certification framework for responsible AI. It addresses organizational context, leadership, planning, support, operation, performance evaluation, and improvement within the AI management lifecycle.

ISO 42001 addresses organizational governance of AI systems at the management-system level. It does not define interaction record retention controls, custody surface mapping, non-creation posture governance, or compelled production response procedures. An organization certified under ISO 42001 may have a mature AI management system with no governance framework for the interaction records its AI systems generate.

O.6 EU AI Act

The EU AI Act classifies AI systems by risk level and imposes requirements proportional to the classification. Article 12 requires automatic logging for high-risk AI systems, and Article 19 requires providers to retain those logs for at least six months. These logging mandates create comprehensive, searchable archives of user interactions as a matter of legal compliance.

The EU AI Act addresses logging as a regulatory obligation but does not address the governance of the records that logging creates. It does not define retention lifecycle controls beyond the minimum retention period, does not address vendor custody architecture for the logged records, does not address the custody surface expansion that compliance-mandated logging produces, and does not address the compelled production exposure created by the existence of those records under civil discovery rules in member states.

ARCS provides the governance layer for records whose creation is mandated by the EU AI Act. An operator subject to Article 12 logging requirements can use ARCS-LIF to define lifecycle controls for the logged records, ARCS-CUS to map where the logs are stored, ARCS-TAX to classify the logs by category, and ARCS-PV to define preservation procedures when the logs become subject to legal process.

O.7 SOC 2 Trust Service Criteria

SOC 2 evaluates an organization's information systems against five Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy. SOC 2 audits are widely used in enterprise procurement and vendor assessment.

SOC 2 addresses whether controls are operating effectively over a reporting period. It does not define interaction record retention as a governance variable, does not address custody surface mapping for AI-generated records, and does not address compelled production exposure. An organization that passes a SOC 2 Type II audit may have no governance framework for the AI interaction records its systems generate.

O.8 Summary of scope comparison

All reviewed frameworks address governance concerns within their intended domains: model behavior, system security, organizational management, regulatory compliance, or audit and accountability. None defines interaction record custody as a governance domain. None addresses retention architecture as a variable that affects legal exposure. None addresses the procedural defense costs that arise when retained records become subject to legal compulsion.

Data protection regimes focus on access, disclosure, and transfer, not on whether interaction artifacts should exist. Regulatory frameworks typically assume that records are created; they do not define architectures in which records are not created. This structural assumption means that existing governance frameworks address the management of records whose existence is taken as given, while ARCS addresses the prior governance question of whether, where, and for how long those records exist.

ARCS addresses these concerns through its ten control families. The relationship is complementary in every case: ARCS does not replace any reviewed framework, and conformance to ARCS does not imply conformance to any external framework. The governance domain ARCS occupies, interaction record custody, is structurally distinct from the domains these frameworks govern.

Annex O is informative. It compares governance scope across frameworks but does not modify the normative requirements of the ARCS standard.