Section navigation
Annex L: Verification and Attestation Protocol
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