Evidence Envelope Specification v0.1

1. Status and Licence

This specification is published under the Apache 2.0 licence. It may be reproduced, implemented, and extended without restriction. The Evidence Envelope Specification governs the format, schema, and verification algorithm only. VERIDIC's infrastructure — the append-only chain, key management, jurisdictional SLAs, institutional access controls — remains proprietary.

This is version 0.1. The specification is stable enough for implementation and reference but may be amended in future versions. Governance of this specification will transition to a neutral Technical Steering Committee. Until that transition, VERIDIC Inc. maintains editorial control.

2. Scope

This specification defines three components:

What is not part of this specification: infrastructure (storage, access control, key management, jurisdictional SLAs), APIs, analytics, reliability computation methods, query layer, framework adaptors, storage backends, jurisdiction-specific regulatory mappings. These are proprietary to the infrastructure provider. Content evaluation, risk scoring, or analytical interpretation of recorded actions is also outside the scope of this specification.

3. Terminology

4. AgentInteractionRecord Schema

The AIR captures eight categories of evidence about a Material Action: what the agent was given (input), what it produced (outcome), what resources it used (tool calls), what it reasoned (reasoning hash), who it is (identity), what authorised it (auth context, delegation chain), when it acted (timestamps), and where it fits in a causal chain (hash chain, sequence).

4.1 Field Definitions

4.2 Supporting Types

// AuthContext — authorisation state at execution time
{
  "token_type":    string,       // e.g. "Bearer"
  "scopes":        [string],     // OAuth scopes granted
  "audience":      string|null,  // intended audience
  "expires_at_ms": uint|null     // token expiry, epoch ms
}

// ToolCallRecord — a single tool or API invocation
{
  "tool_id":       string,   // tool identifier
  "tool_type":     string,   // e.g. "api_call", "mcp_tool"
  "input_hash":   bytes,    // SHA-256 of tool input
  "output_hash":  bytes,    // SHA-256 of tool output
  "is_write":     bool,     // true if tool mutates state
  "timestamp_ms": uint      // when this call completed
}

// ExternalRef — cross-reference to external system
{
  "ref_type":   string,       // e.g. "payment_ref", "trade_id"
  "ref_value":  string,       // the reference value
  "ref_system": string|null  // originating system
}

// RedactionReceipt — see §7
{
  "field_path":    string,  // dot-path to redacted field
  "original_hash": bytes,   // SHA-256 of original value
  "policy_id":     string,  // which policy triggered redaction
  "timestamp_ms":  uint    // when redaction was applied
}

// IntegrityEnvelope — see §5
{
  "content_hash":    bytes,  // SHA-256 of canonical payload
  "prev_chain_hash": bytes,  // chain_hash of preceding record
  "chain_hash":      bytes,  // SHA-256(content_hash ∥ prev_chain_hash ∥ action_timestamp_ms ∥ agent_id)
  "sequence_number": uint,   // monotonically increasing, 0-based
  "signature":       bytes   // ECDSA-P256 over chain_hash
}

4.3 Action Type Vocabulary

Each AIR carries an action_type classifying the Material Action. The initial vocabulary defined by this specification:

Implementations may define additional values using a reverse-DNS namespace (e.g. com.example.custom-action). Values without a namespace prefix are reserved for this specification.

5. Integrity Envelope

Every AIR carries an integrity envelope computed by the signing component before submission to the Evidence Custodian. The cryptographic primitives are fixed: SHA-256 for hashing, ECDSA with the P-256 curve for signatures.

5.1 Hash Chain Construction

For the first record in a chain (sequence_number = 0): prev_chain_hash is 32 zero bytes. For all subsequent records: prev_chain_hash is the chain_hash of the immediately preceding record.

// For every record:
content_hash   = SHA-256(canonical_payload)
chain_hash     = SHA-256(content_hash ∥ prev_chain_hash ∥ action_timestamp_ms ∥ agent_id)
signature      = ECDSA-P256.sign(chain_hash, private_key)

The four-input construction binds identity and temporal ordering into the chain at the cryptographic level: a receipt proves who, when, and what without requiring payload access. Both agent_id and action_timestamp_ms are mandatory fields supplied by the upstream agent platform at capture time.

The concatenation inputs are encoded as follows: content_hash and prev_chain_hash are raw 32-byte SHA-256 digest bytes. action_timestamp_ms is an unsigned 64-bit integer in big-endian (network) byte order (8 bytes). agent_id is a length-prefixed UTF-8 string: a 4-byte big-endian unsigned 32-bit integer containing the byte length of the UTF-8 encoding, followed by the UTF-8 encoded bytes (no null terminator). The total input to SHA-256 is exactly 76 + len(agent_id) bytes. This encoding is deterministic: two conforming implementations given the same field values MUST produce the same chain_hash.

Canonical form follows the JSON Canonicalization Scheme (RFC 8785). All fields except the integrity envelope are included in the canonical payload.

5.1.1 Concurrency and Serialisation

The hash chain construction requires sequential production of records within a single Evidence Chain. Because each record's chain_hash depends on the preceding record's chain_hash via prev_chain_hash, a conforming implementation cannot produce record N+1 until record N has been finalised and signed. This dependency provides a total ordering guarantee that is cryptographically enforced rather than administratively asserted.

Evidence Chains are scoped per agent_id. Agents with distinct agent_id values operate independent chains with no cross-chain ordering dependency. Concurrent agent deployments do not contend with each other.

Within a single agent_id, implementations must serialise record production. Two conforming patterns exist: (a) the Issuer's capture pipeline maintains a per-agent_id serialisation point (queue or mutex) and produces fully signed, sequenced records before submission to the Evidence Custodian; or (b) the Evidence Custodian assigns sequence numbers at admission time and returns chain_hash to the Issuer for use in the next record. Pattern (a) requires Issuer-side state but minimises round trips. Pattern (b) centralises ordering but introduces a synchronous dependency on the Evidence Custodian for each record.

If an agent produces multiple Material Actions concurrently, the capture pipeline queues them and serialises into the chain in arrival order. Records may share the same action_timestamp_ms; the sequence_number provides the authoritative total ordering.

5.2 Identity Binding Levels

6. Verification Algorithm

The following four-step algorithm verifies any AIR. It requires only the record, the preceding record's chain_hash (or an Evidence Receipt), and the Issuer's public key.

If all four steps pass: the record is VERIFIED — intact, untampered, correctly positioned in the chain, and signed by the claimed Issuer.

6.1 Pseudocode

function verify_chain(records, public_key):
    prev_chain_hash = 0x00 * 32  // 32 zero bytes for first record
    expected_seq = 0

    for record in records:
        // Step 1: payload integrity
        payload = canonicalise(record, exclude=["integrity"])
        content_hash = sha256(payload)
        assert content_hash == record.integrity.content_hash

        // Step 2: chain integrity
        chain_hash = sha256(
            content_hash + prev_chain_hash +
            record.action_timestamp_ms + record.agent_id
        )
        assert chain_hash == record.integrity.chain_hash

        // Step 3: signature validity
        assert ecdsa_p256_verify(
            chain_hash,
            record.integrity.signature,
            public_key
        )

        // Step 4: sequence completeness
        assert record.integrity.sequence_number == expected_seq

        prev_chain_hash = chain_hash
        expected_seq += 1

    return VERIFIED

7. Redaction Semantics

Evidence records frequently contain personally identifiable information (PII) that must not persist in the custody layer. The redaction mechanism preserves evidence that the data existed at execution time while removing the data itself.

When a field is redacted, the signing component: computes the SHA-256 hash of the original field value; replaces the field value with a sentinel (e.g. "[REDACTED]"); and appends a RedactionReceipt to the redaction_receipts array. The canonical payload — and therefore the content_hash — is computed after redaction. This means the integrity envelope covers the redacted form. The original_hash in the Redaction Receipt allows a party with legitimate access to the original data to prove that the redacted field contained a specific value, without the custody layer ever holding the raw data.

The redaction order in the write pipeline is: Capture → Normalise → Redact → Sign → Write. Redaction occurs before signing. The signed record never contains raw PII.

8. Capture Interface Contract

A conforming storage backend — whether operated by VERIDIC or by any other party implementing this specification — must accept and guarantee the following:

8.1 Writer Interface (IDL)

interface EvidenceWriter {

  // Submit a signed AIR for admission to the Evidence Chain.
  // Returns an Evidence Receipt on success.
  // Rejects if schema validation, hash chain, or signature fails.
  async submit(record: SignedAIR): EvidenceReceipt

  // Retrieve a record by its record_id.
  // Returns null if the record does not exist or
  // the caller lacks access.
  async get(record_id: string): SignedAIR | null

  // Retrieve the Evidence Receipt for a given record.
  async get_receipt(record_id: string): EvidenceReceipt | null

  // Retrieve a range of records by sequence number.
  async get_range(
    agent_id: string,
    from_seq: uint,
    to_seq: uint
  ): [SignedAIR]
}

8.2 Guarantees

9. Conformance

A record is EES-conformant if and only if all three of the following conditions hold:

A conformant implementation is any system that produces records satisfying all three conditions above. Conformance is assessed at the record level, not the system level — a system is conformant if every record it emits is conformant.

10. Versioning and Governance

The schema_version field in every AIR is the mechanism for forward compatibility. Version "air-1.0" is defined by this specification. Future versions will be designated "air-1.1", "air-2.0", etc., following semantic versioning principles: minor versions add optional fields; major versions may change required fields or the integrity construction.

Governance of this specification will transition to a neutral Technical Steering Committee. Until that transition is complete, VERIDIC Inc. maintains editorial control.

11. Relationship to the SCITT Profile

This specification and the AI Agent Execution Profile of SCITT (draft-emirdag-scitt-ai-agent-execution-00) are complementary. The EES defines the canonical AIR schema, the four-step verification algorithm, and the writer interface contract. The SCITT profile defines the binding: how EES-conforming records are encoded as COSE_Sign1 structures, submitted to a SCITT Transparency Service via SCRAPI, validated against a Registration Policy, and receipted using SCITT Evidence Receipts. The SCITT profile also defines the hash chain as a verifiable data structure and specifies how Evidence Receipts may be embedded in the AIR as Transparent Statements (COSE label 394).

The AgentInteractionRecord schema reproduced in the SCITT profile (§5.2 of that document) is a conformant subset of the EES schema defined here. The canonical definition, including the full field set and extensibility model, is maintained in this specification. The SCITT profile stands alone for implementation purposes; the EES provides additional guidance for implementers building capture interfaces and verification tooling.

The underlying cryptographic parameters are identical: SHA-256 for hashing, ECDSA with P-256 for signatures. The difference is wire format: the EES defines a JSON-native representation; the SCITT profile encodes the same payload as CBOR within a COSE_Sign1 structure. Key material is interchangeable.

12. References