AILEX LLC / VeritasChain Standards Organization

1-10-8 Dogenzaka, Shibuya-ku Tokyo 150-0043 Japan info@ailex.co.jp https://ailex.co.jp

This document specifies an experimental Legal AI Profile (LAP) for verifiable AI provenance, informed by the Verifiable AI Provenance (VAP) Framework. It defines event signatures, hash chains, signed batch commitments, external anchoring, and evidence packages for legal consultation, document generation, and fact checking.This revision aligns the LAP design with a pinned VAP v1.2.0 Draft 3 baseline. All LAP levels require Merkle trees and external anchoring. LAP Bronze, Silver, and Gold remain profile-specific levels; they do not establish VAP Core, Standard, or Full conformance. The document also defines bounded recovery, erasure records, human review records, and legal hold controls.Verification concerns recorded evidence within a declared scope. It does not prove that every real-world operation was captured, that an AI output is correct, or that legal obligations have been met. This is an individual Internet-Draft and a proposed profile, not an IETF standard or a registered VAP profile.

IntroductionLegal AI systems need inspectable records of inputs, outputs, actors, and human review. Cryptographic evidence can make later alteration detectable while leaving questions about capture accuracy, professional judgment, and legal consequences to other controls.This document defines the LAP event format and assurance requirements. Sections 3 through 12 describe infrastructure used by LAP; they do not redefine the upstream VAP framework for other profiles.

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 . 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.

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 . 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.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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.

VAP Alignment and LAP Architecture

Layer ModelThe 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.

Profile Status and LevelsLAP 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.

Cryptographic Foundation

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.

Required Cryptographic Algorithms +============+================+===================+==============+ | 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 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 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:

Canonical Algorithm Identifiers +===========+========================+==================+===========+ | 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 .

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 (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.

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 matching the security.sign_algo field (e.g., "ed25519", "ecdsa-p256"), and Base64url encoding follows (URL-safe alphabet, no padding). The primary mandatory-to-implement (MTI) signature algorithm is Ed25519 . Implementations MUST support Ed25519 and SHOULD support at least one additional algorithm from for migration purposes.

Algorithm MigrationAlgorithm migration follows the principles of . 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.

Post-Quantum PlanningLong-lived evidence requires monitoring cryptographic strength. Implementations SHOULD plan for standardized post-quantum mechanisms and preserve original verification material. This revision does not define an interoperable hybrid signature format or assert a mandatory migration calendar. See and for related mechanisms and terminology.

LAP Common Event StructureEvery LAP event MUST contain the members below. This is a field-layout illustration, not a valid signed test event. All shown objects are required. An absent approval is represented by null in both approval fields; actor_id and actor_hash may be pseudonymous but MUST identify the recorded actor consistently within the declared scope. { "schema_id": "ailex-lap-event-05", "vap_version": "1.2.0-draft3", "profile": {"id": "LAP", "version": "0.6.0"}, "policy": {"policy_id": "reverse.domain:local-id", "policy_hash": "sha-256:<digest>"}, "header": { "event_id": "UUIDv7", "chain_id": "UUIDv7", "sequence": "0", "trace_id": "UUIDv7", "prev_hash": null, "timestamp": "RFC3339", "event_type": "LEGAL_QUERY_ATTEMPT", "causal_link": {"target_event_id": null, "link_type": null} }, "provenance": { "actor": {"actor_id": "pseudonym", "actor_hash": "sha-256:<digest>", "role": "attorney"}, "input": {}, "context": {}, "action": {}, "outcome": {} }, "accountability": {"operator_id": "operator identifier", "last_approval_by": null, "approval_timestamp": null}, "domain_payload": {}, "security": {"event_hash": "sha-256:<digest>", "hash_algo": "sha-256", "sign_algo": "ed25519", "signer_id": "key identifier", "signature": "ed25519:<base64url>"} } event_id, chain_id, and trace_id MUST be UUIDv7 values per . event_id MUST be unique. A trace_id joins events of one operation, including its outcome and reviews. A chain_id identifies one append-only sequence. sequence starts at the string "0" and increases by one for each recorded event. prev_hash is null only for genesis; otherwise it is the preceding event_hash, including its algorithm prefix. A sequence number describes recording order, not verified wall-clock order.All strings MUST be valid Unicode encoded as UTF-8. Timestamps MUST use with an explicit time zone; UTC is RECOMMENDED. Duplicate JSON member names, invalid Unicode, NaN, Infinity, and JSON numbers MUST be rejected. Hashes use a lowercase algorithm prefix, a colon, and the exact lowercase hexadecimal digest. Signatures use the matching lowercase algorithm prefix and unpadded base64url. Unknown algorithm identifiers MUST NOT be normalized into known algorithms.Outcome events MUST link to their attempt with OUTCOME_OF. HUMAN_OVERRIDE events MUST link to the reviewed output with OVERRIDE_OF. Events without a causal link use null for both causal members. Other links use HOLD_ON, RECOVERY_OF, or TIER_CHANGE_OF as appropriate. Extension members are permitted and are included in the signed Hash Input. Unknown critical semantics prevent a positive conformance result, even if the cryptographic check succeeds.

Numeric Value EncodingAll 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 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.

Compatibility and Policy IdentificationThis 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.

LAP Conformance LevelsEach LAP level inherits all requirements of lower levels. These are experimental profile requirements, separate from upstream VAP conformance. A system lacking required evidence MUST NOT claim the corresponding LAP level.

BronzeBronze 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.

SilverSilver 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.

GoldGold 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.

External AnchoringEvery LAP level MUST anchor signed batch commitments externally. A verified receipt establishes that a commitment existed no later than the receipt time under the service trust model. It does not establish when the underlying real-world action occurred or prevent a dishonest producer from omitting activity before capture.

Services and ContinuityThe baseline service is an RFC 3161 TSA supporting ESSCertIDv2 . 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 and COSE Merkle receipts 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.

Signed Batch Statement and ReceiptA 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.

Merkle Tree ConstructionThe batch tree uses SHA-256 with the domain separation and unbalanced-tree recursion in . The same tree construction is retained in . 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.

Scoped Attempt and Outcome ConsistencyFor each captured attempt, a verifier checks exactly one linked terminal outcome of the corresponding pipeline, rejects duplicate outcomes and orphan links, and checks totals as a secondary consistency test. Matching totals alone are insufficient: one missing outcome and one duplicate can cancel numerically.The check MUST state the chain, policy, sequence and time ranges, anchoring status, and available independent capture evidence. Attempts within a declared grace period are pending. The grace period MUST NOT exceed 300 seconds; 60 seconds is RECOMMENDED. An attempt still unresolved afterward is reported as missing an observed outcome. A verifier MUST NOT fabricate a TIMEOUT_ERROR merely to make counts balance. A producer may record an actual timeout it observed, with evidence and pipeline-specific ERROR type; a later result is a supplemental LATE_RESULT event linked to that terminal event and MUST NOT be counted as a second terminal outcome.A pass means the supplied, verified captured records satisfy these checks. It does not establish that every real-world attempt was captured. An operator can omit both an attempt and its outcome before anchoring. Independent request logs, counters, counterpart records, or capture attestation are needed to assess such omissions. Unavailable scope or evidence MUST be reported explicitly and MUST NOT be converted into a positive result. These are LAP reporting rules, not a claim that an upstream research proposal has been adopted.

Evidence Pack Specification An Evidence Pack is a self-contained, signed package of provenance events intended for third-party examination within a declared scope.

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 ). The manifest MUST use the media type application/vap-manifest+json.

Pack Manifestmanifest.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.

Privacy-Preserving Verification VAP enables verification of system integrity without disclosure of sensitive data. This is achieved through:

1. Hash-based attestation: Sensitive fields are stored as cryptographic hashes, enabling existence verification without content disclosure.
2. Selective disclosure via Merkle proofs: Individual events can be proven to exist within an Evidence Pack without revealing other events.
3. Per-tenant salting: Hash salts are unique per tenant to prevent cross-tenant correlation attacks.

This mechanism is particularly critical for LAP, where attorney- client privilege prevents disclosure of consultation content while still requiring verifiable audit trails.

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.

Retention Framework The LAP minima are defined in . Any longer applicable retention duty or active legal hold takes precedence. Private signing keys MUST NOT be retained merely to verify old signatures; retain public keys, key bindings, revocation history, policies, and proofs for the verification lifetime. Retention periods MUST be extended upon: regulatory investigation notification, legal hold orders, security or safety incidents, and third-party audit requests. Domain profiles MAY specify extended retention periods beyond the VAP baseline where domain-specific regulations require longer retention (see for LAP extensions).

Privacy and ErasureCrypto-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.

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 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.

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).

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 ().
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.

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 . 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.

Third-Party Verification Protocol Verification is available at three access levels: Public Access to Merkle roots only. Verifies anchor existence.

Auditor

Access to Evidence Packs. Full chain and completeness verification.

Regulator

Real-time API access (Gold level). Live monitoring capability.

Verification steps:

1. Anchor Verification: Confirm Merkle root in external timestamping service or transparency log.
2. Chain Verification: Validate hash chain integrity from genesis to latest event.
3. Signature Verification: Authenticate all events with public keys.
4. Completeness Verification: Check invariant for the time period.
5. Selective Query (optional): Verify specific events via Merkle proofs.

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 . 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).

Legal AI Profile OverviewLAP records legal queries, document generation, fact checks, and human reviews. It provides evidence of recorded actions and responsible actors. A review event is an attributable assertion of review, not proof of lawful practice, a valid professional license, or substantive correctness. Privacy commitments and access controls protect evidence; they do not themselves establish privilege.

Proposed LAP Profile IdentityThis 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.

LAP Event Type Taxonomy LAP defines three functional pipelines, one cross-cutting control event type, and administrative event types for retention and enforcement management:

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)

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)

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.

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.

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.

Recovery and Assurance AdministrationAdditional 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.

Optional Cross-Party ReferencesWhen 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.

LAP Completeness Invariant LAP applies the Completeness Invariant independently to all three pipelines:

• For each pipeline P in {QUERY, DOC, FACTCHECK}:

Count(LEGAL_{P}_ATTEMPT) = Count(LEGAL_{P}_RESPONSE) + Count(LEGAL_{P}_DENY) [if supported] + Count(LEGAL_{P}_ERROR) Expanded: LEGAL_QUERY_ATTEMPT = LEGAL_QUERY_RESPONSE + LEGAL_QUERY_DENY + LEGAL_QUERY_ERROR LEGAL_DOC_ATTEMPT = LEGAL_DOC_RESPONSE + LEGAL_DOC_DENY + LEGAL_DOC_ERROR LEGAL_FACTCHECK_ATTEMPT = LEGAL_FACTCHECK_RESPONSE + LEGAL_FACTCHECK_DENY [if supported] + LEGAL_FACTCHECK_ERROR For implementations that do not support LEGAL_FACTCHECK_DENY, the invariant simplifies to ATTEMPT = RESPONSE + ERROR for Pipeline 3. Refusal conditions recorded as ERROR with deny_equivalent MUST be counted toward the invariant. Each outcome event MUST set header.causal_link.target_event_id to the originating attempt event's event_id and header.causal_link.link_type to "OUTCOME_OF", ensuring referential integrity can be verified independently of event ordering. The equality above is a summary only. Verifiers MUST apply the per-attempt linkage, uniqueness, grace-period, and scope rules in . A complete anchored batch can still contain an incomplete operation; operation-boundary records outside the selected batch may be needed.

Override Coverage and Enforcement

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.

Override Coverage Assessment +==========+============+==================================+ | 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 | +----------+------------+----------------------------------+

Interpreting Review CoverageCoverage 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.

Enforcement Level Mapping

Enforcement Level by Conformance Level +=======================+==========+=============+=============+ | 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 | +-----------------------+----------+-------------+-------------+

Enforcement Level MappingBronze 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.

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.

LAP Privacy-Preserving Fields Legal AI handles extremely sensitive data protected by professional privilege. LAP extends VAP's privacy-preserving verification with the following hashed fields:

LAP Privacy-Preserving Fields +============+=================+====================+==============+ |Original |Hash Field | Hash Method |Sensitive | |Data | | |Content | +============+=================+====================+==============+ |User query |PromptHash | SHA-256(salt || |Legal | |text | | content) |consultation | | | | |content | | | | |(privileged) | +------------+-----------------+--------------------+--------------+ |AI response |ResponseHash | SHA-256(salt || |AI-generated | |text | | content) |legal advice | +------------+-----------------+--------------------+--------------+ |Document |OutputHash | SHA-256(salt || |Generated | |output | | content) |legal | | | | |documents | +------------+-----------------+--------------------+--------------+ |Case number |CaseNumberHash | HMAC-SHA-256(salt, |Case | | | | value) |identifier | | | | |(high | | | | |specificity) | +------------+-----------------+--------------------+--------------+ |Bar number |BarNumberHash | HMAC-SHA-256(salt, |Professional | | | | value) |registration | | | | |number | +------------+-----------------+--------------------+--------------+ |Party names |PartyHash | HMAC-SHA-256(salt, |Personal | | | | value) |information of| | | | |parties | +------------+-----------------+--------------------+--------------+ |Modification|ModificationHash | SHA-256(salt || |Professional's| |detail | | content) |corrections | +------------+-----------------+--------------------+--------------+ |Factcheck |TargetContentHash| SHA-256(salt || |Content under | |content | | content) |verification | +------------+-----------------+--------------------+--------------+

Fields with low input entropy (CaseNumberHash, BarNumberHash, PartyHash) MUST use HMAC-SHA-256 with the tenant salt as key, per , to resist dictionary attacks. Fields with high input entropy (content hashes) MAY use simple salted SHA-256. Hash computation uses per-tenant salts as specified in . Third-party verifiers can confirm event existence and chain integrity without accessing privileged content. The availability of original content corresponding to these hashes depends on the current Content Retention Tier (). At Tier 1, original content is available in encrypted form. At Tier 2, it is recoverable via escrowed keys. At Tier 3, only hashes remain.

LAP Requirement MatrixAll levels require signed events, chain continuity, signed Merkle statements, policy identification, external anchors, bounded recovery, erasure evidence when used, and legal hold enforcement. The following matrix is a LAP-only summary; the detailed sections govern. Requirement Bronze Silver Gold External anchor interval <=24 hours <=24 hours <=1 hour Three-pipeline checks Optional Required Required Review coverage Optional Required Required Review enforcement minimum Level 0 Level 1 Level 1 Evidence Pack generator Optional Required Required Batch proof export Required Required Required Privacy protection Required Required Required Legal hold Required Required Required Content tiers 3 minimum 2 and 3 1, 2, and 3 Independent escrow Optional Recommended Required HSM Optional Optional Required Event retention 6 months 3 years 10 years Anchor/proof retention >=1 year >=5 years >=10 years Real-time audit API Optional Optional Required Retention minima are extended for dependent retained evidence and legal hold. Optional mechanisms, when used, MUST satisfy their applicable requirements. An implementation operating only Tier 3 cannot recover destroyed content; it MUST disclose that limitation and MUST apply legal hold before any destruction. No VAP-CORE, VAP-STANDARD, or VAP-FULL result follows automatically from this matrix.

Regulatory Context (Informative)Logging, human oversight, retention, and access control can support an organization's assessment of applicable obligations. This draft does not prescribe legal advice, determine whether a service is regulated, or establish compliance with any statute. In particular, a hash of a professional identifier does not verify the professional's license; a HUMAN_OVERRIDE event does not establish adequate review.Jurisdiction, deployment role, evidence scope, and applicable retention or erasure duties require separate assessment. The technical retention minima in this draft are design requirements, not a statement of universally applicable legal periods. A legal hold records an authorized preservation instruction; the protocol cannot determine whether an unrecorded duty exists.

Security Considerations This section describes the threat model and security considerations for VAP-LAP implementations, following the guidance in .

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.

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 Section 2.1.4) to detect log forking.

Timestamp LimitsEvent 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.

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.

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 () 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.

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 () enables verifiers to inspect specific events without accessing the full event store, reducing exposure. For privacy analysis guidance, see .

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.

Omission and Split ViewsA 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.

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.

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.

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 () mitigates this by maintaining recoverable content during periods when discovery is most likely, while the Legal Hold Protocol () prevents premature content destruction when litigation is anticipated.

Override Enforcement Circumvention Enforcement Levels 1 and 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.

Rapid Approval Gaming Users aware of the Override Latency threshold () 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.

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.

IANA Considerations

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

application/vap-evidence-pack+zip

Type name:

application

Subtype name:

vap-evidence-pack+zip

Required parameters:

None

Optional parameters:

profile (string): VAP profile identifier (e.g., "LAP", "VCP")

Encoding considerations:

binary (ZIP archive)

Security considerations:

Evidence Packs contain signed provenance data. Implementations MUST verify the pack-level signature before trusting its contents; limited parsing is necessary to locate the manifest and signature. The pack may contain privacy-sensitive metadata; access control is the responsibility of the implementation. See Section 20 of this document.

Interoperability considerations:

The internal structure follows . Implementations MUST support the manifest.json format defined in .

Published specification:

This document

Applications that use this media type:

AI audit trail systems, regulatory submission tools, third-party verification services Fragment identifier considerations: N/A

Additional information:

N/A

Contact:

AILEX LLC, info@ailex.co.jp

Author:

Shintaro Yamakawa

Change controller:

IETF

application/vap-manifest+json

Type name:

application

Subtype name:

vap-manifest+json

Required parameters:

None

Optional parameters:

None

Encoding considerations:

UTF-8 encoded JSON per

Security considerations:

The manifest is integrity-protected as part of the Evidence Pack signature. See .

Interoperability considerations:

JSON format per .

Published specification:

This document

Applications that use this media type:

AI audit trail systems

Contact:

AILEX LLC, info@ailex.co.jp

Author:

Shintaro Yamakawa

Change controller:

IETF

Profile Identifier ScopeThis 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.

Event Type ScopeThe 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.

Relationship to Other WorkSCITT defines a transparency architecture; COSE Receipts provide mechanisms for verifiable data structures. LAP defines domain records and batch commitments that can be carried using a specified service profile. Merely storing a LAP digest in a service does not demonstrate that its receipt has been verified.Distributed agent and service architectures can supply independent evidence of requests, delegations, and results. LAP does not define those communication protocols or impose requirements on other IETF work. Any future cross-protocol binding must specify authenticated identities, exact committed bytes, failure handling, and privacy boundaries.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] This document updates RFC 3161. It allows the use of ESSCertIDv2, as defined in RFC 5035, to specify the hash of a signer certificate when the hash is calculated with a function other than the Secure Hash Algorithm (SHA-1). [STANDARDS-TRACK] This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. VeritasChain Standards OrganizationFixed repository commit 81fa81e01ef9418c3fb7a02ddfc7fd72d993b6b1; CC BY 4.0. Source baseline; this LAP proposal is not an upstream endorsement. Informative References All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time. One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Government of Japan Japan Federation of Bar Associations Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. National Institute of Standards and Technology National Institute of Standards and Technology National Institute of Standards and Technology

Upstream Requirement MappingThis table identifies design correspondences, not a conformance certificate. The complete upstream assessment, profile registration, and interoperability work remain open. Upstream requirement LAP section / mechanism INT-001 canonicalization 4.2 and 5.1 / RFC 8785 INT-002 event identity 5 / UUIDv7 INT-003 event hash 4.2 / SHA-256 baseline INT-004 sequence evidence 4.2 and 5 / hash chain and sequence INT-005 non-repudiation 4.3 / every event signed INT-006 external anchor 7 / signed Merkle batch and receipt INT-007 continuity 7.1 / fallback and gap evidence INT-008 scope commitment 7.2, 7.3, 8 / count, range, limits INT-009 recovery 14.6 / bounds and human override ERASURE 11.1 / destruction evidence and hold Policy identification 5.2 / immutable policy hash TRC-005 XREF 14.7 / independent party evidence

Validation RequirementsValidators MUST enforce the field types and requirements in Section 5, reject duplicate members and wrong numeric types, recompute each event hash without changing any signed content, verify signatures against independently trusted key bindings, and verify chain and batch scope. The policy, recovery, erasure, external receipt, and per-attempt checks are distinct from syntactic validation.A conforming verifier MUST test non-power-of-two trees; wrong leaf prefixes; altered policy/count/range; missing, duplicated, reordered or substituted events; omitted recovery records; unsupported algorithms; unknown keys; invalid TSA/log receipts; absent prior batches; and missing outcome evidence. A cryptographic pass MUST NOT conceal a failed or unevaluated scope check.A full machine-readable schema and interimplementation interoperability results remain open work. The field definitions in this document are normative; no unpublished companion schema is a prerequisite for interpreting them.

Serialization and Merkle Primitive VectorsThese 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

Implementation StatusThis section follows and is to be removed before RFC publication. No independently validated conforming implementation of draft-05 is reported here. Local document checks and test vectors do not constitute implementation certification.Earlier revisions described AILEX implementations with hash-chained logs and experimental LAP features. Those reports are historical and have not been independently verified for this revision. In particular, an implementation without external anchoring cannot claim draft-05 Bronze. Product availability does not imply LAP or VAP conformance.The pinned upstream repository reports no external implementations and no accepted Evidence Packs for its framework/profile assessment as of 25 October 2026. That report has a defined upstream assessment scope and does not establish the absence of all internal implementations.

Change Log

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.

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 , which has been published since the previous revision, and replaced the unresolved "[IETF-SCITT]" citation in with the same reference.
• Updated the SCITT Reference APIs (SCRAPI) reference to its current revision.
• Added (EAT) as an informative reference for its existing mention in .
• Aligned the vap_version example values in and , and the Profile Version in , 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 and ; and the existing mentions of FIPS 203 and FIPS 204 in now cite and .
• Updated (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 ().
• 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 ().
• 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 () 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 ().
• 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 ().
• Updated FIPS 140-2/3 to FIPS 140-3 as primary requirement with transition period note ().
• Added RFC 5816 (ESSCertIDv2) as normative reference for RFC 3161 TSA SHA-256 support ().
• Specified anchor_proof structure per anchor_type with type- specific fields and verification procedures ().
• Added Completeness Invariant grace period maximum of 300 seconds with TIMEOUT_ERROR mechanism ().
• Added standardized causal_link field in header for all event types, with link_type enumeration ().
• Fixed Override Coverage metric: numerator changed to count distinct target_event_id to prevent exceeding 100%. DENY removed from denominator with rationale documented ().
• Added salt management requirements: 256-bit minimum entropy, HMAC- SHA-256 for low-entropy fields, rotation and compromise response procedures ().
• Added minimum verification API with HTTP endpoints for Silver and Gold levels ().
• 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 ().
• Expanded IANA Considerations with media type registration templates, VAP Domain Profile registry, and VAP Event Type registry per RFC 8126 ().
• Added GDPR interaction subsection addressing right-to- erasure vs. audit trail tension ().
• Added escrow custodian requirements for Tier 2 content recovery ().
• Added Relationship to Other Work section positioning VAP relative to SCITT, RATS/EAT, AIPREF, Sentinel Protocol, and ISO/IEC standards ().
• 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 ().
• Removed EIP from profile.id enumeration (undefined profile).
• Normalized all algorithm identifiers to lowercase hyphenated ASCII strings with explicit canonical mapping table (). 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 (, 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 ().
• Added Legal Hold Protocol () 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 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.

Acknowledgments The VAP Framework and LAP Profile were developed with input from: the CAP v1.0 Safe Refusal Provenance (SRP) design experience, the VCP v1.1 operational feedback, regulatory engagement from legal practitioners, and open-source community contributions. LAP v0.4 design draws from the AILEX SaaS reference implementation, the Ministry of Justice guideline on AI services and Article 72 (August 2023), the on generative AI in attorney practice (September 2025), and operational feedback from pilot law firms regarding judicial discovery and attorney oversight workflows. The authors thank the reviewers who provided detailed technical feedback on the -01 draft, particularly regarding cryptographic algorithm naming accuracy, hash computation clarity, Merkle tree construction consistency, and IANA registration completeness.