# ARCS Controls Catalog

**Standard:** Automated Record Custody Standard (ARCS) v1.0
**Published by:** Vega Commons Project, Inc.
**Date:** April 2026

This document contains the 92 operative control statements of ARCS v1.0, organized by control family.

## Control families

- **ARCS-LIF: Record Lifecycle** — Creation, retention, deletion, vendor deletion verifiability, and lifecycle state transitions (13 controls)
- **ARCS-CUS: Custody Surface** — Custody identification, multi-vendor propagation, authorization-gap custody, vendor governance declarations (12 controls)
- **ARCS-TAX: Record Taxonomy** — Record categories, classification, and category-based lifecycle rules (11 controls)
- **ARCS-OPB: Operator Boundary** — Operator scope, vendor inclusion, responsibility boundary (5 controls)
- **ARCS-PUB: Publish Boundary** — Export, third-party sharing, API propagation (6 controls)
- **ARCS-NCR: Non-Creation Posture** — Non-creation declarations, memory-only processing, publish boundary verification (6 controls)
- **ARCS-PV: Preservation and Legal Hold** — Preservation triggers, hold process, multi-vendor preservation communication (7 controls)
- **ARCS-VER: Verification and Audit** — Lifecycle audit, custody audit, vendor compliance, cross-vendor traceability, attestation (7 controls)
- **ARCS-AGT: Agent Runtime** — Agent runtime artifacts, tool call governance, intermediate record controls, security-relevant content, lifecycle boundaries (13 controls)
- **ARCS-DEL: Delegation and Memory** — Governed persistence, delegation chains, autonomous execution records, emergent execution documentation (12 controls)

## ARCS-LIF: Record Lifecycle

*Domain:* Creation, retention, deletion, vendor deletion verifiability, and lifecycle state transitions

- **LIF-01** — The operator SHALL define default retention posture for each record category.
- **LIF-02** — The operator SHALL define preservation posture triggers: litigation, regulatory inquiry, contractual audit, internal investigation.
- **LIF-03** — The operator SHALL define preservation scope: categories, systems, vendors, time period, derived artifacts.
- **LIF-04** — The operator SHALL suspend deletion controls upon preservation trigger: primary storage, backups, safety records, vendor-held copies.
- **LIF-05** — The operator SHALL distinguish user-visible deletion from backend retention; document which copies remain and why.
- **LIF-06** — The operator SHALL define multi-vendor preservation procedure: vendor notice, compliance verification.
- **LIF-07** — The operator SHALL define exit from preservation posture: authority required, eligible categories, auditable release.
- **LIF-08** — The operator SHALL produce lifecycle disclosure sufficient for procurement, audit, and legal evaluation.
- **LIF-09** — The operator SHALL implement non-creation and non-retention controls where applicable; auditable claims are required.
- **LIF-10** — Where agentic workflows generate artifacts requiring different retention classes within a single session, the operator SHALL support per-artifact retention classification distinguishing retained deliverables from ephemeral process artifacts.
- **LIF-11** — Governed persistence: where records must persist across sessions for operational reasons but contain deliberative content, the operator SHALL define maximum retention duration, encryption requirements, backup exclusion policy, and preservation override procedure.
- **LIF-12** — Vendor deletion verifiability: for each vendor surface, the operator SHALL document whether the operator can verify that deletion requests have been carried out, the verification mechanism available, or state that no verification mechanism exists.
- **LIF-13** — Architecturally precluded deletion: where vendor storage architecture does not support deletion (append-only ledgers, immutable logs, blockchain-based systems), the operator SHALL document that deletion is architecturally precluded, identify affected surfaces and record classes, and treat such records as permanently available for production.

## ARCS-CUS: Custody Surface

*Domain:* Custody identification, multi-vendor propagation, authorization-gap custody, vendor governance declarations

- **CUS-01** — The operator SHALL define custody surface: all layers including application, storage, logging, safety, backup, analytics, model providers, infrastructure.
- **CUS-02** — The operator SHALL identify custodians: legal entity, system owner, data controller or processor, vendor.
- **CUS-03** — The operator SHALL map record location: category to storage system, vendor, retention policy, deletion control.
- **CUS-04** — The operator SHALL define multi-vendor propagation: which vendors receive records, what categories, whether vendors retain or derive.
- **CUS-05** — The operator SHALL disclose vendor retention: duration, configurability, suspension capability.
- **CUS-06** — The operator SHALL define custody surface during preservation: vendor notice, deletion suspension, unverifiable locations documented.
- **CUS-07** — The operator SHALL govern derived artifact custody: embeddings, safety classifications, telemetry, training feedback.
- **CUS-08** — The operator SHALL govern backup and archive custody: retention, deletion, preservation behavior.
- **CUS-09** — The operator SHALL produce custody surface disclosure sufficient for procurement, audit, legal, and regulatory purposes.
- **CUS-10** — Where agent delegation chains create records across multiple vendors, the operator SHALL map each vendor in the chain as a separate custody surface entry and assess the combined chain for custody fragmentation.
- **CUS-11** — Authorization-gap custody: where an agent creates records documenting actions not authorized by any party in the custody triad (user, operator, provider), the operator SHALL map custody obligations for those records regardless of authorization status.
- **CUS-12** — Vendor governance declarations: for each vendor surface, the operator SHALL obtain structured, dated, and verifiable documentation of retention duration, preservation capability, deletion support, and record acquisition modalities. Where vendor documentation is unavailable, treat as unknown surface and disclose.

## ARCS-TAX: Record Taxonomy

*Domain:* Record categories, classification, and category-based lifecycle rules

- **TAX-01** — The operator SHALL define all required record categories for the operator's system.
- **TAX-02** — The operator SHALL classify deliberative records: prompts, instructions, reasoning traces, authorization parameters.
- **TAX-03** — The operator SHALL classify exported outputs: records delivered outside the custody surface.
- **TAX-04** — The operator SHALL classify telemetry: operational logs, timing, success/fail indicators, resource usage.
- **TAX-05** — The operator SHALL classify system logs: audit records, access logs, error logs.
- **TAX-06** — The operator SHALL classify safety and review records: moderation, content classification, trust-and-safety artifacts.
- **TAX-07** — The operator SHALL classify derived artifacts: embeddings, vectors, summaries, evaluation outputs, training feedback.
- **TAX-08** — The operator SHALL classify metadata: timestamps, identifiers, routing data.
- **TAX-09** — The operator SHALL define lifecycle rules per category; document retention period and deletion behavior for each.
- **TAX-10** — The operator SHALL produce taxonomy documentation sufficient for audit and procurement.
- **TAX-11** — Agent runtime artifacts SHALL be classified into at minimum: planning traces (deliberative), tool call content (deliberative or operational per AGT-05), tool call metadata (operational), intermediate results (deliberative), agent memory (governed-persistent), authentication context (ephemeral/security), error recovery content (deliberative), error metadata (operational), security-context deliverables (persistent/security), and security-context intermediates (deliberative).

## ARCS-OPB: Operator Boundary

*Domain:* Operator scope, vendor inclusion, responsibility boundary

- **OPB-01** — The operator SHALL define operator boundary: all systems creating, transmitting, storing, or logging interaction records.
- **OPB-02** — The operator SHALL list in-scope systems: applications, APIs, model providers, storage, logging, analytics, safety, backup.
- **OPB-03** — Vendor inclusion rule: the operator SHALL treat a vendor as inside the boundary if the operator sends records to, causes records at, or relies on the vendor for storage or deletion.
- **OPB-04** — Out-of-scope systems: the operator SHALL document why, what records exist, deletion control, preservation capability.
- **OPB-05** — Boundary change procedure: the operator SHALL update custody surface and retention posture when architecture changes.

## ARCS-PUB: Publish Boundary

*Domain:* Export, third-party sharing, API propagation

- **PUB-01** — The operator SHALL define publish boundary: the point at which a record leaves the governed environment.
- **PUB-02** — The operator SHALL classify exported outputs: distinguish deliberative records from exported outputs; retention rules may differ.
- **PUB-03** — Post-publish retention: the operator SHALL document retention rules for exported copies.
- **PUB-04** — Preservation at publish boundary: the operator SHALL define preservation behavior for exported records.
- **PUB-05** — API propagation: the operator SHALL govern records transmitted through APIs to external systems.
- **PUB-06** — Publish boundary disclosure: the operator SHALL document publish events and recipients for audit purposes.

## ARCS-NCR: Non-Creation Posture

*Domain:* Non-creation declarations, memory-only processing, publish boundary verification

- **NCR-01** — Non-creation declaration: the operator SHALL produce an auditable claim that a specific record category is not created.
- **NCR-02** — Memory-only processing: the operator SHALL document categories processed in volatile memory only, never written to storage.
- **NCR-03** — Non-retention declaration: the operator SHALL produce an auditable claim that records are not retained beyond session.
- **NCR-04** — Preservation posture interaction: the operator SHALL define how preservation obligations interact with non-creation or non-retention claims.
- **NCR-05** — The operator SHALL produce non-creation documentation sufficient for procurement, audit, and legal evaluation.
- **NCR-06** — Publish boundary lifecycle verification: where non-creation architecture is defined by a publish boundary, the operator SHALL document that boundary as a lifecycle boundary and verify that artifacts below the boundary do not cross into governed record status during ordinary operation, error conditions, or abnormal termination.

## ARCS-PV: Preservation and Legal Hold

*Domain:* Preservation triggers, hold process, multi-vendor preservation communication

- **PV-01** — Preservation trigger: the operator SHALL define conditions requiring preservation posture (litigation, regulatory inquiry, audit, internal investigation).
- **PV-02** — The operator SHALL define the legal hold process: authority, scope, notification, and documentation.
- **PV-03** — Preservation SHALL override deletion: routine deletion SHALL be suspended for affected categories during preservation posture.
- **PV-04** — Preservation responsibility: the operator SHALL identify who bears obligation across operator and vendor boundaries.
- **PV-05** — Multi-vendor preservation: the operator SHALL document vendor notice, compliance verification, and unverifiable locations.
- **PV-06** — Exit from preservation posture: the operator SHALL document authority required, categories eligible, and auditable release record.
- **PV-07** — Multi-vendor preservation communication: the operator SHALL document how preservation obligations are communicated to each vendor surface, including communication mechanism, expected vendor response, confirmation timeframe, and procedure when vendor cannot comply.

## ARCS-VER: Verification and Audit

*Domain:* Lifecycle audit, custody audit, vendor compliance, cross-vendor traceability, attestation

- **VER-01** — Documentation currency: the operator SHALL maintain current documentation of lifecycle and custody controls.
- **VER-02** — Internal verification: the operator SHALL perform periodic confirmation that controls operate as documented.
- **VER-03** — Vendor verification: the operator SHALL obtain vendor confirmation of retention, deletion, and preservation behavior.
- **VER-04** — Preservation verification: the operator SHALL confirm preservation posture is in effect and deletion is suspended.
- **VER-05** — Audit availability: the operator SHALL make documentation available for audit, regulatory, or legal review.
- **VER-06** — Attestation: the operator SHALL be able to attest to compliance with ARCS controls; attestation does not replace documentation.
- **VER-07** — Cross-vendor traceability: where conformance depends on behavior across multiple vendor surfaces, the audit evidence package SHALL permit an assessor to identify records across those surfaces. Where cross-surface identification is incomplete, disclose the limitation.

## ARCS-AGT: Agent Runtime

*Domain:* Agent runtime artifacts, tool call governance, intermediate record controls, security-relevant content, lifecycle boundaries

- **AGT-01** — The operator SHALL identify all agent runtime artifact classes present in the deployment and classify each according to the agent runtime artifact taxonomy defined in Section 14.
- **AGT-02** — The operator SHALL apply content-telemetry separation to all agent runtime artifacts containing both deliberative content and operational telemetry. Co-mingled artifacts must be separated at the custody boundary or treated as deliberative in full.
- **AGT-03** — The operator SHALL define session scope for agent runtime deployments. For multi-step agentic workflows, the session scope must encompass the entire workflow, not individual API calls within it.
- **AGT-04** — The operator SHALL classify planning traces as ephemeral by default. Metadata may be retained only if it excludes abandoned approaches, alternative reasoning, and cognitive path content.
- **AGT-05** — The operator SHALL classify and govern tool call metadata and tool call content separately. Tool call content governed as deliberative unless operator documents that content contains no material derived from operator prompts.
- **AGT-06** — The operator SHALL classify intermediate results as ephemeral by default. Document retained deliverable designations; reflect designated deliverables in session receipt.
- **AGT-07** — The operator SHALL classify error recovery artifacts as deliberative and govern as ephemeral. Retain error metadata as operational telemetry only. Configure observability pipelines to exclude deliberative content from error context capture.
- **AGT-08** — The operator SHALL decompose security-sensitive tool outputs into final deliverables (persistent), deliberative intermediates (ephemeral), and operational telemetry (retainable). Apply deletion controls independently to each storage location created by the tool.
- **AGT-09** — The operator SHALL disclose agent runtime artifact classes, retention class applied to each, and vendor retention for all tool integrations handling deliberative content.
- **AGT-10** — The operator SHALL confirm preservation posture under ARCS-PV covers all agent runtime artifact storage locations, including tool-provider logs, workflow state containers, and external storage accessed during execution.
- **AGT-11** — Session receipt SHALL identify session scope, artifact classes generated, retention class per class, whether deliberative content was transmitted to external tool providers, and retained deliverable designations. Receipt shall not include deliberative content.
- **AGT-12** — Undifferentiated security-relevant content: where tool calls or agent runtime records may contain security-relevant content that cannot be classified at creation time, the operator SHALL document which tool-call classes may contain such content, what detection mechanism exists, the default retention posture, and how such records would be handled in response to a discovery request.
- **AGT-13** — Lifecycle boundary identification: the operator SHALL identify lifecycle boundaries applicable to each runtime component and document which artifact classes cross which boundaries during normal operation, error conditions, and abnormal termination. Assess at minimum: persistence to durable storage, transmission outside local execution environment, retention beyond session termination, capture by logging or telemetry systems, and inclusion in training or evaluation datasets.

## ARCS-DEL: Delegation and Memory

*Domain:* Governed persistence, delegation chains, autonomous execution records, emergent execution documentation

- **DEL-01** — The operator SHALL identify whether deployment involves persistent memory, delegated authority, or autonomous execution. Document which conditions apply and confirm non-applicability of inapplicable conditions in the conformance statement.
- **DEL-02** — The operator SHALL classify agent memory stores requiring cross-session persistence as governed persistence. Document maximum retention period, deletion mechanism, storage location, and backup or synchronization exposure.
- **DEL-03** — The operator SHALL subject governed-persistence memory stores to an automatic purge schedule. Log purge operations with sufficient metadata to confirm purge occurred.
- **DEL-04** — The operator SHALL suspend automatic purge of governed-persistence memory stores when a preservation obligation arises under ARCS-PV. Confirm preservation posture reaches the memory store storage location.
- **DEL-05** — The operator SHALL classify delegation artifacts as deliberative records. Document classification applied to delegation artifacts and rationale for any non-ephemeral classification.
- **DEL-06** — The operator SHALL document the scope of authority delegated to each agent or agent class: authorized actions, accessible external systems, runtime configurability, and disclosure to downstream systems.
- **DEL-07** — For autonomous execution sequences, the operator SHALL define governance posture: intermediate artifact classification, session scope determination, and record generated at sequence completion.
- **DEL-08** — The operator SHALL extend ARCS-CUS custody surface documentation to cover governed-persistence memory stores, delegation artifacts, and autonomous execution records across all storage locations.
- **DEL-09** — The operator SHALL disclose whether any vendor retains agent memory content, delegation artifacts, or autonomous execution records. Document vendor retention with same specificity as other deliberative record retention.
- **DEL-10** — The operator SHALL confirm at preservation trigger that posture covers governed-persistence memory stores, delegation artifacts, and autonomous execution records. Address vendor-held agent memory and execution records in preservation notice.
- **DEL-11** — Attestation record for ARCS-DEL deployments SHALL identify: persistent memory use; delegated authority use; autonomous execution use; retention class per memory store; purge schedule; and whether any vendor holds agent memory content subject to preservation obligations.
- **DEL-12** — Emergent autonomous execution: where an agent creates records documenting actions outside the behavioral envelope defined by the operator, the operator SHALL document whether the implementation detects such actions, whether records are distinguishable from anticipated-action records, the operator notification mechanism and latency, and whether visibility of the action at occurrence time can be determined after the fact.

Vega Commons Project, Inc. | ARCS Controls Catalog | v1.0 | April 2026

© 2024-2026 Vega Commons Project, Inc. All rights reserved.