Verifiable AI Provenance (VAP) Framework and Legal AI Profile (LAP)

1.1. Scope and Upstream Baseline

LAP addresses legal consultation, document generation, and fact checking. The upstream baseline is VSO-VAP-SPEC-001, VAP v1.2.0 Draft 3, at repository commit 81fa81e01ef9418c3fb7a02ddfc7fd72d993b6b1 [VAP12]. This immutable reference includes the October 2026 integrity clarifications. Later changes require explicit review and a new LAP revision.¶

The upstream specification is maintained by VeritasChain Standards Organization and published under CC BY 4.0. LAP is an independently proposed domain profile; this document does not assert upstream registration, endorsement, or certification. References to other profiles are descriptive only.¶

1.2. Authority and Assurance Limits

The requirements here govern the LAP wire format defined here. They do not override the VAP specification. Differences are documented in Section 5.2. A claim of VAP conformance requires a separate assessment against the pinned upstream requirements; LAP conformance alone is insufficient.¶

Signed records establish integrity and attributable statements under stated trust assumptions. They do not establish factual truth, legal correctness, safety, fairness, regulatory compliance, admissibility, or adequacy of professional review. Missing capture before signing and anchoring remains a distinct risk.¶

2.1. Terminology

VAP

Verifiable AI Provenance Framework, maintained upstream as described in VAP12.¶

Profile

A domain-specific instantiation of VAP (e.g., VCP for¶

finance, CAP for content, LAP for legal).¶

LAP

Legal AI Profile - the judicial AI domain profile defined in¶

this document.¶

Provenance

Cryptographically verifiable record of data origin,¶

derivation, and history.¶

Completeness Invariant

A scoped consistency check over captured attempts and outcomes. Passing it is not proof that all real-world activity was captured.¶

Evidence Pack

A self-contained, signed package of provenance events¶

intended for third-party examination within a declared scope.¶

External Anchor

An external service receipt binding a signed batch statement commitment to an independently verifiable service record.¶

Human Override

An event recording a human professional's review,¶

approval, modification, or rejection of an AI-generated output.¶

Override Coverage

The ratio of AI outputs reviewed by a human¶

professional to total AI outputs, expressed as a percentage.¶

Causal Link

A reference from an outcome event to its originating¶

attempt event, establishing referential integrity within a pipeline.¶

Content Retention Tier

One of three levels of content preservation¶

(Full Content, Recoverable Hash, Hash-Only) defining the availability of original event content at a given point in the retention lifecycle.¶

Legal Hold

A directive freezing the current retention tier for¶

events within scope, preventing content deletion or tier transition during litigation, investigation, or regulatory inquiry.¶

Override Enforcement Level

One of four graduated control levels¶

(Metric Only, Warn, Gate, Strict) governing how the system responds when AI outputs lack corresponding HUMAN_OVERRIDE events.¶

Hash Input

The JCS bytes of an event after removing only security.event_hash and security.signature. Algorithm identifiers and signer_id remain covered.¶

Secure Multi-Agent Collaboration

An architecture in which¶

multiple AI agents coordinate through authenticated and integrity-protected communication channels, enabling distributed reasoning, delegation, and collective decision- making under verifiable security guarantees.¶

AI Agent Collaboration Provenance

A provenance record capturing¶

the interactions, delegations, and outputs produced during secure multi-agent collaboration sessions, enabling post-hoc verification of each agent's contribution to a collective outcome.¶

Provenance Profile

A domain-specific instantiation of the VAP¶

Framework that defines event types, data model extensions, conformance mappings, and regulatory alignment for a particular high-risk AI domain. (See also: Profile.)¶

Domain-Specific Provenance Constraints

Requirements imposed by¶

a provenance profile that restrict, extend, or refine the VAP common event structure and completeness invariant for a particular regulatory or professional context.¶

3.1. Layer Model

The upstream framework has four common assurance layers: Integrity, Provenance, Traceability, and Accountability; the domain profile supplies domain-specific rules. LAP applies these layers through event hashing and signatures, actor/input/action/outcome records, trace and causal identifiers, and identified operators and approvers.¶

Shared mechanisms include Merkle trees, external anchors, scope commitments, bounded recovery, erasure records, and evidence packages. Their mandatory LAP requirements are defined below.¶

3.2. Profile Status and Levels

LAP is proposed, not listed as a registered profile in the pinned upstream registry. The labels Bronze, Silver, and Gold in this document belong only to LAP. Upstream Core, Standard, and Full are separate requirement sets. No one-to-one equivalence is asserted.¶

4.1. Algorithm Requirements

All VAP-conformant implementations MUST support the primary algorithms listed below. Implementations SHOULD support at least one alternative algorithm in each category for migration purposes. Post- quantum algorithms are listed for future migration readiness and are currently OPTIONAL.¶

 +============+================+===================+==============+
 | Category   | Primary (MTI)  | Alternative       | Post-Quantum |
 |            |                |                   | (Future MTI) |
 +============+================+===================+==============+
 | Hash       | SHA-256        | SHA-384, SHA-512  | SHA3-256     |
 +------------+----------------+-------------------+--------------+
 | Signature  | Ed25519        | ECDSA P-256       | ML-DSA-65    |
 |            | ([RFC8032])    | ([RFC6979])       | ([FIPS204])  |
 +------------+----------------+-------------------+--------------+
 | Encryption | AES-256-GCM    | ChaCha20-Poly1305 | N/A (see KEM |
 |            |                |                   | row)         |
 +------------+----------------+-------------------+--------------+
 | KEM        | N/A (classical | N/A               | ML-KEM-1024  |
 |            | key exchange)  |                   | ([FIPS203])  |
 +------------+----------------+-------------------+--------------+

Note: The Post-Quantum signature algorithm ML-DSA-65 (formerly known as CRYSTALS-Dilithium, renamed upon FIPS 204 [FIPS204] standardization in August 2024) provides security equivalent to AES-192. This parameter set was selected as a balance between signature size (3,309 bytes) and security margin for legal audit trails requiring multi-decade retention. ML-DSA-44 (AES-128 equivalent) was considered insufficient for the intended retention periods; ML-DSA-87 (AES-256 equivalent) imposes significantly larger signatures (4,627 bytes) with marginal practical benefit for this use case.¶

Note: ML-KEM-1024 (formerly known as CRYSTALS-Kyber, renamed upon FIPS 203 [FIPS203] standardization in August 2024) is a key encapsulation mechanism (KEM), not an encryption algorithm. It is listed separately from symmetric encryption because KEM and symmetric encryption serve different roles: KEM establishes shared secrets for key agreement, while AES-256-GCM provides authenticated encryption of content.¶

Implementations MUST include algorithm identifiers in all cryptographic fields. The following table defines the canonical algorithm identifiers used in field values and wire-format prefixes:¶

+===========+========================+==================+===========+
| Algorithm | Field Value (hash_algo | Wire Prefix      | Reference |
|           | / sign_algo)           | (in encoded      |           |
|           |                        | strings)         |           |
+===========+========================+==================+===========+
| SHA-256   | "sha-256"              | "sha-256:"       | NIST FIPS |
|           |                        |                  | 180-4     |
+-----------+------------------------+------------------+-----------+
| SHA-384   | "sha-384"              | "sha-384:"       | NIST FIPS |
|           |                        |                  | 180-4     |
+-----------+------------------------+------------------+-----------+
| SHA-512   | "sha-512"              | "sha-512:"       | NIST FIPS |
|           |                        |                  | 180-4     |
+-----------+------------------------+------------------+-----------+
| SHA3-256  | "sha3-256"             | "sha3-256:"      | NIST FIPS |
|           |                        |                  | 202       |
+-----------+------------------------+------------------+-----------+
| Ed25519   | "ed25519"              | "ed25519:"       | [RFC8032] |
+-----------+------------------------+------------------+-----------+
| ECDSA     | "ecdsa-p256"           | "ecdsa-p256:"    | [RFC6979] |
| P-256     |                        |                  |           |
+-----------+------------------------+------------------+-----------+
| ML-DSA-65 | "ml-dsa-65"            | "ml-dsa-65:"     | [FIPS204] |
+-----------+------------------------+------------------+-----------+

All algorithm identifiers MUST be lowercase ASCII strings with hyphens as separators. The field value and wire prefix use the same string (the wire prefix appends a colon as delimiter). Implementations MUST reject non-canonical algorithm identifiers and MUST produce lowercase output. These identifiers enable crypto agility and algorithm migration as specified in Section 4.4.¶

4.2. Hash Chain Specification

Events MUST be linked in a hash chain where each event's hash includes the hash of the preceding event.¶

The Hash Input is computed by removing the following fields from the event before canonicalization:¶

• security.event_hash¶

• security.signature¶

The remaining fields (including security.hash_algo, security.sign_algo, and security.signer_id) are retained in the hash input. This explicit exclusion list prevents circular references (event_hash cannot be included in its own computation) and ensures that implementations agree on the hash input.¶

The computation proceeds as follows:

HashInput[n] = Event[n] with {security.event_hash, security.signature} removed¶

EventHash[n] = HashAlgo(JCS-Canonicalize(HashInput[n]))¶

where:

Event[n].header.prev_hash = EventHash[n-1] Event[0].header.prev_hash = null (genesis event) HashAlgo is the algorithm specified in security.hash_algo JCS-Canonicalize follows RFC 8785¶

Canonicalization MUST follow [RFC8785] (JSON Canonicalization Scheme).¶

Chain integrity verification MUST confirm:¶

1. Each event's EventHash matches the recomputed hash over the Hash Input.¶

2. Each event's prev_hash matches the preceding event's EventHash.¶

3. The genesis event has a null prev_hash.¶

4. The hash_algo specified in each event is a supported algorithm.¶

4.3. Digital Signature Requirements

Every event MUST be signed. The signature MUST be computed over the EventHash bytes (not over the raw event):¶

  Signature = SignAlgo.Sign(PrivateKey, EventHash_bytes)

The signature MUST be encoded as follows:

  security.signature = sign_algo_id ":" Base64url(Signature_bytes)

where sign_algo_id is the canonical algorithm identifier from Figure 2 matching the security.sign_algo field (e.g., "ed25519", "ecdsa-p256"), and Base64url encoding follows Section 5 of [RFC4648] (URL-safe alphabet, no padding).¶

The primary mandatory-to-implement (MTI) signature algorithm is Ed25519 [RFC8032]. Implementations MUST support Ed25519 and SHOULD support at least one additional algorithm from Figure 1 for migration purposes.¶

4.4. Algorithm Migration

Algorithm migration follows the principles of [RFC7696]. This revision requires SHA-256 and Ed25519 interoperability for event and batch commitments. Other algorithm support in the tables is preparatory: a deployment MUST NOT claim interoperable use without a versioned specification of key, signature, and transcript encoding. Unsupported algorithms MUST be reported as unverifiable.¶

A key change MUST be logged and authorized under the existing trust policy. Historical events MUST NOT be rewritten or re-signed in place. Supplemental signatures, if used, MUST be detached attestations over the original event_hash with explicit algorithm and signer identifiers; they MUST NOT be inserted into the old event. Re-anchoring preserves the original proofs and does not retrospectively repair a compromised signature.¶

5.1. Numeric Value Encoding

All numeric values in LAP JSON events, policies, anchor records, proofs, and manifests MUST be strings. Non-negative integer fields, including sequence, counts, indexes, and limits, MUST match 0|[1-9][0-9]*. Signed integers, if needed in an extension, MUST use an optional leading minus and MUST NOT use negative zero. Decimal fields MUST use a decimal point with digits on both sides, no exponent, no leading plus, no unnecessary leading zeros, and no trailing fractional zeros; integral values use the integer form. Booleans and null retain their JSON types.¶

These rules apply before hashing. JCS [RFC8785] MUST NOT convert types, normalize Unicode, or rewrite numeric strings. A receiver MUST reject a wrong type rather than silently repair signed data. The rules apply to the LAP JSON wrapper, not binary data encoded inside a receipt or quoted third-party documents.¶

5.2. Compatibility and Policy Identification

This revision is not byte-compatible with draft-04. It replaces the former vap_version value 1.4, which was not the upstream VAP v1.2 version, and advances the LAP profile version from 0.5.0 to 0.6.0. Old records MUST retain their original bytes and schema identity. Migration MUST start a new chain with a signed migration record referencing the last old event hash and available old anchor. Old proofs MUST NOT be relabeled as draft-05 proofs.¶

The LAP fields header.timestamp and header.prev_hash correspond conceptually to upstream header.timestamp_iso and security.prev_hash. LAP adds explicit sequence and schema_id. An adapter MUST preserve the original signed bytes and disclose mappings; renaming fields produces a different signed object. No generic upstream JSON validator compatibility is claimed.¶

Every event MUST bind a policy_id and policy_hash. policy_id MUST use reverse-domain notation followed by a colon and a local identifier. policy_hash is SHA-256 of the UTF-8 JCS bytes of the immutable policy document. The policy document MUST contain: issuer, policy_id, effective_from, expires_at (timestamp or null), lap_level (Bronze, Silver, or Gold), the pinned vap_baseline commit, vap_conformance (UNASSESSED, VAP-CORE, VAP-STANDARD, or VAP-FULL), registration_policy (issuer and policy_uri), verification_depth, anchor_interval_seconds, fallback_endpoint, max_failover_seconds, and recovery_bounds. verification_depth MUST declare event_signature, hash_chain, merkle_tree, and external_anchor as true. A non-UNASSESSED VAP claim MUST identify a separate assessment and evidence URI. Neither this field nor its signature makes that claim true.¶

Policy documents MUST be included in evidence packages and retained with anchors. Policy changes require a new hash and a POLICY_CHANGE event binding old and new hashes. A policy change MUST close the existing batch. Limits MUST NOT be relaxed retroactively.¶

schema_id values in this document are opaque identifiers defined here, not registered URN namespaces. Optional extensions MUST declare any validation-critical member names in a critical_extensions array of strings at the event top level. Unknown listed members prevent a positive semantic validation result. The array itself is included in Hash Input.¶

6.1. Bronze

Bronze MUST implement the event structure, SHA-256 hashing, Ed25519 support, an unbroken hash chain, per-event signatures, policy binding, signed Merkle batch statements, and verified external anchoring at intervals no longer than 86400 seconds. It MUST preserve events for at least six months and anchors, policies, proofs, and public verification material for at least one year and for as long as any dependent retained event requires verification. Legal hold, recovery, erasure, and anchoring-failure records are mandatory when applicable. Bronze MUST export the records and proofs needed to verify a declared batch, even if it has no online audit API.¶

6.2. Silver

Silver additionally MUST implement the three-pipeline consistency checks, Evidence Pack generation, privacy protection, override coverage reporting, Level 1 review warnings, and the audit API. LAP Silver events MUST be retained for at least three years; anchors and verification material for at least five years and for as long as dependent records remain retained. External anchoring remains mandatory at most every 86400 seconds.¶

6.3. Gold

Gold additionally MUST anchor at intervals no longer than 3600 seconds, use a transparency log as one anchor service, use a FIPS 140-3 Level 2 or higher validated HSM for signing keys, provide real-time audit access, preserve evidence during incidents, maintain at least two geographic regions, support crypto-shredding subject to legal hold, and obtain an annual third-party audit. LAP Gold events and anchor material MUST be retained for at least ten years. A 24-hour incident-response capability is REQUIRED. These operational requirements are not proof that an implementation has obtained a certification.¶

7.1. Services and Continuity

The baseline service is an RFC 3161 TSA [RFC3161] supporting ESSCertIDv2 [RFC5816]. A transparency service with authenticated receipts, inclusion verification, and a documented append-only trust model MAY be used instead. Gold MUST include a transparency service. SCITT [RFC9943] and COSE Merkle receipts [RFC9942] are relevant mechanisms; their use does not by itself establish LAP conformance. Blockchain-only proofs do not satisfy this draft's mandatory baseline.¶

The policy MUST identify a primary and a distinct fallback service, trust anchors, verification rules, and a maximum failover window. The maximum MUST NOT exceed 2592000 seconds (30 days). Normal successful anchor intervals MUST NOT exceed the level's limit. On failure, the operator MUST retain the signed batch, retry and use the fallback within that window, and report the period as degraded. A failover window does not extend the normal interval or authorize a conformance claim for a missed deadline.¶

A gap exceeding twice the configured interval MUST produce an ANCHOR_GAP event, including last_successful_anchor_id, gap_start, detection_time, failed_endpoints, and retry evidence. A successful fallback MUST produce an ANCHOR_RECOVERED event linking the gap and receipt. Locally retained receipts MUST remain usable independently of the service's later availability. No failure or recovery event may be excluded from subsequent batches.¶

For a chain with no new events, a separately signed heartbeat statement MAY report the unchanged last anchor and observation time. It MUST NOT invent an event or claim inclusion of an empty batch. Policy-defined monitoring MUST distinguish an idle chain from an unavailable producer.¶

7.2. Signed Batch Statement and Receipt

A batch MUST cover a non-empty, consecutive range of one chain under one policy hash. Its statement MUST contain exactly the fields in the following layout; all counters are strings. An epoch is not inferred from a mutable service response.¶

{
  "schema_id": "ailex-lap-anchor-05",
  "anchor_id": "UUIDv7", "chain_id": "UUIDv7",
  "policy_id": "reverse.domain:local-id",
  "policy_hash": "sha-256:<digest>",
  "previous_anchor_hash": null,
  "first_sequence": "0", "last_sequence": "999",
  "event_count": "1000",
  "first_event_id": "UUIDv7", "last_event_id": "UUIDv7",
  "first_event_hash": "sha-256:<digest>",
  "last_event_hash": "sha-256:<digest>",
  "merkle_root": "sha-256:<digest>",
  "created_at": "RFC3339",
  "hash_algo": "sha-256", "sign_algo": "ed25519",
  "signer_id": "key identifier"
}

Let S be the JCS UTF-8 bytes of this statement. statement_hash is SHA-256(S). The operator MUST sign those raw 32 digest bytes with Ed25519. Let signed_statement be the JSON object with exactly three members: statement (the object above), statement_hash (the prefixed hexadecimal digest), and signature (ed25519: followed by the unpadded base64url signature). The anchor commitment is SHA-256(JCS(signed_statement)); the external service MUST bind this commitment, not the unbound Merkle root. previous_anchor_hash is the preceding signed_statement commitment in this chain, or null only for the first batch. Batches MUST NOT overlap or skip recorded sequence numbers.¶

An AnchorRecord contains signed_statement and a receipts array. Each receipt MUST identify anchor_type, service_endpoint, service_profile, commitment_hash, and proof. commitment_hash MUST match the signed_statement commitment. Receipts and service metadata are outside signed_statement to avoid circularity. Changing a receipt cannot change the anchored statement. The signature key MUST be bound to an authorized operator through an independently configured trust policy, not merely through a supplied key file.¶

For RFC3161, proof MUST include the DER TimeStampToken encoded in unpadded base64url, and the TSA certificate chain or sufficient references to obtain it. The verifier MUST check messageImprint.algorithm is SHA-256, messageImprint.hashedMessage equals the raw commitment bytes, the token signature, certificate purpose and path, applicable revocation evidence, and the TSA policy against configured trust. A displayed anchor_timestamp is not authoritative; use the verified token genTime.¶

For a transparency receipt, service_profile MUST name the exact immutable protocol version and statement-to-log-leaf encoding. proof MUST carry the authenticated checkpoint or signed receipt, inclusion path, leaf index, and tree size required by that protocol. Verification MUST bind the exact commitment to the authenticated checkpoint and validate the log key and trust policy. A bare sibling-hash array is insufficient. For SCITT, the binding MUST follow its Signed Statement and Receipt model. The LAP Merkle tree and the service tree are distinct and MUST NOT be conflated. Unsupported service profiles yield an unverifiable result, not a pass.¶

A batch verifier MUST check operator signature, policy validity, count equals last_sequence minus first_sequence plus one, first and last identifiers and hashes, chain and policy identity for every event, sequence continuity, previous batch linkage where available, and the external receipt. Missing surrounding batches MUST be disclosed as a scope limitation. Receipt validation failure MUST be reported separately from event signature validation.¶

7.3. Merkle Tree Construction

The batch tree uses SHA-256 with the domain separation and unbalanced-tree recursion in Section 2.1 of [RFC6962]. The same tree construction is retained in [RFC9162]. Each d(i) is the UTF-8 JCS serialization of the complete signed event, including event_hash and signature. Events are ordered by numeric sequence, not lexicographic string order.¶

MTH({})     = SHA-256(empty byte string)
MTH({d(0)}) = SHA-256(0x00 || d(0))
MTH(D[n])   = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n]))
k = largest power of two strictly less than n

An inclusion proof MUST supply the event, its zero-based leaf index, batch size, and ordered sibling hashes, all bound to the verified batch statement. Index and size use decimal strings. No duplicate last leaf is inserted for non-power-of-two trees. An inclusion proof establishes membership only. A claim that the full batch was disclosed requires all event bytes, exact committed count and range, and successful reconstruction of the root. Selective disclosures MUST be labeled partial and MUST NOT claim batch completeness.¶

9.1. Pack Structure

An Evidence Pack MUST contain:¶

• manifest.json: Pack metadata and integrity information¶

• events/: Event batches (max 10,000 events per file)¶

• anchors/: External anchor records¶

• merkle/: Merkle tree structure and selective disclosure proofs¶

• keys/: Public keys for signature verification¶

• signatures/: Pack-level signature¶

The Evidence Pack SHOULD be packaged as a ZIP archive with the media type application/vap-evidence-pack+zip (see Section 21.1). The manifest MUST use the media type application/vap-manifest+json.¶

9.2. Pack Manifest

manifest.json MUST be a JCS-compatible object containing schema_id ailex-lap-manifest-05, pack_id (UUIDv7), generated_at, profile, lap_level, policies, scope, files, statistics, verification, retention_status, and enforcement_metrics. All counters use decimal strings. policies lists each policy_id, policy_hash, and included policy path. scope MUST identify chains, sequence ranges, batch commitments, time range, and whether disclosure is complete or partial.¶

files MUST list every packaged data file with its relative path, byte size, and SHA-256 digest. It MUST NOT list manifest.json or the detached pack signature. Paths MUST be unique, relative, and free of traversal components; verifiers MUST reject unlisted data files, duplicate archive names, and mismatched digests. A pack signature is Ed25519 over SHA-256 of the JCS manifest bytes, stored in signatures/manifest.json with signer_id and signature. The signature file is excluded from the manifest to avoid circularity. Public keys in the pack are candidate verification material, not self-authenticating trust anchors.¶

The pack MUST include signed events, policy documents, AnchorRecords, inclusion or full-batch reconstruction data, key bindings, and applicable recovery, erasure, legal hold, policy-change, and gap records. A selective pack MUST identify undisclosed ranges. The pack signature does not replace event or external receipt verification.¶

verification MUST give separate results and evidence references for schema, event signatures, chains, batch roots, external receipts, policy, per-attempt consistency, and recovery/erasure controls. Each result MUST state whether it passed, failed, or was not evaluated and why. These are LAP report statuses, not upstream framework conformance labels. statistics MUST contain total_events and events_by_type. Retention and enforcement metrics MUST report unknown values explicitly instead of substituting zero. Bronze packs, if generated, follow the same format.¶

10.1. Salt Management Requirements

Per-tenant salts MUST meet the following requirements:¶

• Minimum entropy: 256 bits (32 bytes), generated using a cryptographically secure random number generator.¶

• Uniqueness: Each tenant MUST have a distinct salt. Implementations MUST NOT share salts across tenants.¶

• Storage: Salts MUST be stored separately from the hashed data and protected with access controls equivalent to signing keys.¶

• Rotation: Salts SHOULD be rotated at least annually. Upon rotation, previously hashed values are NOT re-hashed; the provenance chain records the salt epoch in effect at each event's timestamp.¶

For fields with low input entropy (such as bar registration numbers, which occupy a bounded numeric space), plain SHA-256(salt || value) is vulnerable to dictionary attack if the salt is compromised. For such fields, implementations MUST use HMAC-SHA-256 with the tenant salt as key:¶

  BarNumberHash = "sha-256:" || hex(HMAC-SHA-256(tenant_salt,
                                                bar_number_bytes))

In the event of salt compromise, the implementation MUST:

1. Generate a new salt immediately.¶

2. Record a SALT_ROTATION event in the provenance chain.¶

3. Assess and document the exposure window (events between last rotation and compromise discovery).¶

4. Notify affected tenants per applicable data breach notification requirements.¶

11.1. Privacy and Erasure

Crypto-shredding can limit access to encrypted content while preserving audit commitments. It does not by itself establish compliance with privacy law or remove all copies. An active legal hold or applicable retention duty MUST block destruction of the affected content keys. The operator MUST record the retention_exemption basis, approving actor, affected scope, and review date when a duty overrides a requested erasure.¶

Every completed destruction MUST generate an ERASURE event in the ordinary signed, chained, and anchored stream. domain_payload MUST include target_event_ids or an authenticated range manifest, reason, operator_id, and key_destruction_proof. The proof MUST identify the destroyed key identifiers, key manager, destruction time, and a signed destruction attestation or its digest with retrievable protected evidence. It MUST state residual backups or escrow copies and the evidence limits; a local deletion acknowledgment is not proof of universal deletion.¶

ERASURE MUST NOT rewrite prior signed bytes or remove hashes from an existing tree. Legal hold checks and authorization MUST precede destruction. A rejected or deferred request MUST be recorded as ERASURE_DEFERRED with retention_exemption, without pretending that destruction occurred. Tier changes that destroy keys require both the transition record and the linked ERASURE record. Legal adequacy remains a jurisdiction-specific determination.¶

11.2. Content Retention Tiers

Implementations face a tension between privacy-preserving verification (which favors early deletion of sensitive content) and legal discovery obligations (which may require content disclosure). To address this, LAP defines three content retention tiers that domain profiles MAY adopt:¶

Tier 1 - Full Content Retention

All event content (inputs, outputs,¶

documents) is retained in encrypted form alongside provenance hashes. Duration: configurable per tenant. Encryption MUST use AES-256-GCM or ChaCha20-Poly1305 with per-tenant keys.¶

Tier 2 - Recoverable Hash Retention

Original content is deleted but¶

a content recovery key is escrowed with a designated custodian. The escrowed key enables re-association of content from encrypted backups if a legal hold or disclosure order is triggered. Duration: from end of Tier 1 to the applicable retention period endpoint. See Section 11.3 for custodian requirements.¶

Tier 3 - Hash-Only Retention

Only provenance hashes remain. Content¶

is cryptographically unrecoverable (crypto-shredding complete). Duration: remainder of the retention period.¶

Transition from Tier 1 to Tier 2 MUST NOT occur while any Legal Hold is active for the affected events. Transition from Tier 2 to Tier 3 MUST NOT occur while any Legal Hold is active.¶

Implementations MUST log all tier transitions as RETENTION_TIER_CHANGE events in the provenance chain.¶

11.3. Escrow Custodian Requirements

Tier 2 escrow custodians MUST satisfy the following:¶

• The custodian MUST be organizationally independent from the VAP implementation operator (i.e., the entity that generates and signs provenance events).¶

• Key escrow operations (deposit, retrieval, destruction) MUST each generate a provenance event in the custodian's own audit log.¶

• Escrow keys MUST be encrypted at rest using the custodian's own key management infrastructure.¶

• Key granularity: implementations SHOULD use per-case or per-tenant escrow keys rather than a single global key, to limit the blast radius of any single key compromise.¶

• Recovery execution MUST require dual authorization: one from the requesting party (e.g., the tenant attorney) and one from the custodian.¶

A CONTENT_RECOVERY_EXECUTED event MUST be logged upon successful recovery, including: hold_id, recovered_event_range, recovered_by (actor hash), custodian_id, and court_order_reference_hash (if applicable).¶

11.4. Legal Hold Protocol

A Legal Hold freezes the current retention tier for all events within scope, preventing content deletion or tier transition.¶

Legal Hold triggers:¶

1. Court Order: Judicial order for evidence preservation.¶

2. Regulatory Investigation: Government regulatory action.¶

3. Litigation Hold: Reasonably anticipated litigation.¶

4. Professional Body Inquiry: Investigation by a professional regulatory body (e.g., bar association).¶

5. Disciplinary Proceedings: Professional disciplinary matters.¶

When a Legal Hold is activated:¶

1. All events within scope MUST be frozen at their current retention tier (Tier 1 or Tier 2).¶

2. A LEGAL_HOLD_ACTIVATED event MUST be recorded in the provenance chain, including: hold_id (UUIDv7), hold_trigger (enumerated trigger type), scope (event time range or case identifiers), activated_by (actor identity hash), and activation_timestamp ([RFC3339]).¶

3. Tier transitions for in-scope events MUST be blocked until a corresponding LEGAL_HOLD_RELEASED event is recorded.¶

4. The Legal Hold itself MUST be included in Evidence Packs generated during the hold period.¶

Legal Hold activation MUST be available at Bronze level. Automated Legal Hold detection (e.g., triggered by court filing notifications or regulatory inquiry receipt) is RECOMMENDED at Gold level.¶

11.5. Judicial Disclosure Response

When a court or regulatory body orders full content disclosure for specific events, the response depends on the current retention tier:¶

Events at Tier 1

Content is available in encrypted form and can be¶

disclosed subject to appropriate access controls and professional review.¶

Events at Tier 2

Content recovery key is retrieved from escrow per¶

Section 11.3. Content is reconstructed from encrypted backups. A CONTENT_RECOVERY_EXECUTED event MUST be logged in the provenance chain.¶

Events at Tier 3

Content is cryptographically unrecoverable. The¶

implementation MUST provide:¶

1. Hash chain integrity proof demonstrating unbroken provenance.¶

2. Tier transition log showing when and why content was deleted.¶

3. Certification that no Legal Hold was active at the time of deletion.¶

4. Statistical metadata (token counts, timestamps, event types) that remains available.¶

This three-tier approach enables implementations to demonstrate to judicial authorities that content deletion followed a documented, auditable process rather than constituting potential evidence spoliation.¶

NOTE: The adequacy of hash-only evidence for specific judicial proceedings is a jurisdiction-specific legal determination outside the scope of this specification. This framework provides the maximum available technical evidence in each retention tier.¶

12.1. Minimum Verification API

Silver and Gold level implementations that expose a third-party verification endpoint MUST support at minimum the following HTTP endpoints. All responses MUST use Content-Type application/json and MUST include appropriate authentication (e.g., Bearer token, mutual TLS).¶

GET /vap/v1/anchors?from={RFC3339}&to={RFC3339}

Returns anchor¶

records for the specified time range. Response: JSON array of Anchor Record objects per Section 7.2. REQUIRED for Silver+. All numeric response members MUST use the decimal string encoding of Section 5.1.¶

GET /vap/v1/chain/verify?from={RFC3339}&to={RFC3339}

Performs and¶

returns chain integrity verification results for the specified time range. Response: JSON object with fields: chain_valid (boolean), events_verified (decimal string), first_event_id, last_event_id, errors (array of {event_id, error_type, detail}). REQUIRED for Silver+. All numeric response members MUST use the decimal string encoding of Section 5.1.¶

GET /vap/v1/completeness?from={RFC3339}&to={RFC3339}

Returns¶

completeness invariant verification for the time range. Response: JSON object with fields: invariant_valid (boolean), grace_period_seconds (decimal string), pipelines (array of {pipeline_id, attempts, outcomes, valid}). REQUIRED for Silver+. All numeric response members MUST use the decimal string encoding of Section 5.1.¶

GET /vap/v1/events/{event_id}/proof

Returns Merkle inclusion proof¶

for a specific event. Response: JSON object with fields: event_id, anchor_id, merkle_root, inclusion_proof (array of Base64url sibling hashes), leaf_index, tree_size. REQUIRED for Silver+.¶

GET /vap/v1/events/stream (WebSocket or SSE)

Real-time event stream¶

for live monitoring. REQUIRED for Gold only.¶

Error responses MUST use standard HTTP status codes (400 for malformed requests, 401/403 for authentication/authorization failures, 404 for unknown resources, 500 for server errors) with a JSON body containing "error" (string code) and "detail" (human- readable description).¶

13.1. Proposed LAP Profile Identity

This revision uses profile.id LAP and profile.version 0.6.0. The domain is Legal AI / LegalTech. The schema identity is ailex-lap-event-05. These are identifiers defined by this draft, not a statement of IANA allocation or upstream profile registration. Framework-level mapping remains subject to independent assessment.¶

14.1. Pipeline 1: Legal Query

AI-powered legal consultation:¶

• LEGAL_QUERY_ATTEMPT: Question submission to AI¶

• LEGAL_QUERY_RESPONSE: AI response generated successfully¶

• LEGAL_QUERY_DENY: Response refused (content filter, unauthorized role)¶

• LEGAL_QUERY_ERROR: System error (API failure, timeout)¶

14.2. Pipeline 2: Document Generation

AI-assisted legal document drafting:¶

• LEGAL_DOC_ATTEMPT: Document generation request¶

• LEGAL_DOC_RESPONSE: Document generated successfully¶

• LEGAL_DOC_DENY: Generation refused (insufficient consent, unauthorized)¶

• LEGAL_DOC_ERROR: System error (API failure, parse error)¶

14.3. Pipeline 3: Fact Check

AI-powered legal fact verification:¶

• LEGAL_FACTCHECK_ATTEMPT: Fact-check request¶

• LEGAL_FACTCHECK_RESPONSE: Fact-check completed¶

• LEGAL_FACTCHECK_DENY: Fact-check refused (OPTIONAL)¶

• LEGAL_FACTCHECK_ERROR: System error¶

Implementations MAY define LEGAL_FACTCHECK_DENY for cases where a fact-check request is refused due to rate limiting, insufficient permissions, or consent constraints. The deny_reason field SHOULD distinguish these from system errors.¶

If an implementation does not support LEGAL_FACTCHECK_DENY, refusal conditions MUST be recorded as LEGAL_FACTCHECK_ERROR with a deny_equivalent indicator set to true in the error detail, ensuring the Completeness Invariant is maintained.¶

14.4. Cross-Cutting: Human Override

HUMAN_OVERRIDE events record an attorney's review of any AI output:¶

• APPROVE: Attorney confirms AI output without modification¶

• MODIFY: Attorney edits AI output (modification hash recorded)¶

• REJECT: Attorney rejects AI output entirely¶

HUMAN_OVERRIDE events MUST set header.causal_link.target_event_id to the target outcome event's identifier and header.causal_link.link_type to "OVERRIDE_OF". The event MUST also include the attorney's identity (bar number hash), override type, and optional modification details in the domain_payload.¶

14.5. Retention and Enforcement Events

LAP defines additional event types for retention management and override enforcement:¶

RETENTION_TIER_CHANGE

Records transitions between content retention¶

tiers. Fields: previous_tier, new_tier, affected_event_range, reason, authorized_by.¶

LEGAL_HOLD_ACTIVATED

Records activation of a legal hold. Fields:¶

hold_id, hold_trigger, scope, activated_by.¶

LEGAL_HOLD_RELEASED

Records release of a legal hold. Fields:¶

hold_id, released_by, release_reason.¶

CONTENT_RECOVERY_EXECUTED

Records recovery of content from Tier 2¶

escrow. Fields: hold_id, recovered_event_range, recovered_by, custodian_id, court_order_reference_hash.¶

REVIEW_WARNING_ACKNOWLEDGED

Records that an attorney acknowledged an¶

unreviewed-output warning before proceeding with export. Fields: target_event_id, warning_type, acknowledged_by.¶

REVIEW_GATE_BLOCKED

Records that an export attempt was blocked due¶

to missing HUMAN_OVERRIDE. Fields: target_event_id, document_type, blocked_action.¶

REVIEW_GATE_OVERRIDE

Records that an attorney bypassed a review gate¶

with explicit justification. Fields: target_event_id, override_reason, overridden_by.¶

SALT_ROTATION

Records rotation of tenant privacy salt. Fields:¶

previous_salt_epoch, new_salt_epoch, rotated_by, reason.¶

These events are NOT part of the three-pipeline Completeness Invariant (they are control and administrative events, similar to HUMAN_OVERRIDE). However, they MUST be included in the hash chain and signed.¶

14.6. Recovery and Assurance Administration

Additional event types are RECOVERY, ANCHOR_GAP, ANCHOR_RECOVERED, ERASURE, ERASURE_DEFERRED, POLICY_CHANGE, MIGRATION, XREF_OBSERVATION, and LATE_RESULT. They are signed, chained, and anchored like all other events and are outside terminal outcome counts.¶

RECOVERY means an operation affecting interpretation of a broken sequence, not recovery of encrypted content under Section 11. For every level, the default automatic SKIP bound is zero events, automatic MERGE bound is zero source chains, and automatic CHECKPOINT bound is zero unverified events. Automatic REBUILD is permitted only when all original signed event bytes and their validated anchor receipts are available: the bound is one already committed batch per operation and one such operation per chain per 86400 seconds. It MUST preserve all bytes, IDs, sequence values, and old proofs. It MUST NOT synthesize missing events. Policies MAY set stricter bounds.¶

Any recovery exceeding these bounds requires an Emergency Override approved by an identified human before execution. The RECOVERY event MUST identify operation_type, break_point (chain, sequence, last valid hash), affected ranges, quantitative bound, observed quantity, reason, validation_evidence hashes, approving actor, approval time, and emergency_override boolean. Such an override MUST be flagged in the evidence report; approval does not turn an unverified interval into a continuous valid chain.¶

If the old chain cannot continue, a new chain MUST begin with a RECOVERY event referencing the old chain and last verified anchor; its genesis prev_hash remains null. The old chain, break evidence, and both sets of receipts MUST be retained. Recovery records MUST NOT be filtered out of anchor batches, exports, or applicable verification scope. Repeated bounded operations MUST NOT be used to evade the daily bound.¶

14.7. Optional Cross-Party References

When used, header.cross_reference_id MUST be a shared UUIDv7 recorded independently by participating parties. XREF_OBSERVATION domain_payload MUST declare role (INITIATOR, COUNTERPARTY, or OBSERVER), counterpart identity, referenced event identifiers, matching policy, time tolerance in seconds, observation status (PENDING, MATCHED, DISCREPANCY, or TIMEOUT), and severity (INFO, WARNING, or CRITICAL). Each party's evidence MUST be independently signed and anchored. MATCHED requires validated counterpart evidence satisfying the declared matching policy; one party's unverified claim is insufficient. Confidential fields MUST NOT be disclosed merely to create a cross-reference.¶

16.1. Override Coverage Metric

HUMAN_OVERRIDE events are outside the Completeness Invariant but LAP defines Override Coverage as a critical operational metric:¶

• Override Coverage =

  Count(distinct target_event_id with at least one HUMAN_OVERRIDE where link_type = "OVERRIDE_OF") /¶

  Count(LEGAL_*_RESPONSE)

This metric quantifies the degree to which human professionals review AI outputs. In jurisdictions where regulations require that a licensed professional personally scrutinize AI-generated work products, this metric provides evidence of recorded review activity, without establishing legal compliance or review quality.¶

Design notes on the denominator:¶

• The numerator counts distinct target events (not raw HUMAN_OVERRIDE count) to prevent a single output reviewed multiple times from inflating coverage above 100%.¶

• DENY events are excluded from the denominator because a denial represents the AI system refusing to produce output. There is no AI-generated work product for a professional to review. If a jurisdiction requires that denial decisions themselves be reviewed, the implementation SHOULD track this as a separate "Denial Review Coverage" metric.¶

• ERROR events are excluded from the denominator because they do not produce an output suitable for professional approval or rejection. Completeness of error handling is evaluated separately via the per-pipeline invariant.¶

    +==========+============+==================================+
    | Coverage | Assessment | Operational Implication          |
    +==========+============+==================================+
    | 100%     | Ideal      | Full professional oversight of   |
    |          |            | all AI outputs                   |
    +----------+------------+----------------------------------+
    | 70-99%   | Good       | Majority reviewed; low-risk      |
    |          |            | outputs may be excluded          |
    +----------+------------+----------------------------------+
    | 30-69%   | Warning    | Insufficient review; operational |
    |          |            | improvement recommended          |
    +----------+------------+----------------------------------+
    | <30%     | Critical   | Professional oversight           |
    |          |            | requirements likely unmet        |
    +----------+------------+----------------------------------+

16.2. Interpreting Review Coverage

Coverage counts recorded HUMAN_OVERRIDE links, not verified professional diligence. A value of 100 percent establishes neither correctness nor compliance. The report MUST declare its time range, denominator, excluded events, duplicates, and unavailable evidence. A zero denominator is not applicable, not 100 percent. Operational alert thresholds are a deployment policy choice and MUST NOT be presented as legal adequacy thresholds.¶

16.3. Enforcement Level Mapping

  +=======================+==========+=============+=============+
  | Enforcement           | Bronze   | Silver      | Gold        |
  +=======================+==========+=============+=============+
  | Level 0 (Metric Only) | Default  | Minimum     | N/A         |
  +-----------------------+----------+-------------+-------------+
  | Level 1 (Warn)        | OPTIONAL | REQUIRED    | REQUIRED    |
  +-----------------------+----------+-------------+-------------+
  | Level 2 (Gate)        | N/A      | RECOMMENDED | RECOMMENDED |
  +-----------------------+----------+-------------+-------------+
  | Level 3 (Strict)      | N/A      | OPTIONAL    | OPTIONAL    |
  +-----------------------+----------+-------------+-------------+

16.4. Enforcement Level Mapping

Bronze has no mandatory review gate; Level 0 is its default if coverage is computed. Silver and Gold MUST implement Level 1 warnings at minimum and SHOULD implement Level 2 gates for designated high-risk outputs. Level 3 is OPTIONAL at any level. Stronger enforcement does not replace signatures, anchors, or evidence of the actual review.¶

16.5. Structural Limitation Acknowledgment

This specification acknowledges that no technical mechanism can fully guarantee the quality or depth of human professional review. A licensed attorney may approve an AI output after genuine review or after cursory inspection; the system cannot distinguish between these without introducing unacceptable surveillance of professional judgment.¶

The enforcement framework therefore aims to: (a) create friction against entirely unreviewed AI output usage; (b) provide auditable evidence of review or lack thereof; (c) enable risk-proportionate controls (stronger for high-risk document types); and (d) preserve professional autonomy while recording accountability metadata.¶

The combination of enforcement levels, latency monitoring, and comprehensive provenance logging shifts the accountability model from "trust alone" to "trust with verification infrastructure," acknowledging that while absolute prevention is impossible, the cost and detectability of non-compliance can be substantially increased.¶

20.1. Threat Model

VAP assumes the following attacker capabilities and trust assumptions:¶

• Attacker capabilities: An adversary may have read access to the event store, network access to observe event traffic, and in some scenarios write access to event storage (insider threat). The adversary's goal is to forge, suppress, reorder, or selectively disclose provenance events.¶

• Trust assumptions: The signing key holder is trusted to sign only genuine events. The external anchoring service is trusted to provide accurate timestamps and append-only guarantees. Verifiers are trusted to correctly execute the verification algorithm.¶

20.2. Hash Chain Manipulation

An adversary with write access could attempt to modify past events, insert fabricated events, or delete events. The hash chain provides integrity: any modification to a past event changes its EventHash, breaking the chain at that point. External anchoring at every LAP level makes post-hoc modification detectable by comparing the stored Merkle root against the independently timestamped root. Implementations SHOULD use Merkle consistency proofs (per [RFC9162] Section 2.1.4) to detect log forking.¶

20.3. Timestamp Limits

Event timestamps are producer assertions. Verifiers MUST check internal chronology, receipt time, configured clock uncertainty, and the declared anchoring interval separately. A daily batch can legitimately include events many hours before its receipt; a fixed 300-second event-to-receipt limit is therefore inappropriate. Events later than the authenticated receipt time plus the declared clock tolerance MUST be flagged. A receipt proves commitment existence no later than that time, not truth of each event timestamp.¶

20.4. Insider Threats

An authorized operator could forge events, suppress events before they are anchored, or create fabricated ERROR events to satisfy the Completeness Invariant while hiding actual outcomes. Mitigations include:¶

• External anchoring makes suppression detectable after anchoring.¶

• Gold level implementations SHOULD require multi-party signatures for administrative events (Legal Hold, tier changes).¶

• Separation of duties: the event signer and the external anchor submitter SHOULD be different principals where operationally feasible.¶

• Completeness Invariant cross-validation against application-layer logs (e.g., HTTP request logs) can detect fabricated events at audit time.¶

20.5. Key Compromise

Compromise of signing keys allows event forgery. Bronze implementations SHOULD rotate keys annually. Silver MUST rotate semi-annually. Gold MUST use HSM storage ([FIPS140-3]) and quarterly rotation.¶

Upon key compromise detection, the implementation MUST:¶

1. Immediately revoke the compromised key.¶

2. Generate a new signing key pair.¶

3. Record a KEY_ROTATION event signed by the new key, referencing the compromised key identifier.¶

4. Preserve all original events and receipts; issue a new signed incident attestation identifying the affected range and any supplemental anchor. New anchoring does not validate previously compromised signatures.¶

5. Notify all relying parties of the compromise and the validity window of the affected key.¶

During key rotation (including non-emergency rotation), the hash chain continues unbroken. The new key signs a KEY_ROTATION event that includes the old key's public key hash, establishing chain continuity. Verifiers MUST validate key authorization and compromise status independently; a KEY_ROTATION event signed only by an untrusted new key is insufficient. An overlap period does not override revocation evidence.¶

20.6. Privacy Leakage

Per-tenant salting prevents cross-tenant hash correlation. Implementations MUST NOT share salts across tenants. Event metadata (timestamps, event types, counts) may leak statistical information even when content is hashed; this is an inherent limitation of any audit trail system. Selective disclosure via Merkle proofs (Section 7.3) enables verifiers to inspect specific events without accessing the full event store, reducing exposure.¶

For privacy analysis guidance, see [RFC6973].¶

20.7. Availability Attacks

Denial-of-service attacks against the logging infrastructure could prevent event recording, violating completeness. Gold level implementations MUST have geographic redundancy. Implementations SHOULD buffer events locally when the central event store is unavailable, and MUST reconcile buffered events upon reconnection.¶

20.8. Omission and Split Views

A verified count, range, and Merkle commitment detect omitted or changed members when a producer claims to disclose the complete committed batch. Inclusion proofs for a subset cannot establish full disclosure. An operator may omit entire attempt/outcome pairs before capture or present different signed histories to different recipients. Checkpoint comparison, independent witnesses, and cross-party records are needed to detect split views. A single receipt and internally balanced counters do not establish global completeness.¶

20.9. Selective Disclosure Attacks

An adversary could present only favorable events to a verifier, hiding unfavorable records. The Completeness Invariant detects such omissions: any missing outcome event will cause the invariant to fail for the affected pipeline. External anchoring of Merkle roots makes it infeasible to present a consistent subset of events that satisfies the invariant if any events have been omitted.¶

20.10. Replay Attacks

An adversary could replay valid events from one context into another. The chain_id field binds events to a specific chain, and the prev_hash field creates a strict ordering dependency that makes replayed events detectable (they will break the hash chain at the insertion point). UUIDv7 event identifiers provide globally unique, time-ordered identification that further constrains replay.¶

20.11. Content Retention and Discovery Risk

The tension between privacy-preserving hash-only retention and judicial discovery obligations creates a risk that hash-only evidence may be deemed insufficient by courts. The Tiered Retention model (Section 11.2) mitigates this by maintaining recoverable content during periods when discovery is most likely, while the Legal Hold Protocol (Section 11.4) prevents premature content destruction when litigation is anticipated.¶

20.12. Override Enforcement Circumvention

Enforcement Levels 1 and 2 (Section 16.2) can be circumvented by users who copy AI output through means outside the system's control (e.g., screen capture, manual transcription). Technical enforcement addresses the common case of system-mediated export but cannot prevent all forms of circumvention. The provenance chain nonetheless records the absence of HUMAN_OVERRIDE events, providing post-hoc accountability.¶

20.13. Rapid Approval Gaming

Users aware of the Override Latency threshold (Section 16.4) might delay approval clicks to avoid the RAPID_APPROVAL_FLAG. This is a known limitation. Statistical analysis of approval latency distributions across users and document types can detect such gaming patterns in audit reviews.¶

20.14. Legal Hold Integrity

Legal Hold activation and release events must be protected from unauthorized modification. Gold level implementations SHOULD require multi-party authorization for Legal Hold release.¶

21.1. Media Type Registration

IANA is requested to register the following media types in the "Media Types" registry:¶

21.2. Profile Identifier Scope

This draft defines LAP for use with its explicit schema identifiers. It makes no request to reserve identifiers for other upstream profiles and does not create or amend the upstream VAP registry. Coordination of any future IANA profile registry with that upstream registry remains an open issue.¶

21.3. Event Type Scope

The event names in Section 14 are scoped by the LAP schema_id and profile version. This revision does not request a cross-domain VAP event registry. The media type registrations above remain proposals; no allocation is asserted.¶

B.1. Serialization and Merkle Primitive Vectors

These small objects exercise serialization and tree construction only; they are not LAP events or signatures. The exact inputs contain no leading or trailing whitespace. All digests are SHA-256 hexadecimal. For the third leaf (index 2, size 3), the sibling is the two-leaf root on the left.¶

d(0) = {"a":"1","b":true}
d(1) = {"a":"2","b":false}
d(2) = {"a":"3","b":null}

empty_root =
  e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
two_leaf_root =
  81bf82be3b1303d45cb2bcc0996c743674186a4c45db54868536ba5fb0737a20
three_leaf_root =
  e2432afb47c308a949b76a048780be5c9765b0ea6d27b17f167a08c5670d32d7

leaf(0) =
  fba9de6076dc98b39a486ee4d32ca78e6b3b0d238d6f02df056fbf20058bbf8a
leaf(1) =
  3623daa57bddb441e0a4e7732f002ee50196107848e4f08706d47a67d91890ca
leaf(2) =
  bd476a15d851fe0ef64cc866e8e3b82108c9544b17079b59f46e1db51e8bae1a

D.1. Changes from -04 to -05

• Pin upstream VAP v1.2.0 Draft 3; distinguish LAP levels, schema, authority, and profile status.¶

• Require signed Merkle commitments and external anchors for Bronze, Silver, and Gold; bind policy, count, range, and previous batch; define continuity and fallback reporting.¶

• Add schema identity, numeric string rules, trace and sequence identifiers, immutable policy binding, and explicit signed-byte definitions. Advance LAP profile version to 0.6.0; preserve legacy records.¶

• Bound recovery, require erasure evidence and legal hold checks, and specify optional cross-party evidence.¶

• Limit completeness claims to declared captured evidence; remove fabricated timeout balancing and unsupported compliance/implementation claims.¶

• Define detached Evidence Pack commitments and retain legal review, escrow, and hold controls. Add serialization and Merkle test vectors.¶

D.2. Historical Revision Notes

This section tracks changes between Internet-Draft revisions and will be removed before publication.¶

draft-ailex-vap-legal-ai-provenance-04¶

• Refreshed the document. There are no technical changes to the VAP Framework or to LAP; vap_version remains 1.4 and the LAP Profile Version remains 0.5.0.¶

• Replaced the reference to the SCITT architecture Internet-Draft with [RFC9943], which has been published since the previous revision, and replaced the unresolved "[IETF-SCITT]" citation in Section 22 with the same reference.¶

• Updated the SCITT Reference APIs (SCRAPI) reference to its current revision.¶

• Added [RFC9711] (EAT) as an informative reference for its existing mention in Section 22.¶

• Aligned the vap_version example values in Section 5 and Section 9.2, and the Profile Version in Section 13.1, with the versions announced in -03 (1.4 and 0.5.0, respectively).¶

• Corrected cross-references: citations of Section 5 of RFC 4648, Section 6 of RFC 8259, and Section 2 of RFC 9162 previously linked to sections of this document; the EU AI Act citation in draft-04 19.2 now reads "Annex III, point 8(a)"; in-text references to "Table 1" and "Table 2" now point to Figure 1 and Figure 2; and the existing mentions of FIPS 203 and FIPS 204 in Section 4.1 now cite [FIPS203] and [FIPS204].¶

• Updated Appendix C (Implementation Status) to distinguish the first-generation AILEX SaaS platform from its successor implementation.¶

• Editorial: restored the revision heading for -03 in this change log.¶

draft-ailex-vap-legal-ai-provenance-03¶

• Added draft-04 22.1 "Relationship with DMSC and Multi-Agent Collaboration Frameworks" with four subsections: Scope Differentiation, Complementary Layering, Integration Points, and Non-Dependency Statement.¶

• Added layered architecture diagram (draft-04 ure-vap-lap-and-dmsc-layered-architecture) illustrating the complementary positioning of Application Layer, Domain Profile Layer (LAP), Provenance/Anchoring Layer (VAP), Collaboration Layer (DMSC), and Security/Transport Layer.¶

• Added disambiguation NOTE clarifying that "DMSC" in this document refers to Dynamic Multi-agent Secured Collaboration, with cross-reference to the Distributed Micro Service Communication usage of the same acronym.¶

• Added terminology entries: Secure Multi-Agent Collaboration, AI Agent Collaboration Provenance, Provenance Profile, and Domain-Specific Provenance Constraints (Section 2.1).¶

• Defined integration points between VAP-LAP and DMSC-class frameworks using existing Common Event Structure fields (actor_id, causal_link, chain_id, domain_payload) without introducing new fields (draft-04 22.1.3).¶

• Clarified that VAP-LAP operates as a provenance and domain profile layer independent of any specific collaboration framework, while identifying concrete integration points with DMSC-class architectures.¶

• Added informative references DMSC-BOF, DMSC-ARCH, DMSC-TECH, DMSC-DTA.¶

• Updated vap_version from 1.3 to 1.4.¶

• Updated LAP Profile Version from 0.4.0 to 0.5.0.¶

draft-ailex-vap-legal-ai-provenance-02¶

• Added individual author name (Shintaro Yamakawa) per IETF guidelines requiring personal author identification.¶

• Fixed cryptographic algorithm naming: Kyber-1024 renamed to ML- KEM-1024 per FIPS 203 standardization; separated into distinct KEM category from Encryption. Added ML-DSA-65 parameter set selection rationale.¶

• Resolved EventHash circular reference: defined explicit Hash Input excluding security.event_hash and security.signature from canonicalization input (Section 4.2).¶

• Resolved crypto agility contradiction: hash chain and signature formulas now parameterized by hash_algo/sign_algo fields instead of hardcoding SHA-256/Ed25519. Added Algorithm Migration procedure (Section 4.4) with post-quantum readiness subsection referencing FIPS 204 and RFC 9794.¶

• Updated Merkle tree construction to follow RFC 9162 (replacing obsoleted RFC 6962), with domain separation prefixes and correct handling of non-power-of-two leaf counts (Section 7.3).¶

• Fixed encoding specifications: timestamps now require RFC 3339; Base64 encoding now requires RFC 4648, Section 5 (URL-safe, no padding); hash values standardized as lowercase hex; RFC 8259 added to normative references (Section 5).¶

• Updated FIPS 140-2/3 to FIPS 140-3 as primary requirement with transition period note (Section 6.3).¶

• Added RFC 5816 (ESSCertIDv2) as normative reference for RFC 3161 TSA SHA-256 support (Section 7.1).¶

• Specified anchor_proof structure per anchor_type with type- specific fields and verification procedures (Section 7.2).¶

• Added Completeness Invariant grace period maximum of 300 seconds with TIMEOUT_ERROR mechanism (Section 8).¶

• Added standardized causal_link field in header for all event types, with link_type enumeration (Section 5).¶

• Fixed Override Coverage metric: numerator changed to count distinct target_event_id to prevent exceeding 100%. DENY removed from denominator with rationale documented (Section 16.1).¶

• Added salt management requirements: 256-bit minimum entropy, HMAC- SHA-256 for low-entropy fields, rotation and compromise response procedures (Section 10.1).¶

• Added minimum verification API with HTTP endpoints for Silver and Gold levels (Section 12.1).¶

• Added Bronze-level validation requirements specifying minimum field presence and type checking (Appendix B).¶

• Expanded Security Considerations with explicit threat model, 12 specific threat analyses per RFC 3552, key rotation procedures, and denial-of-provenance mitigation (Section 20).¶

• Expanded IANA Considerations with media type registration templates, VAP Domain Profile registry, and VAP Event Type registry per RFC 8126 (Section 21).¶

• Added GDPR interaction subsection addressing right-to- erasure vs. audit trail tension (Section 11.1).¶

• Added escrow custodian requirements for Tier 2 content recovery (Section 11.4).¶

• Added Relationship to Other Work section positioning VAP relative to SCITT, RATS/EAT, AIPREF, Sentinel Protocol, and ISO/IEC standards (Section 22).¶

• Added Implementation Status appendix per RFC 7942 (Appendix C).¶

• Added Japan AI Promotion Act (2025) to regulatory alignment references.¶

• Added SALT_ROTATION event type to LAP administrative events (Section 14.5).¶

• Removed EIP from profile.id enumeration (undefined profile).¶

• Normalized all algorithm identifiers to lowercase hyphenated ASCII strings with explicit canonical mapping table (Section 4.1). Resolved inconsistency between field values (e.g., "SHA-256") and wire prefixes (e.g., "sha256:") by unifying on a single form (e.g., "sha-256" / "sha-256:").¶

• Added UTF-8 encoding requirement for all text fields (Section 5, RFC 3629).¶

• Updated vap_version from 1.2 to 1.3.¶

• Updated LAP Profile Version from 0.3.0 to 0.4.0.¶

• Updated Abstract to reference SCITT.¶

draft-ailex-vap-legal-ai-provenance-01¶

• Added Tiered Content Retention model (Section 11.2).¶

• Added Legal Hold Protocol (Section 11.5) with five trigger types.¶

• Added Judicial Disclosure Response procedures (Section 11.6).¶

• Expanded Override Coverage with four-level Enforcement Framework.¶

• Added Override Latency Threshold with Rapid Approval Flag.¶

• Added Section 16.5 acknowledging structural limitations.¶

• Added seven new event types for retention and enforcement.¶

• Extended Evidence Pack manifest with retention_status and enforcement_metrics.¶

• Updated LAP Profile Version from 0.2.0 to 0.3.0.¶

draft-ailex-vap-legal-ai-provenance-00 Initial submission.¶