# ARCS Minimum Profile

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

| Family Code | Family Name | Profile Status |
|---|---|---|
| ARCS-LIF | Record Lifecycle | Required |
| ARCS-CUS | Custody Surface | Required |
| ARCS-TAX | Record Taxonomy | Required |
| ARCS-OPB | Operator Boundary | Required |
| ARCS-PUB | Publish Boundary | Required |
| ARCS-PV | Preservation and Legal Hold | Required |
| ARCS-VER | Verification and Audit | Required |
| ARCS-NCR | Non-Creation Posture | Required if claimed |

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.

*Vega Commons Project, Inc. | ARCS Minimum Profile | v1.0 | March 2026*
