Verification and Attestation Protocol

This protocol defines verification procedures for assessing whether an operator's in-scope infrastructure implements ARCS verification controls applicable to non-creation and non-retention claims. It establishes verification categories, evidence artifacts, evaluation criteria, and attestation outputs for a defined verification boundary.

This protocol does not define architectural requirements. Architectural and implementation requirements are addressed in the ARCS standard and related implementation instruments.

1. Purpose and scope

This protocol applies to operator-controlled infrastructure used to process AI interaction sessions within the defined verification boundary. It evaluates whether interaction content classified by the operator as ephemeral is prevented from entering persistent operator-side storage systems within that boundary.

Persistent storage systems within scope may include centralized logging systems, application telemetry systems, error monitoring systems, observability pipelines, database storage layers, backup and snapshot systems, and long-term analytics storage systems.

Unless expressly included by the operator, vendor-operated infrastructure, model-provider infrastructure, and external API service infrastructure remain outside the scope of this protocol.

2. 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, including logs, databases, backups, message queues, analytics stores, and monitoring platforms.

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

Sovereignty receipt A cryptographic attestation artifact generated at session close documenting the retention class applied, the destruction schedule where applicable, and the execution of governance controls. A sovereignty receipt does not store interaction content.

3. Verification categories

Verification is conducted across categories corresponding to known persistence surfaces in typical operator infrastructure.

Centralized logging Verification confirms that ephemeral interaction content is not written to centralized logging systems. Evidence may include logging configuration exports, redaction or filter configuration, and controlled test execution logs.

Monitoring and telemetry Verification confirms that telemetry pipelines do not capture ephemeral interaction content. Evidence may include monitoring-agent configuration, telemetry schema definitions, and sampled telemetry payloads.

Error monitoring Verification confirms that exception-tracking systems do not capture ephemeral interaction content. Evidence may include exception-monitoring configuration, example exception payloads, and redaction settings.

Database storage Verification confirms that ephemeral interaction content is not written to persistent database systems. Evidence may include schema inspection, query logging inspection, and database sampling reports.

Backup and snapshot systems Verification confirms that backups and snapshots do not contain ephemeral interaction content within the verification boundary. Evidence may include backup configuration, snapshot sampling inspection, and retention policies.

Session lifecycle Verification confirms that ephemeral interaction content exists only within session memory during execution, to the extent represented by the documented architecture and tested procedures. Evidence may include session-management configuration, execution-flow documentation, and controlled test runs.

Sovereignty receipts Where operators generate sovereignty receipts, verification confirms the integrity and format of those receipts. Evidence may include receipt-signature verification logs, key-management descriptions, and sample receipts. These receipts document governance events; they do not independently prove destruction outside the defined verification scope.

Legal hold switching Verification confirms that any documented retention-class switching mechanism for preservation or legal hold operates as described. Evidence may include activation procedures, controlled switching tests, audit logs, and reversal procedures where applicable.

4. Evidence artifacts

Artifacts collected during verification may include 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 configuration change logs.

Artifacts should be sufficient to allow an independent reviewer to understand the tested system behavior within the defined scope and to evaluate whether ephemeral interaction content enters any persistent operator-side storage pathway within that scope.

5. Evaluation criteria

Verification results should be assessed against the documented verification scope and procedures.

A verification result is adverse where testing or inspection shows that ephemeral interaction content entered a persistent storage system within the defined scope, or where required verification mechanisms cannot be validated as documented.

Examples of adverse findings include prompt or response content appearing in persistent logs, telemetry payloads, exception reports, or database storage; backups or snapshots containing in-scope interaction payloads; receipt signatures failing verification where receipts are used; and legal-hold switching mechanisms not functioning as documented.

A verification result is satisfactory where inspection and testing show no observed persistence of ephemeral interaction content within the defined scope and time period.

6. Verification frequency

Operators implementing ARCS verification controls should perform verification at initial deployment, upon material changes to logging or telemetry pipelines, upon material changes to AI interaction infrastructure, and periodically at intervals appropriate to system risk, but not less than once every twelve months.

Verification may be performed internally or by an independent assessor. Independent assessment may be appropriate where third-party attestation is required for insurance, procurement, or regulatory purposes.

7. Attestation letter

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

An attestation letter should not characterize the verification as proof of universal non-existence of records. It documents only that the stated procedures were performed and that no in-scope persistent storage of ephemeral interaction content was observed within the defined scope and time period.

8. Limitations

Verification procedures evaluate system behavior within a defined scope and time period. They do not establish the absence of records outside the verification scope or within infrastructure excluded from the verification boundary.

This protocol does not evaluate the retention practices of external service providers unless expressly included in scope. It does not provide legal advice regarding compliance with any specific regulatory framework. Organizations using this protocol should review applicable legal, regulatory, and sector-specific obligations independently before relying on verification outputs for compliance, procurement, or litigation purposes.