Network Working Group S. Yamakawa, Ed. Internet-Draft AILEX LLC / VeritasChain Standards Organization Intended status: Experimental 26 October 2026 Expires: 29 April 2027 Verifiable AI Provenance (VAP) Framework and Legal AI Profile (LAP) draft-ailex-vap-legal-ai-provenance-05 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 29 April 2027. Yamakawa Expires 29 April 2027 [Page 1] Internet-Draft VAP-LAP October 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope and Upstream Baseline . . . . . . . . . . . . . . . 4 1.2. Authority and Assurance Limits . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. VAP Alignment and LAP Architecture . . . . . . . . . . . . . 7 3.1. Layer Model . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Profile Status and Levels . . . . . . . . . . . . . . . . 7 4. Cryptographic Foundation . . . . . . . . . . . . . . . . . . 7 4.1. Algorithm Requirements . . . . . . . . . . . . . . . . . 7 4.2. Hash Chain Specification . . . . . . . . . . . . . . . . 9 4.3. Digital Signature Requirements . . . . . . . . . . . . . 10 4.4. Algorithm Migration . . . . . . . . . . . . . . . . . . . 11 4.4.1. Post-Quantum Planning . . . . . . . . . . . . . . . . 11 5. LAP Common Event Structure . . . . . . . . . . . . . . . . . 11 5.1. Numeric Value Encoding . . . . . . . . . . . . . . . . . 13 5.2. Compatibility and Policy Identification . . . . . . . . . 13 6. LAP Conformance Levels . . . . . . . . . . . . . . . . . . . 14 6.1. Bronze . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Silver . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Gold . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. External Anchoring . . . . . . . . . . . . . . . . . . . . . 15 7.1. Services and Continuity . . . . . . . . . . . . . . . . . 15 7.2. Signed Batch Statement and Receipt . . . . . . . . . . . 16 7.3. Merkle Tree Construction . . . . . . . . . . . . . . . . 17 8. Scoped Attempt and Outcome Consistency . . . . . . . . . . . 18 9. Evidence Pack Specification . . . . . . . . . . . . . . . . . 18 9.1. Pack Structure . . . . . . . . . . . . . . . . . . . . . 19 9.2. Pack Manifest . . . . . . . . . . . . . . . . . . . . . . 19 10. Privacy-Preserving Verification . . . . . . . . . . . . . . . 20 10.1. Salt Management Requirements . . . . . . . . . . . . . . 20 11. Retention Framework . . . . . . . . . . . . . . . . . . . . . 21 Yamakawa Expires 29 April 2027 [Page 2] Internet-Draft VAP-LAP October 2026 11.1. Privacy and Erasure . . . . . . . . . . . . . . . . . . 21 11.2. Content Retention Tiers . . . . . . . . . . . . . . . . 22 11.3. Escrow Custodian Requirements . . . . . . . . . . . . . 23 11.4. Legal Hold Protocol . . . . . . . . . . . . . . . . . . 23 11.5. Judicial Disclosure Response . . . . . . . . . . . . . . 24 12. Third-Party Verification Protocol . . . . . . . . . . . . . . 25 12.1. Minimum Verification API . . . . . . . . . . . . . . . . 26 13. Legal AI Profile Overview . . . . . . . . . . . . . . . . . . 27 13.1. Proposed LAP Profile Identity . . . . . . . . . . . . . 27 14. LAP Event Type Taxonomy . . . . . . . . . . . . . . . . . . . 27 14.1. Pipeline 1: Legal Query . . . . . . . . . . . . . . . . 27 14.2. Pipeline 2: Document Generation . . . . . . . . . . . . 27 14.3. Pipeline 3: Fact Check . . . . . . . . . . . . . . . . . 28 14.4. Cross-Cutting: Human Override . . . . . . . . . . . . . 28 14.5. Retention and Enforcement Events . . . . . . . . . . . . 29 14.6. Recovery and Assurance Administration . . . . . . . . . 30 14.7. Optional Cross-Party References . . . . . . . . . . . . 30 15. LAP Completeness Invariant . . . . . . . . . . . . . . . . . 31 16. Override Coverage and Enforcement . . . . . . . . . . . . . . 32 16.1. Override Coverage Metric . . . . . . . . . . . . . . . . 32 16.2. Interpreting Review Coverage . . . . . . . . . . . . . . 33 16.3. Enforcement Level Mapping . . . . . . . . . . . . . . . 33 16.4. Enforcement Level Mapping . . . . . . . . . . . . . . . 34 16.5. Structural Limitation Acknowledgment . . . . . . . . . . 34 17. LAP Privacy-Preserving Fields . . . . . . . . . . . . . . . . 34 18. LAP Requirement Matrix . . . . . . . . . . . . . . . . . . . 36 19. Regulatory Context (Informative) . . . . . . . . . . . . . . 36 20. Security Considerations . . . . . . . . . . . . . . . . . . . 37 20.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 37 20.2. Hash Chain Manipulation . . . . . . . . . . . . . . . . 37 20.3. Timestamp Limits . . . . . . . . . . . . . . . . . . . . 37 20.4. Insider Threats . . . . . . . . . . . . . . . . . . . . 38 20.5. Key Compromise . . . . . . . . . . . . . . . . . . . . . 38 20.6. Privacy Leakage . . . . . . . . . . . . . . . . . . . . 39 20.7. Availability Attacks . . . . . . . . . . . . . . . . . . 39 20.8. Omission and Split Views . . . . . . . . . . . . . . . . 39 20.9. Selective Disclosure Attacks . . . . . . . . . . . . . . 39 20.10. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 40 20.11. Content Retention and Discovery Risk . . . . . . . . . . 40 20.12. Override Enforcement Circumvention . . . . . . . . . . . 40 20.13. Rapid Approval Gaming . . . . . . . . . . . . . . . . . 40 20.14. Legal Hold Integrity . . . . . . . . . . . . . . . . . . 40 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 21.1. Media Type Registration . . . . . . . . . . . . . . . . 41 21.1.1. application/vap-evidence-pack+zip . . . . . . . . . 41 21.1.2. application/vap-manifest+json . . . . . . . . . . . 42 21.2. Profile Identifier Scope . . . . . . . . . . . . . . . . 43 21.3. Event Type Scope . . . . . . . . . . . . . . . . . . . . 43 Yamakawa Expires 29 April 2027 [Page 3] Internet-Draft VAP-LAP October 2026 22. Relationship to Other Work . . . . . . . . . . . . . . . . . 43 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 23.1. Normative References . . . . . . . . . . . . . . . . . . 43 23.2. Informative References . . . . . . . . . . . . . . . . . 45 Appendix A. Upstream Requirement Mapping . . . . . . . . . . . . 46 Appendix B. Validation Requirements . . . . . . . . . . . . . . 46 B.1. Serialization and Merkle Primitive Vectors . . . . . . . 47 Appendix C. Implementation Status . . . . . . . . . . . . . . . 47 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 48 D.1. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 48 D.2. Historical Revision Notes . . . . . . . . . . . . . . . . 48 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction Legal 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. 1.1. Scope and Upstream Baseline LAP addresses legal consultation, document generation, and fact checking. The upstream baseline is VSO-VAP-SPEC-001, VAP v1.2.0 Draft 3, at repository commit 81fa81e01ef9418c3fb7a02ddfc7fd72d993b6b1 [VAP12]. This immutable reference includes the October 2026 integrity clarifications. Later changes require explicit review and a new LAP revision. The upstream specification is maintained by VeritasChain Standards Organization and published under CC BY 4.0. LAP is an independently proposed domain profile; this document does not assert upstream registration, endorsement, or certification. References to other profiles are descriptive only. 1.2. Authority and Assurance Limits The requirements here govern the LAP wire format defined here. They do not override the VAP specification. Differences are documented in Section 5.2. A claim of VAP conformance requires a separate assessment against the pinned upstream requirements; LAP conformance alone is insufficient. Yamakawa Expires 29 April 2027 [Page 4] Internet-Draft VAP-LAP October 2026 Signed records establish integrity and attributable statements under stated trust assumptions. They do not establish factual truth, legal correctness, safety, fairness, regulatory compliance, admissibility, or adequacy of professional review. Missing capture before signing and anchoring remains a distinct risk. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.1. Terminology VAP Verifiable AI Provenance Framework, maintained upstream as described in VAP12. Profile A domain-specific instantiation of VAP (e.g., VCP for finance, CAP for content, LAP for legal). LAP Legal AI Profile - the judicial AI domain profile defined in this document. Provenance Cryptographically verifiable record of data origin, derivation, and history. Completeness Invariant A scoped consistency check over captured attempts and outcomes. Passing it is not proof that all real- world activity was captured. Evidence Pack A self-contained, signed package of provenance events intended for third-party examination within a declared scope. External Anchor An external service receipt binding a signed batch statement commitment to an independently verifiable service record. Human Override An event recording a human professional's review, approval, modification, or rejection of an AI-generated output. Override Coverage The ratio of AI outputs reviewed by a human Yamakawa Expires 29 April 2027 [Page 5] Internet-Draft VAP-LAP October 2026 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 Yamakawa Expires 29 April 2027 [Page 6] Internet-Draft VAP-LAP October 2026 a provenance profile that restrict, extend, or refine the VAP common event structure and completeness invariant for a particular regulatory or professional context. 3. VAP Alignment and LAP Architecture 3.1. Layer Model The upstream framework has four common assurance layers: Integrity, Provenance, Traceability, and Accountability; the domain profile supplies domain-specific rules. LAP applies these layers through event hashing and signatures, actor/input/action/outcome records, trace and causal identifiers, and identified operators and approvers. Shared mechanisms include Merkle trees, external anchors, scope commitments, bounded recovery, erasure records, and evidence packages. Their mandatory LAP requirements are defined below. 3.2. Profile Status and Levels LAP is proposed, not listed as a registered profile in the pinned upstream registry. The labels Bronze, Silver, and Gold in this document belong only to LAP. Upstream Core, Standard, and Full are separate requirement sets. No one-to-one equivalence is asserted. 4. Cryptographic Foundation 4.1. Algorithm Requirements All VAP-conformant implementations MUST support the primary algorithms listed below. Implementations SHOULD support at least one alternative algorithm in each category for migration purposes. Post- quantum algorithms are listed for future migration readiness and are currently OPTIONAL. Yamakawa Expires 29 April 2027 [Page 7] Internet-Draft VAP-LAP October 2026 +============+================+===================+==============+ | 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]) | +------------+----------------+-------------------+--------------+ Figure 1: Required Cryptographic Algorithms Note: The Post-Quantum signature algorithm ML-DSA-65 (formerly known as CRYSTALS-Dilithium, renamed upon FIPS 204 [FIPS204] standardization in August 2024) provides security equivalent to AES- 192. This parameter set was selected as a balance between signature size (3,309 bytes) and security margin for legal audit trails requiring multi-decade retention. ML-DSA-44 (AES-128 equivalent) was considered insufficient for the intended retention periods; ML-DSA-87 (AES-256 equivalent) imposes significantly larger signatures (4,627 bytes) with marginal practical benefit for this use case. Note: ML-KEM-1024 (formerly known as CRYSTALS-Kyber, renamed upon FIPS 203 [FIPS203] standardization in August 2024) is a key encapsulation mechanism (KEM), not an encryption algorithm. It is listed separately from symmetric encryption because KEM and symmetric encryption serve different roles: KEM establishes shared secrets for key agreement, while AES-256-GCM provides authenticated encryption of content. Implementations MUST include algorithm identifiers in all cryptographic fields. The following table defines the canonical algorithm identifiers used in field values and wire-format prefixes: Yamakawa Expires 29 April 2027 [Page 8] Internet-Draft VAP-LAP October 2026 +===========+========================+==================+===========+ | 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] | +-----------+------------------------+------------------+-----------+ Figure 2: Canonical Algorithm Identifiers All algorithm identifiers MUST be lowercase ASCII strings with hyphens as separators. The field value and wire prefix use the same string (the wire prefix appends a colon as delimiter). Implementations MUST reject non-canonical algorithm identifiers and MUST produce lowercase output. These identifiers enable crypto agility and algorithm migration as specified in Section 4.4. 4.2. Hash Chain Specification Events MUST be linked in a hash chain where each event's hash includes the hash of the preceding event. The Hash Input is computed by removing the following fields from the event before canonicalization: * security.event_hash * security.signature Yamakawa Expires 29 April 2027 [Page 9] Internet-Draft VAP-LAP October 2026 The remaining fields (including security.hash_algo, security.sign_algo, and security.signer_id) are retained in the hash input. This explicit exclusion list prevents circular references (event_hash cannot be included in its own computation) and ensures that implementations agree on the hash input. The computation proceeds as follows: HashInput[n] = Event[n] with {security.event_hash, security.signature} removed EventHash[n] = HashAlgo(JCS-Canonicalize(HashInput[n])) where: Event[n].header.prev_hash = EventHash[n-1] Event[0].header.prev_hash = null (genesis event) HashAlgo is the algorithm specified in security.hash_algo JCS-Canonicalize follows RFC 8785 Canonicalization MUST follow [RFC8785] (JSON Canonicalization Scheme). Chain integrity verification MUST confirm: 1. Each event's EventHash matches the recomputed hash over the Hash Input. 2. Each event's prev_hash matches the preceding event's EventHash. 3. The genesis event has a null prev_hash. 4. The hash_algo specified in each event is a supported algorithm. 4.3. Digital Signature Requirements Every event MUST be signed. The signature MUST be computed over the EventHash bytes (not over the raw event): Signature = SignAlgo.Sign(PrivateKey, EventHash_bytes) The signature MUST be encoded as follows: security.signature = sign_algo_id ":" Base64url(Signature_bytes) where sign_algo_id is the canonical algorithm identifier from Figure 2 matching the security.sign_algo field (e.g., "ed25519", "ecdsa-p256"), and Base64url encoding follows Section 5 of [RFC4648] (URL-safe alphabet, no padding). Yamakawa Expires 29 April 2027 [Page 10] Internet-Draft VAP-LAP October 2026 The primary mandatory-to-implement (MTI) signature algorithm is Ed25519 [RFC8032]. Implementations MUST support Ed25519 and SHOULD support at least one additional algorithm from Figure 1 for migration purposes. 4.4. Algorithm Migration Algorithm migration follows the principles of [RFC7696]. This revision requires SHA-256 and Ed25519 interoperability for event and batch commitments. Other algorithm support in the tables is preparatory: a deployment MUST NOT claim interoperable use without a versioned specification of key, signature, and transcript encoding. Unsupported algorithms MUST be reported as unverifiable. A key change MUST be logged and authorized under the existing trust policy. Historical events MUST NOT be rewritten or re-signed in place. Supplemental signatures, if used, MUST be detached attestations over the original event_hash with explicit algorithm and signer identifiers; they MUST NOT be inserted into the old event. Re-anchoring preserves the original proofs and does not retrospectively repair a compromised signature. 4.4.1. Post-Quantum Planning Long-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 [FIPS204] and [RFC9794] for related mechanisms and terminology. 5. LAP Common Event Structure Every 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. Yamakawa Expires 29 April 2027 [Page 11] Internet-Draft VAP-LAP October 2026 { "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:"}, "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:", "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:", "hash_algo": "sha-256", "sign_algo": "ed25519", "signer_id": "key identifier", "signature": "ed25519:"} } event_id, chain_id, and trace_id MUST be UUIDv7 values per [RFC9562]. 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 [RFC3339] 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 Yamakawa Expires 29 April 2027 [Page 12] Internet-Draft VAP-LAP October 2026 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. 5.1. Numeric Value Encoding All numeric values in LAP JSON events, policies, anchor records, proofs, and manifests MUST be strings. Non-negative integer fields, including sequence, counts, indexes, and limits, MUST match 0|[1-9][0-9]*. Signed integers, if needed in an extension, MUST use an optional leading minus and MUST NOT use negative zero. Decimal fields MUST use a decimal point with digits on both sides, no exponent, no leading plus, no unnecessary leading zeros, and no trailing fractional zeros; integral values use the integer form. Booleans and null retain their JSON types. These rules apply before hashing. JCS [RFC8785] MUST NOT convert types, normalize Unicode, or rewrite numeric strings. A receiver MUST reject a wrong type rather than silently repair signed data. The rules apply to the LAP JSON wrapper, not binary data encoded inside a receipt or quoted third-party documents. 5.2. Compatibility and Policy Identification This revision is not byte-compatible with draft-04. It replaces the former vap_version value 1.4, which was not the upstream VAP v1.2 version, and advances the LAP profile version from 0.5.0 to 0.6.0. Old records MUST retain their original bytes and schema identity. Migration MUST start a new chain with a signed migration record referencing the last old event hash and available old anchor. Old proofs MUST NOT be relabeled as draft-05 proofs. The LAP fields header.timestamp and header.prev_hash correspond conceptually to upstream header.timestamp_iso and security.prev_hash. LAP adds explicit sequence and schema_id. An adapter MUST preserve the original signed bytes and disclose mappings; renaming fields produces a different signed object. No generic upstream JSON validator compatibility is claimed. Every event MUST bind a policy_id and policy_hash. policy_id MUST use reverse-domain notation followed by a colon and a local identifier. policy_hash is SHA-256 of the UTF-8 JCS bytes of the immutable policy document. The policy document MUST contain: issuer, policy_id, effective_from, expires_at (timestamp or null), lap_level (Bronze, Silver, or Gold), the pinned vap_baseline commit, vap_conformance (UNASSESSED, VAP-CORE, VAP-STANDARD, or VAP-FULL), registration_policy (issuer and policy_uri), verification_depth, Yamakawa Expires 29 April 2027 [Page 13] Internet-Draft VAP-LAP October 2026 anchor_interval_seconds, fallback_endpoint, max_failover_seconds, and recovery_bounds. verification_depth MUST declare event_signature, hash_chain, merkle_tree, and external_anchor as true. A non- UNASSESSED VAP claim MUST identify a separate assessment and evidence URI. Neither this field nor its signature makes that claim true. Policy documents MUST be included in evidence packages and retained with anchors. Policy changes require a new hash and a POLICY_CHANGE event binding old and new hashes. A policy change MUST close the existing batch. Limits MUST NOT be relaxed retroactively. schema_id values in this document are opaque identifiers defined here, not registered URN namespaces. Optional extensions MUST declare any validation-critical member names in a critical_extensions array of strings at the event top level. Unknown listed members prevent a positive semantic validation result. The array itself is included in Hash Input. 6. LAP Conformance Levels Each 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. 6.1. Bronze Bronze MUST implement the event structure, SHA-256 hashing, Ed25519 support, an unbroken hash chain, per-event signatures, policy binding, signed Merkle batch statements, and verified external anchoring at intervals no longer than 86400 seconds. It MUST preserve events for at least six months and anchors, policies, proofs, and public verification material for at least one year and for as long as any dependent retained event requires verification. Legal hold, recovery, erasure, and anchoring-failure records are mandatory when applicable. Bronze MUST export the records and proofs needed to verify a declared batch, even if it has no online audit API. 6.2. Silver Silver additionally MUST implement the three-pipeline consistency checks, Evidence Pack generation, privacy protection, override coverage reporting, Level 1 review warnings, and the audit API. LAP Silver events MUST be retained for at least three years; anchors and verification material for at least five years and for as long as dependent records remain retained. External anchoring remains mandatory at most every 86400 seconds. Yamakawa Expires 29 April 2027 [Page 14] Internet-Draft VAP-LAP October 2026 6.3. Gold Gold additionally MUST anchor at intervals no longer than 3600 seconds, use a transparency log as one anchor service, use a FIPS 140-3 Level 2 or higher validated HSM for signing keys, provide real- time audit access, preserve evidence during incidents, maintain at least two geographic regions, support crypto-shredding subject to legal hold, and obtain an annual third-party audit. LAP Gold events and anchor material MUST be retained for at least ten years. A 24-hour incident-response capability is REQUIRED. These operational requirements are not proof that an implementation has obtained a certification. 7. External Anchoring Every 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. 7.1. Services and Continuity The baseline service is an RFC 3161 TSA [RFC3161] supporting ESSCertIDv2 [RFC5816]. A transparency service with authenticated receipts, inclusion verification, and a documented append-only trust model MAY be used instead. Gold MUST include a transparency service. SCITT [RFC9943] and COSE Merkle receipts [RFC9942] are relevant mechanisms; their use does not by itself establish LAP conformance. Blockchain-only proofs do not satisfy this draft's mandatory baseline. The policy MUST identify a primary and a distinct fallback service, trust anchors, verification rules, and a maximum failover window. The maximum MUST NOT exceed 2592000 seconds (30 days). Normal successful anchor intervals MUST NOT exceed the level's limit. On failure, the operator MUST retain the signed batch, retry and use the fallback within that window, and report the period as degraded. A failover window does not extend the normal interval or authorize a conformance claim for a missed deadline. A gap exceeding twice the configured interval MUST produce an ANCHOR_GAP event, including last_successful_anchor_id, gap_start, detection_time, failed_endpoints, and retry evidence. A successful fallback MUST produce an ANCHOR_RECOVERED event linking the gap and receipt. Locally retained receipts MUST remain usable independently of the service's later availability. No failure or recovery event may be excluded from subsequent batches. Yamakawa Expires 29 April 2027 [Page 15] Internet-Draft VAP-LAP October 2026 For a chain with no new events, a separately signed heartbeat statement MAY report the unchanged last anchor and observation time. It MUST NOT invent an event or claim inclusion of an empty batch. Policy-defined monitoring MUST distinguish an idle chain from an unavailable producer. 7.2. Signed Batch Statement and Receipt A batch MUST cover a non-empty, consecutive range of one chain under one policy hash. Its statement MUST contain exactly the fields in the following layout; all counters are strings. An epoch is not inferred from a mutable service response. { "schema_id": "ailex-lap-anchor-05", "anchor_id": "UUIDv7", "chain_id": "UUIDv7", "policy_id": "reverse.domain:local-id", "policy_hash": "sha-256:", "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:", "last_event_hash": "sha-256:", "merkle_root": "sha-256:", "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. Yamakawa Expires 29 April 2027 [Page 16] Internet-Draft VAP-LAP October 2026 An AnchorRecord contains signed_statement and a receipts array. Each receipt MUST identify anchor_type, service_endpoint, service_profile, commitment_hash, and proof. commitment_hash MUST match the signed_statement commitment. Receipts and service metadata are outside signed_statement to avoid circularity. Changing a receipt cannot change the anchored statement. The signature key MUST be bound to an authorized operator through an independently configured trust policy, not merely through a supplied key file. For RFC3161, proof MUST include the DER TimeStampToken encoded in unpadded base64url, and the TSA certificate chain or sufficient references to obtain it. The verifier MUST check messageImprint.algorithm is SHA-256, messageImprint.hashedMessage equals the raw commitment bytes, the token signature, certificate purpose and path, applicable revocation evidence, and the TSA policy against configured trust. A displayed anchor_timestamp is not authoritative; use the verified token genTime. For a transparency receipt, service_profile MUST name the exact immutable protocol version and statement-to-log-leaf encoding. proof MUST carry the authenticated checkpoint or signed receipt, inclusion path, leaf index, and tree size required by that protocol. Verification MUST bind the exact commitment to the authenticated checkpoint and validate the log key and trust policy. A bare sibling-hash array is insufficient. For SCITT, the binding MUST follow its Signed Statement and Receipt model. The LAP Merkle tree and the service tree are distinct and MUST NOT be conflated. Unsupported service profiles yield an unverifiable result, not a pass. A batch verifier MUST check operator signature, policy validity, count equals last_sequence minus first_sequence plus one, first and last identifiers and hashes, chain and policy identity for every event, sequence continuity, previous batch linkage where available, and the external receipt. Missing surrounding batches MUST be disclosed as a scope limitation. Receipt validation failure MUST be reported separately from event signature validation. 7.3. Merkle Tree Construction The batch tree uses SHA-256 with the domain separation and unbalanced-tree recursion in Section 2.1 of [RFC6962]. The same tree construction is retained in [RFC9162]. Each d(i) is the UTF-8 JCS serialization of the complete signed event, including event_hash and signature. Events are ordered by numeric sequence, not lexicographic string order. Yamakawa Expires 29 April 2027 [Page 17] Internet-Draft VAP-LAP October 2026 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. 8. Scoped Attempt and Outcome Consistency For 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. 9. Evidence Pack Specification An Evidence Pack is a self-contained, signed package of provenance events intended for third-party examination within a declared scope. Yamakawa Expires 29 April 2027 [Page 18] Internet-Draft VAP-LAP October 2026 9.1. Pack Structure An Evidence Pack MUST contain: * manifest.json: Pack metadata and integrity information * events/: Event batches (max 10,000 events per file) * anchors/: External anchor records * merkle/: Merkle tree structure and selective disclosure proofs * keys/: Public keys for signature verification * signatures/: Pack-level signature The Evidence Pack SHOULD be packaged as a ZIP archive with the media type application/vap-evidence-pack+zip (see Section 21.1). The manifest MUST use the media type application/vap-manifest+json. 9.2. Pack Manifest manifest.json MUST be a JCS-compatible object containing schema_id ailex-lap-manifest-05, pack_id (UUIDv7), generated_at, profile, lap_level, policies, scope, files, statistics, verification, retention_status, and enforcement_metrics. All counters use decimal strings. policies lists each policy_id, policy_hash, and included policy path. scope MUST identify chains, sequence ranges, batch commitments, time range, and whether disclosure is complete or partial. files MUST list every packaged data file with its relative path, byte size, and SHA-256 digest. It MUST NOT list manifest.json or the detached pack signature. Paths MUST be unique, relative, and free of traversal components; verifiers MUST reject unlisted data files, duplicate archive names, and mismatched digests. A pack signature is Ed25519 over SHA-256 of the JCS manifest bytes, stored in signatures/ manifest.json with signer_id and signature. The signature file is excluded from the manifest to avoid circularity. Public keys in the pack are candidate verification material, not self-authenticating trust anchors. The pack MUST include signed events, policy documents, AnchorRecords, inclusion or full-batch reconstruction data, key bindings, and applicable recovery, erasure, legal hold, policy-change, and gap records. A selective pack MUST identify undisclosed ranges. The pack signature does not replace event or external receipt verification. Yamakawa Expires 29 April 2027 [Page 19] Internet-Draft VAP-LAP October 2026 verification MUST give separate results and evidence references for schema, event signatures, chains, batch roots, external receipts, policy, per-attempt consistency, and recovery/erasure controls. Each result MUST state whether it passed, failed, or was not evaluated and why. These are LAP report statuses, not upstream framework conformance labels. statistics MUST contain total_events and events_by_type. Retention and enforcement metrics MUST report unknown values explicitly instead of substituting zero. Bronze packs, if generated, follow the same format. 10. 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. 10.1. Salt Management Requirements Per-tenant salts MUST meet the following requirements: * Minimum entropy: 256 bits (32 bytes), generated using a cryptographically secure random number generator. * Uniqueness: Each tenant MUST have a distinct salt. Implementations MUST NOT share salts across tenants. * Storage: Salts MUST be stored separately from the hashed data and protected with access controls equivalent to signing keys. * Rotation: Salts SHOULD be rotated at least annually. Upon rotation, previously hashed values are NOT re-hashed; the provenance chain records the salt epoch in effect at each event's timestamp. Yamakawa Expires 29 April 2027 [Page 20] Internet-Draft VAP-LAP October 2026 For fields with low input entropy (such as bar registration numbers, which occupy a bounded numeric space), plain SHA-256(salt || value) is vulnerable to dictionary attack if the salt is compromised. For such fields, implementations MUST use HMAC-SHA-256 with the tenant salt as key: BarNumberHash = "sha-256:" || hex(HMAC-SHA-256(tenant_salt, bar_number_bytes)) In the event of salt compromise, the implementation MUST: 1. Generate a new salt immediately. 2. Record a SALT_ROTATION event in the provenance chain. 3. Assess and document the exposure window (events between last rotation and compromise discovery). 4. Notify affected tenants per applicable data breach notification requirements. 11. Retention Framework The LAP minima are defined in Section 6. 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 Section 18 for LAP extensions). 11.1. Privacy and Erasure Crypto-shredding can limit access to encrypted content while preserving audit commitments. It does not by itself establish compliance with privacy law or remove all copies. An active legal hold or applicable retention duty MUST block destruction of the affected content keys. The operator MUST record the retention_exemption basis, approving actor, affected scope, and review date when a duty overrides a requested erasure. Yamakawa Expires 29 April 2027 [Page 21] Internet-Draft VAP-LAP October 2026 Every completed destruction MUST generate an ERASURE event in the ordinary signed, chained, and anchored stream. domain_payload MUST include target_event_ids or an authenticated range manifest, reason, operator_id, and key_destruction_proof. The proof MUST identify the destroyed key identifiers, key manager, destruction time, and a signed destruction attestation or its digest with retrievable protected evidence. It MUST state residual backups or escrow copies and the evidence limits; a local deletion acknowledgment is not proof of universal deletion. ERASURE MUST NOT rewrite prior signed bytes or remove hashes from an existing tree. Legal hold checks and authorization MUST precede destruction. A rejected or deferred request MUST be recorded as ERASURE_DEFERRED with retention_exemption, without pretending that destruction occurred. Tier changes that destroy keys require both the transition record and the linked ERASURE record. Legal adequacy remains a jurisdiction-specific determination. 11.2. Content Retention Tiers Implementations face a tension between privacy-preserving verification (which favors early deletion of sensitive content) and legal discovery obligations (which may require content disclosure). To address this, LAP defines three content retention tiers that domain profiles MAY adopt: Tier 1 - Full Content Retention All event content (inputs, outputs, documents) is retained in encrypted form alongside provenance hashes. Duration: configurable per tenant. Encryption MUST use AES-256-GCM or ChaCha20-Poly1305 with per-tenant keys. Tier 2 - Recoverable Hash Retention Original content is deleted but a content recovery key is escrowed with a designated custodian. The escrowed key enables re-association of content from encrypted backups if a legal hold or disclosure order is triggered. Duration: from end of Tier 1 to the applicable retention period endpoint. See Section 11.3 for custodian requirements. Tier 3 - Hash-Only Retention Only provenance hashes remain. Content is cryptographically unrecoverable (crypto-shredding complete). Duration: remainder of the retention period. Transition from Tier 1 to Tier 2 MUST NOT occur while any Legal Hold is active for the affected events. Transition from Tier 2 to Tier 3 MUST NOT occur while any Legal Hold is active. Yamakawa Expires 29 April 2027 [Page 22] Internet-Draft VAP-LAP October 2026 Implementations MUST log all tier transitions as RETENTION_TIER_CHANGE events in the provenance chain. 11.3. Escrow Custodian Requirements Tier 2 escrow custodians MUST satisfy the following: * The custodian MUST be organizationally independent from the VAP implementation operator (i.e., the entity that generates and signs provenance events). * Key escrow operations (deposit, retrieval, destruction) MUST each generate a provenance event in the custodian's own audit log. * Escrow keys MUST be encrypted at rest using the custodian's own key management infrastructure. * Key granularity: implementations SHOULD use per-case or per-tenant escrow keys rather than a single global key, to limit the blast radius of any single key compromise. * Recovery execution MUST require dual authorization: one from the requesting party (e.g., the tenant attorney) and one from the custodian. A CONTENT_RECOVERY_EXECUTED event MUST be logged upon successful recovery, including: hold_id, recovered_event_range, recovered_by (actor hash), custodian_id, and court_order_reference_hash (if applicable). 11.4. Legal Hold Protocol A Legal Hold freezes the current retention tier for all events within scope, preventing content deletion or tier transition. Legal Hold triggers: 1. Court Order: Judicial order for evidence preservation. 2. Regulatory Investigation: Government regulatory action. 3. Litigation Hold: Reasonably anticipated litigation. 4. Professional Body Inquiry: Investigation by a professional regulatory body (e.g., bar association). 5. Disciplinary Proceedings: Professional disciplinary matters. Yamakawa Expires 29 April 2027 [Page 23] Internet-Draft VAP-LAP October 2026 When a Legal Hold is activated: 1. All events within scope MUST be frozen at their current retention tier (Tier 1 or Tier 2). 2. A LEGAL_HOLD_ACTIVATED event MUST be recorded in the provenance chain, including: hold_id (UUIDv7), hold_trigger (enumerated trigger type), scope (event time range or case identifiers), activated_by (actor identity hash), and activation_timestamp ([RFC3339]). 3. Tier transitions for in-scope events MUST be blocked until a corresponding LEGAL_HOLD_RELEASED event is recorded. 4. The Legal Hold itself MUST be included in Evidence Packs generated during the hold period. Legal Hold activation MUST be available at Bronze level. Automated Legal Hold detection (e.g., triggered by court filing notifications or regulatory inquiry receipt) is RECOMMENDED at Gold level. 11.5. Judicial Disclosure Response When a court or regulatory body orders full content disclosure for specific events, the response depends on the current retention tier: Events at Tier 1 Content is available in encrypted form and can be disclosed subject to appropriate access controls and professional review. Events at Tier 2 Content recovery key is retrieved from escrow per Section 11.3. Content is reconstructed from encrypted backups. A CONTENT_RECOVERY_EXECUTED event MUST be logged in the provenance chain. Events at Tier 3 Content is cryptographically unrecoverable. The implementation MUST provide: 1. Hash chain integrity proof demonstrating unbroken provenance. 2. Tier transition log showing when and why content was deleted. 3. Certification that no Legal Hold was active at the time of deletion. Yamakawa Expires 29 April 2027 [Page 24] Internet-Draft VAP-LAP October 2026 4. Statistical metadata (token counts, timestamps, event types) that remains available. This three-tier approach enables implementations to demonstrate to judicial authorities that content deletion followed a documented, auditable process rather than constituting potential evidence spoliation. NOTE: The adequacy of hash-only evidence for specific judicial proceedings is a jurisdiction-specific legal determination outside the scope of this specification. This framework provides the maximum available technical evidence in each retention tier. 12. 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. Yamakawa Expires 29 April 2027 [Page 25] Internet-Draft VAP-LAP October 2026 12.1. Minimum Verification API Silver and Gold level implementations that expose a third-party verification endpoint MUST support at minimum the following HTTP endpoints. All responses MUST use Content-Type application/json and MUST include appropriate authentication (e.g., Bearer token, mutual TLS). GET /vap/v1/anchors?from={RFC3339}&to={RFC3339} Returns anchor records for the specified time range. Response: JSON array of Anchor Record objects per Section 7.2. REQUIRED for Silver+. All numeric response members MUST use the decimal string encoding of Section 5.1. GET /vap/v1/chain/verify?from={RFC3339}&to={RFC3339} Performs and returns chain integrity verification results for the specified time range. Response: JSON object with fields: chain_valid (boolean), events_verified (decimal string), first_event_id, last_event_id, errors (array of {event_id, error_type, detail}). REQUIRED for Silver+. All numeric response members MUST use the decimal string encoding of Section 5.1. GET /vap/v1/completeness?from={RFC3339}&to={RFC3339} Returns completeness invariant verification for the time range. Response: JSON object with fields: invariant_valid (boolean), grace_period_seconds (decimal string), pipelines (array of {pipeline_id, attempts, outcomes, valid}). REQUIRED for Silver+. All numeric response members MUST use the decimal string encoding of Section 5.1. GET /vap/v1/events/{event_id}/proof Returns Merkle inclusion proof for a specific event. Response: JSON object with fields: event_id, anchor_id, merkle_root, inclusion_proof (array of Base64url sibling hashes), leaf_index, tree_size. REQUIRED for Silver+. GET /vap/v1/events/stream (WebSocket or SSE) Real-time event stream for live monitoring. REQUIRED for Gold only. Yamakawa Expires 29 April 2027 [Page 26] Internet-Draft VAP-LAP October 2026 Error responses MUST use standard HTTP status codes (400 for malformed requests, 401/403 for authentication/authorization failures, 404 for unknown resources, 500 for server errors) with a JSON body containing "error" (string code) and "detail" (human- readable description). 13. Legal AI Profile Overview LAP 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. 13.1. Proposed LAP Profile Identity This revision uses profile.id LAP and profile.version 0.6.0. The domain is Legal AI / LegalTech. The schema identity is ailex-lap- event-05. These are identifiers defined by this draft, not a statement of IANA allocation or upstream profile registration. Framework-level mapping remains subject to independent assessment. 14. LAP Event Type Taxonomy LAP defines three functional pipelines, one cross-cutting control event type, and administrative event types for retention and enforcement management: 14.1. Pipeline 1: Legal Query AI-powered legal consultation: * LEGAL_QUERY_ATTEMPT: Question submission to AI * LEGAL_QUERY_RESPONSE: AI response generated successfully * LEGAL_QUERY_DENY: Response refused (content filter, unauthorized role) * LEGAL_QUERY_ERROR: System error (API failure, timeout) 14.2. Pipeline 2: Document Generation AI-assisted legal document drafting: * LEGAL_DOC_ATTEMPT: Document generation request Yamakawa Expires 29 April 2027 [Page 27] Internet-Draft VAP-LAP October 2026 * LEGAL_DOC_RESPONSE: Document generated successfully * LEGAL_DOC_DENY: Generation refused (insufficient consent, unauthorized) * LEGAL_DOC_ERROR: System error (API failure, parse error) 14.3. Pipeline 3: Fact Check AI-powered legal fact verification: * LEGAL_FACTCHECK_ATTEMPT: Fact-check request * LEGAL_FACTCHECK_RESPONSE: Fact-check completed * LEGAL_FACTCHECK_DENY: Fact-check refused (OPTIONAL) * LEGAL_FACTCHECK_ERROR: System error Implementations MAY define LEGAL_FACTCHECK_DENY for cases where a fact-check request is refused due to rate limiting, insufficient permissions, or consent constraints. The deny_reason field SHOULD distinguish these from system errors. If an implementation does not support LEGAL_FACTCHECK_DENY, refusal conditions MUST be recorded as LEGAL_FACTCHECK_ERROR with a deny_equivalent indicator set to true in the error detail, ensuring the Completeness Invariant is maintained. 14.4. Cross-Cutting: Human Override HUMAN_OVERRIDE events record an attorney's review of any AI output: * APPROVE: Attorney confirms AI output without modification * MODIFY: Attorney edits AI output (modification hash recorded) * REJECT: Attorney rejects AI output entirely HUMAN_OVERRIDE events MUST set header.causal_link.target_event_id to the target outcome event's identifier and header.causal_link.link_type to "OVERRIDE_OF". The event MUST also include the attorney's identity (bar number hash), override type, and optional modification details in the domain_payload. Yamakawa Expires 29 April 2027 [Page 28] Internet-Draft VAP-LAP October 2026 14.5. Retention and Enforcement Events LAP defines additional event types for retention management and override enforcement: RETENTION_TIER_CHANGE Records transitions between content retention tiers. Fields: previous_tier, new_tier, affected_event_range, reason, authorized_by. LEGAL_HOLD_ACTIVATED Records activation of a legal hold. Fields: hold_id, hold_trigger, scope, activated_by. LEGAL_HOLD_RELEASED Records release of a legal hold. Fields: hold_id, released_by, release_reason. CONTENT_RECOVERY_EXECUTED Records recovery of content from Tier 2 escrow. Fields: hold_id, recovered_event_range, recovered_by, custodian_id, court_order_reference_hash. REVIEW_WARNING_ACKNOWLEDGED Records that an attorney acknowledged an unreviewed-output warning before proceeding with export. Fields: target_event_id, warning_type, acknowledged_by. REVIEW_GATE_BLOCKED Records that an export attempt was blocked due to missing HUMAN_OVERRIDE. Fields: target_event_id, document_type, blocked_action. REVIEW_GATE_OVERRIDE Records that an attorney bypassed a review gate with explicit justification. Fields: target_event_id, override_reason, overridden_by. SALT_ROTATION Records rotation of tenant privacy salt. Fields: previous_salt_epoch, new_salt_epoch, rotated_by, reason. These events are NOT part of the three-pipeline Completeness Invariant (they are control and administrative events, similar to HUMAN_OVERRIDE). However, they MUST be included in the hash chain and signed. Yamakawa Expires 29 April 2027 [Page 29] Internet-Draft VAP-LAP October 2026 14.6. Recovery and Assurance Administration Additional event types are RECOVERY, ANCHOR_GAP, ANCHOR_RECOVERED, ERASURE, ERASURE_DEFERRED, POLICY_CHANGE, MIGRATION, XREF_OBSERVATION, and LATE_RESULT. They are signed, chained, and anchored like all other events and are outside terminal outcome counts. RECOVERY means an operation affecting interpretation of a broken sequence, not recovery of encrypted content under Section 11. For every level, the default automatic SKIP bound is zero events, automatic MERGE bound is zero source chains, and automatic CHECKPOINT bound is zero unverified events. Automatic REBUILD is permitted only when all original signed event bytes and their validated anchor receipts are available: the bound is one already committed batch per operation and one such operation per chain per 86400 seconds. It MUST preserve all bytes, IDs, sequence values, and old proofs. It MUST NOT synthesize missing events. Policies MAY set stricter bounds. Any recovery exceeding these bounds requires an Emergency Override approved by an identified human before execution. The RECOVERY event MUST identify operation_type, break_point (chain, sequence, last valid hash), affected ranges, quantitative bound, observed quantity, reason, validation_evidence hashes, approving actor, approval time, and emergency_override boolean. Such an override MUST be flagged in the evidence report; approval does not turn an unverified interval into a continuous valid chain. If the old chain cannot continue, a new chain MUST begin with a RECOVERY event referencing the old chain and last verified anchor; its genesis prev_hash remains null. The old chain, break evidence, and both sets of receipts MUST be retained. Recovery records MUST NOT be filtered out of anchor batches, exports, or applicable verification scope. Repeated bounded operations MUST NOT be used to evade the daily bound. 14.7. Optional Cross-Party References When used, header.cross_reference_id MUST be a shared UUIDv7 recorded independently by participating parties. XREF_OBSERVATION domain_payload MUST declare role (INITIATOR, COUNTERPARTY, or OBSERVER), counterpart identity, referenced event identifiers, matching policy, time tolerance in seconds, observation status (PENDING, MATCHED, DISCREPANCY, or TIMEOUT), and severity (INFO, WARNING, or CRITICAL). Each party's evidence MUST be independently signed and anchored. MATCHED requires validated counterpart evidence satisfying the declared matching policy; one party's unverified claim Yamakawa Expires 29 April 2027 [Page 30] Internet-Draft VAP-LAP October 2026 is insufficient. Confidential fields MUST NOT be disclosed merely to create a cross-reference. 15. 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 Section 8. A complete anchored batch can still contain an incomplete operation; operation-boundary records outside the selected batch may be needed. Yamakawa Expires 29 April 2027 [Page 31] Internet-Draft VAP-LAP October 2026 16. Override Coverage and Enforcement 16.1. Override Coverage Metric HUMAN_OVERRIDE events are outside the Completeness Invariant but LAP defines Override Coverage as a critical operational metric: Override Coverage = Count(distinct target_event_id with at least one HUMAN_OVERRIDE where link_type = "OVERRIDE_OF") / Count(LEGAL_*_RESPONSE) This metric quantifies the degree to which human professionals review AI outputs. In jurisdictions where regulations require that a licensed professional personally scrutinize AI-generated work products, this metric provides evidence of recorded review activity, without establishing legal compliance or review quality. Design notes on the denominator: * The numerator counts distinct target events (not raw HUMAN_OVERRIDE count) to prevent a single output reviewed multiple times from inflating coverage above 100%. * DENY events are excluded from the denominator because a denial represents the AI system refusing to produce output. There is no AI-generated work product for a professional to review. If a jurisdiction requires that denial decisions themselves be reviewed, the implementation SHOULD track this as a separate "Denial Review Coverage" metric. * ERROR events are excluded from the denominator because they do not produce an output suitable for professional approval or rejection. Completeness of error handling is evaluated separately via the per-pipeline invariant. Yamakawa Expires 29 April 2027 [Page 32] Internet-Draft VAP-LAP October 2026 +==========+============+==================================+ | 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 | +----------+------------+----------------------------------+ Figure 3: Override Coverage Assessment 16.2. Interpreting Review Coverage Coverage counts recorded HUMAN_OVERRIDE links, not verified professional diligence. A value of 100 percent establishes neither correctness nor compliance. The report MUST declare its time range, denominator, excluded events, duplicates, and unavailable evidence. A zero denominator is not applicable, not 100 percent. Operational alert thresholds are a deployment policy choice and MUST NOT be presented as legal adequacy thresholds. 16.3. Enforcement Level Mapping +=======================+==========+=============+=============+ | Enforcement | Bronze | Silver | Gold | +=======================+==========+=============+=============+ | Level 0 (Metric Only) | Default | Minimum | N/A | +-----------------------+----------+-------------+-------------+ | Level 1 (Warn) | OPTIONAL | REQUIRED | REQUIRED | +-----------------------+----------+-------------+-------------+ | Level 2 (Gate) | N/A | RECOMMENDED | RECOMMENDED | +-----------------------+----------+-------------+-------------+ | Level 3 (Strict) | N/A | OPTIONAL | OPTIONAL | +-----------------------+----------+-------------+-------------+ Figure 4: Enforcement Level by Conformance Level Yamakawa Expires 29 April 2027 [Page 33] Internet-Draft VAP-LAP October 2026 16.4. Enforcement Level Mapping Bronze has no mandatory review gate; Level 0 is its default if coverage is computed. Silver and Gold MUST implement Level 1 warnings at minimum and SHOULD implement Level 2 gates for designated high-risk outputs. Level 3 is OPTIONAL at any level. Stronger enforcement does not replace signatures, anchors, or evidence of the actual review. 16.5. Structural Limitation Acknowledgment This specification acknowledges that no technical mechanism can fully guarantee the quality or depth of human professional review. A licensed attorney may approve an AI output after genuine review or after cursory inspection; the system cannot distinguish between these without introducing unacceptable surveillance of professional judgment. The enforcement framework therefore aims to: (a) create friction against entirely unreviewed AI output usage; (b) provide auditable evidence of review or lack thereof; (c) enable risk-proportionate controls (stronger for high-risk document types); and (d) preserve professional autonomy while recording accountability metadata. The combination of enforcement levels, latency monitoring, and comprehensive provenance logging shifts the accountability model from "trust alone" to "trust with verification infrastructure," acknowledging that while absolute prevention is impossible, the cost and detectability of non-compliance can be substantially increased. 17. 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: Yamakawa Expires 29 April 2027 [Page 34] Internet-Draft VAP-LAP October 2026 +============+=================+====================+==============+ |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 | +------------+-----------------+--------------------+--------------+ Figure 5: LAP Privacy-Preserving Fields Fields with low input entropy (CaseNumberHash, BarNumberHash, PartyHash) MUST use HMAC-SHA-256 with the tenant salt as key, per Section 10.1, 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 Section 10.1. Third-party verifiers can confirm event existence and chain integrity without accessing privileged content. Yamakawa Expires 29 April 2027 [Page 35] Internet-Draft VAP-LAP October 2026 The availability of original content corresponding to these hashes depends on the current Content Retention Tier (Section 11.2). 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. 18. LAP Requirement Matrix All 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. 19. 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. Yamakawa Expires 29 April 2027 [Page 36] Internet-Draft VAP-LAP October 2026 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. 20. Security Considerations This section describes the threat model and security considerations for VAP-LAP implementations, following the guidance in [RFC3552]. 20.1. Threat Model VAP assumes the following attacker capabilities and trust assumptions: * Attacker capabilities: An adversary may have read access to the event store, network access to observe event traffic, and in some scenarios write access to event storage (insider threat). The adversary's goal is to forge, suppress, reorder, or selectively disclose provenance events. * Trust assumptions: The signing key holder is trusted to sign only genuine events. The external anchoring service is trusted to provide accurate timestamps and append-only guarantees. Verifiers are trusted to correctly execute the verification algorithm. 20.2. Hash Chain Manipulation An adversary with write access could attempt to modify past events, insert fabricated events, or delete events. The hash chain provides integrity: any modification to a past event changes its EventHash, breaking the chain at that point. External anchoring at every LAP level makes post-hoc modification detectable by comparing the stored Merkle root against the independently timestamped root. Implementations SHOULD use Merkle consistency proofs (per [RFC9162] Section 2.1.4) to detect log forking. 20.3. Timestamp Limits Event timestamps are producer assertions. Verifiers MUST check internal chronology, receipt time, configured clock uncertainty, and the declared anchoring interval separately. A daily batch can legitimately include events many hours before its receipt; a fixed 300-second event-to-receipt limit is therefore inappropriate. Events later than the authenticated receipt time plus the declared clock tolerance MUST be flagged. A receipt proves commitment existence no Yamakawa Expires 29 April 2027 [Page 37] Internet-Draft VAP-LAP October 2026 later than that time, not truth of each event timestamp. 20.4. Insider Threats An authorized operator could forge events, suppress events before they are anchored, or create fabricated ERROR events to satisfy the Completeness Invariant while hiding actual outcomes. Mitigations include: * External anchoring makes suppression detectable after anchoring. * Gold level implementations SHOULD require multi-party signatures for administrative events (Legal Hold, tier changes). * Separation of duties: the event signer and the external anchor submitter SHOULD be different principals where operationally feasible. * Completeness Invariant cross-validation against application-layer logs (e.g., HTTP request logs) can detect fabricated events at audit time. 20.5. Key Compromise Compromise of signing keys allows event forgery. Bronze implementations SHOULD rotate keys annually. Silver MUST rotate semi-annually. Gold MUST use HSM storage ([FIPS140-3]) and quarterly rotation. Upon key compromise detection, the implementation MUST: 1. Immediately revoke the compromised key. 2. Generate a new signing key pair. 3. Record a KEY_ROTATION event signed by the new key, referencing the compromised key identifier. 4. Preserve all original events and receipts; issue a new signed incident attestation identifying the affected range and any supplemental anchor. New anchoring does not validate previously compromised signatures. 5. Notify all relying parties of the compromise and the validity window of the affected key. Yamakawa Expires 29 April 2027 [Page 38] Internet-Draft VAP-LAP October 2026 During key rotation (including non-emergency rotation), the hash chain continues unbroken. The new key signs a KEY_ROTATION event that includes the old key's public key hash, establishing chain continuity. Verifiers MUST validate key authorization and compromise status independently; a KEY_ROTATION event signed only by an untrusted new key is insufficient. An overlap period does not override revocation evidence. 20.6. Privacy Leakage Per-tenant salting prevents cross-tenant hash correlation. Implementations MUST NOT share salts across tenants. Event metadata (timestamps, event types, counts) may leak statistical information even when content is hashed; this is an inherent limitation of any audit trail system. Selective disclosure via Merkle proofs (Section 7.3) enables verifiers to inspect specific events without accessing the full event store, reducing exposure. For privacy analysis guidance, see [RFC6973]. 20.7. Availability Attacks Denial-of-service attacks against the logging infrastructure could prevent event recording, violating completeness. Gold level implementations MUST have geographic redundancy. Implementations SHOULD buffer events locally when the central event store is unavailable, and MUST reconcile buffered events upon reconnection. 20.8. Omission and Split Views A verified count, range, and Merkle commitment detect omitted or changed members when a producer claims to disclose the complete committed batch. Inclusion proofs for a subset cannot establish full disclosure. An operator may omit entire attempt/outcome pairs before capture or present different signed histories to different recipients. Checkpoint comparison, independent witnesses, and cross- party records are needed to detect split views. A single receipt and internally balanced counters do not establish global completeness. 20.9. Selective Disclosure Attacks An adversary could present only favorable events to a verifier, hiding unfavorable records. The Completeness Invariant detects such omissions: any missing outcome event will cause the invariant to fail for the affected pipeline. External anchoring of Merkle roots makes it infeasible to present a consistent subset of events that satisfies the invariant if any events have been omitted. Yamakawa Expires 29 April 2027 [Page 39] Internet-Draft VAP-LAP October 2026 20.10. Replay Attacks An adversary could replay valid events from one context into another. The chain_id field binds events to a specific chain, and the prev_hash field creates a strict ordering dependency that makes replayed events detectable (they will break the hash chain at the insertion point). UUIDv7 event identifiers provide globally unique, time-ordered identification that further constrains replay. 20.11. Content Retention and Discovery Risk The tension between privacy-preserving hash-only retention and judicial discovery obligations creates a risk that hash-only evidence may be deemed insufficient by courts. The Tiered Retention model (Section 11.2) mitigates this by maintaining recoverable content during periods when discovery is most likely, while the Legal Hold Protocol (Section 11.4) prevents premature content destruction when litigation is anticipated. 20.12. Override Enforcement Circumvention Enforcement Levels 1 and 2 (Section 16.2) can be circumvented by users who copy AI output through means outside the system's control (e.g., screen capture, manual transcription). Technical enforcement addresses the common case of system-mediated export but cannot prevent all forms of circumvention. The provenance chain nonetheless records the absence of HUMAN_OVERRIDE events, providing post-hoc accountability. 20.13. Rapid Approval Gaming Users aware of the Override Latency threshold (Section 16.4) might delay approval clicks to avoid the RAPID_APPROVAL_FLAG. This is a known limitation. Statistical analysis of approval latency distributions across users and document types can detect such gaming patterns in audit reviews. 20.14. Legal Hold Integrity Legal Hold activation and release events must be protected from unauthorized modification. Gold level implementations SHOULD require multi-party authorization for Legal Hold release. 21. IANA Considerations Yamakawa Expires 29 April 2027 [Page 40] Internet-Draft VAP-LAP October 2026 21.1. Media Type Registration IANA is requested to register the following media types in the "Media Types" registry: 21.1.1. 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 Section 9.1. Implementations MUST support the manifest.json format defined in Section 9.2. 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 Yamakawa Expires 29 April 2027 [Page 41] Internet-Draft VAP-LAP October 2026 Author: Shintaro Yamakawa Change controller: IETF 21.1.2. 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 [RFC8259] Security considerations: The manifest is integrity-protected as part of the Evidence Pack signature. See Section 20. Interoperability considerations: JSON format per Section 9.2. 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 Yamakawa Expires 29 April 2027 [Page 42] Internet-Draft VAP-LAP October 2026 21.2. Profile Identifier Scope This draft defines LAP for use with its explicit schema identifiers. It makes no request to reserve identifiers for other upstream profiles and does not create or amend the upstream VAP registry. Coordination of any future IANA profile registry with that upstream registry remains an open issue. 21.3. Event Type Scope The event names in Section 14 are scoped by the LAP schema_id and profile version. This revision does not request a cross-domain VAP event registry. The media type registrations above remain proposals; no allocation is asserted. 22. Relationship to Other Work SCITT [RFC9943] defines a transparency architecture; COSE Receipts [RFC9942] 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. 23. References 23.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . Yamakawa Expires 29 April 2027 [Page 43] Internet-Draft VAP-LAP October 2026 [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, . [RFC5816] Santesson, S. and N. Pope, "ESSCertIDv2 Update for RFC 3161", RFC 5816, DOI 10.17487/RFC5816, April 2010, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [VAP12] VeritasChain Standards Organization, "VAP Framework Specification, v1.2.0 Draft 3, VSO-VAP-SPEC-001", October 2026, . Fixed repository commit 81fa81e01ef9418c3fb7a02ddfc7fd72d993b6b1; CC BY 4.0. Source baseline; this LAP proposal is not an upstream endorsement. [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, 2026, . Yamakawa Expires 29 April 2027 [Page 44] Internet-Draft VAP-LAP October 2026 23.2. Informative References [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, . [RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for Post-Quantum Traditional Hybrid Schemes", RFC 9794, DOI 10.17487/RFC9794, June 2025, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [JAPAN-ATTORNEY-ACT] Government of Japan, "Attorney Act (Bengoshi-ho), Act No. 205 of 1949", 1949. [JFBA-AI-GUIDANCE] Japan Federation of Bar Associations, "Precautions Regarding the Use of Generative AI in Attorney Practice", September 2025. [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . Yamakawa Expires 29 April 2027 [Page 45] Internet-Draft VAP-LAP October 2026 [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [FIPS203] National Institute of Standards and Technology, "Module- Lattice-Based Key-Encapsulation Mechanism Standard", FIPS 203, August 2024. [FIPS204] National Institute of Standards and Technology, "Module- Lattice-Based Digital Signature Standard", FIPS 204, August 2024. [FIPS140-3] National Institute of Standards and Technology, "Security Requirements for Cryptographic Modules", FIPS 140-3, March 2019. Appendix A. Upstream Requirement Mapping This 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 Appendix B. Validation Requirements Validators 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. Yamakawa Expires 29 April 2027 [Page 46] Internet-Draft VAP-LAP October 2026 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. B.1. Serialization and Merkle Primitive Vectors These small objects exercise serialization and tree construction only; they are not LAP events or signatures. The exact inputs contain no leading or trailing whitespace. All digests are SHA-256 hexadecimal. For the third leaf (index 2, size 3), the sibling is the two-leaf root on the left. d(0) = {"a":"1","b":true} d(1) = {"a":"2","b":false} d(2) = {"a":"3","b":null} empty_root = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 two_leaf_root = 81bf82be3b1303d45cb2bcc0996c743674186a4c45db54868536ba5fb0737a20 three_leaf_root = e2432afb47c308a949b76a048780be5c9765b0ea6d27b17f167a08c5670d32d7 leaf(0) = fba9de6076dc98b39a486ee4d32ca78e6b3b0d238d6f02df056fbf20058bbf8a leaf(1) = 3623daa57bddb441e0a4e7732f002ee50196107848e4f08706d47a67d91890ca leaf(2) = bd476a15d851fe0ef64cc866e8e3b82108c9544b17079b59f46e1db51e8bae1a Appendix C. Implementation Status This section follows [RFC7942] 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 Yamakawa Expires 29 April 2027 [Page 47] Internet-Draft VAP-LAP October 2026 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. Appendix D. Change Log D.1. Changes from -04 to -05 * Pin upstream VAP v1.2.0 Draft 3; distinguish LAP levels, schema, authority, and profile status. * Require signed Merkle commitments and external anchors for Bronze, Silver, and Gold; bind policy, count, range, and previous batch; define continuity and fallback reporting. * Add schema identity, numeric string rules, trace and sequence identifiers, immutable policy binding, and explicit signed-byte definitions. Advance LAP profile version to 0.6.0; preserve legacy records. * Bound recovery, require erasure evidence and legal hold checks, and specify optional cross-party evidence. * Limit completeness claims to declared captured evidence; remove fabricated timeout balancing and unsupported compliance/ implementation claims. * Define detached Evidence Pack commitments and retain legal review, escrow, and hold controls. Add serialization and Merkle test vectors. D.2. Historical Revision Notes This section tracks changes between Internet-Draft revisions and will be removed before publication. draft-ailex-vap-legal-ai-provenance-04 * Refreshed the document. There are no technical changes to the VAP Framework or to LAP; vap_version remains 1.4 and the LAP Profile Version remains 0.5.0. Yamakawa Expires 29 April 2027 [Page 48] Internet-Draft VAP-LAP October 2026 * Replaced the reference to the SCITT architecture Internet-Draft with [RFC9943], which has been published since the previous revision, and replaced the unresolved "[IETF-SCITT]" citation in Section 22 with the same reference. * Updated the SCITT Reference APIs (SCRAPI) reference to its current revision. * Added [RFC9711] (EAT) as an informative reference for its existing mention in Section 22. * Aligned the vap_version example values in Section 5 and Section 9.2, and the Profile Version in Section 13.1, with the versions announced in -03 (1.4 and 0.5.0, respectively). * Corrected cross-references: citations of Section 5 of RFC 4648, Section 6 of RFC 8259, and Section 2 of RFC 9162 previously linked to sections of this document; the EU AI Act citation in draft-04 19.2 (https://www.ietf.org/archive/id/draft-ailex-vap-legal-ai- provenance-04.html) now reads "Annex III, point 8(a)"; in-text references to "Table 1" and "Table 2" now point to Figure 1 and Figure 2; and the existing mentions of FIPS 203 and FIPS 204 in Section 4.1 now cite [FIPS203] and [FIPS204]. * Updated Appendix C (Implementation Status) to distinguish the first-generation AILEX SaaS platform from its successor implementation. * Editorial: restored the revision heading for -03 in this change log. draft-ailex-vap-legal-ai-provenance-03 * Added draft-04 22.1 (https://www.ietf.org/archive/id/draft-ailex- vap-legal-ai-provenance-04.html) "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 (https://www.ietf.org/archive/id/draft-ailex- vap-legal-ai-provenance-04.html)) illustrating the complementary positioning of Application Layer, Domain Profile Layer (LAP), Provenance/Anchoring Layer (VAP), Collaboration Layer (DMSC), and Security/Transport Layer. Yamakawa Expires 29 April 2027 [Page 49] Internet-Draft VAP-LAP October 2026 * Added disambiguation NOTE clarifying that "DMSC" in this document refers to Dynamic Multi-agent Secured Collaboration, with cross- reference to the Distributed Micro Service Communication usage of the same acronym. * Added terminology entries: Secure Multi-Agent Collaboration, AI Agent Collaboration Provenance, Provenance Profile, and Domain- Specific Provenance Constraints (Section 2.1). * Defined integration points between VAP-LAP and DMSC-class frameworks using existing Common Event Structure fields (actor_id, causal_link, chain_id, domain_payload) without introducing new fields (draft-04 22.1.3 (https://www.ietf.org/archive/id/draft- ailex-vap-legal-ai-provenance-04.html)). * Clarified that VAP-LAP operates as a provenance and domain profile layer independent of any specific collaboration framework, while identifying concrete integration points with DMSC-class architectures. * Added informative references DMSC-BOF, DMSC-ARCH, DMSC-TECH, DMSC- DTA. * Updated vap_version from 1.3 to 1.4. * Updated LAP Profile Version from 0.4.0 to 0.5.0. draft-ailex-vap-legal-ai-provenance-02 * Added individual author name (Shintaro Yamakawa) per IETF guidelines requiring personal author identification. * Fixed cryptographic algorithm naming: Kyber-1024 renamed to ML- KEM-1024 per FIPS 203 standardization; separated into distinct KEM category from Encryption. Added ML-DSA-65 parameter set selection rationale. * Resolved EventHash circular reference: defined explicit Hash Input excluding security.event_hash and security.signature from canonicalization input (Section 4.2). * Resolved crypto agility contradiction: hash chain and signature formulas now parameterized by hash_algo/sign_algo fields instead of hardcoding SHA-256/Ed25519. Added Algorithm Migration procedure (Section 4.4) with post-quantum readiness subsection referencing FIPS 204 and RFC 9794. Yamakawa Expires 29 April 2027 [Page 50] Internet-Draft VAP-LAP October 2026 * Updated Merkle tree construction to follow RFC 9162 (replacing obsoleted RFC 6962), with domain separation prefixes and correct handling of non-power-of-two leaf counts (Section 7.3). * Fixed encoding specifications: timestamps now require RFC 3339; Base64 encoding now requires RFC 4648, Section 5 (URL-safe, no padding); hash values standardized as lowercase hex; RFC 8259 added to normative references (Section 5). * Updated FIPS 140-2/3 to FIPS 140-3 as primary requirement with transition period note (Section 6.3). * Added RFC 5816 (ESSCertIDv2) as normative reference for RFC 3161 TSA SHA-256 support (Section 7.1). * Specified anchor_proof structure per anchor_type with type- specific fields and verification procedures (Section 7.2). * Added Completeness Invariant grace period maximum of 300 seconds with TIMEOUT_ERROR mechanism (Section 8). * Added standardized causal_link field in header for all event types, with link_type enumeration (Section 5). * Fixed Override Coverage metric: numerator changed to count distinct target_event_id to prevent exceeding 100%. DENY removed from denominator with rationale documented (Section 16.1). * Added salt management requirements: 256-bit minimum entropy, HMAC- SHA-256 for low-entropy fields, rotation and compromise response procedures (Section 10.1). * Added minimum verification API with HTTP endpoints for Silver and Gold levels (Section 12.1). * Added Bronze-level validation requirements specifying minimum field presence and type checking (Appendix B). * Expanded Security Considerations with explicit threat model, 12 specific threat analyses per RFC 3552, key rotation procedures, and denial-of-provenance mitigation (Section 20). * Expanded IANA Considerations with media type registration templates, VAP Domain Profile registry, and VAP Event Type registry per RFC 8126 (Section 21). * Added GDPR interaction subsection addressing right-to- erasure vs. audit trail tension (Section 11.1). Yamakawa Expires 29 April 2027 [Page 51] Internet-Draft VAP-LAP October 2026 * Added escrow custodian requirements for Tier 2 content recovery (Section 11.4). * Added Relationship to Other Work section positioning VAP relative to SCITT, RATS/EAT, AIPREF, Sentinel Protocol, and ISO/IEC standards (Section 22). * Added Implementation Status appendix per RFC 7942 (Appendix C). * Added Japan AI Promotion Act (2025) to regulatory alignment references. * Added SALT_ROTATION event type to LAP administrative events (Section 14.5). * Removed EIP from profile.id enumeration (undefined profile). * Normalized all algorithm identifiers to lowercase hyphenated ASCII strings with explicit canonical mapping table (Section 4.1). Resolved inconsistency between field values (e.g., "SHA-256") and wire prefixes (e.g., "sha256:") by unifying on a single form (e.g., "sha-256" / "sha-256:"). * Added UTF-8 encoding requirement for all text fields (Section 5, RFC 3629). * Updated vap_version from 1.2 to 1.3. * Updated LAP Profile Version from 0.3.0 to 0.4.0. * Updated Abstract to reference SCITT. draft-ailex-vap-legal-ai-provenance-01 * Added Tiered Content Retention model (Section 11.2). * Added Legal Hold Protocol (Section 11.5) with five trigger types. * Added Judicial Disclosure Response procedures (Section 11.6). * Expanded Override Coverage with four-level Enforcement Framework. * Added Override Latency Threshold with Rapid Approval Flag. * Added Section 16.5 acknowledging structural limitations. * Added seven new event types for retention and enforcement. Yamakawa Expires 29 April 2027 [Page 52] Internet-Draft VAP-LAP October 2026 * 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 [JAPAN-ATTORNEY-ACT] Article 72 (August 2023), the [JFBA-AI-GUIDANCE] 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. Author's Address Shintaro Yamakawa (editor) AILEX LLC / VeritasChain Standards Organization 1-10-8 Dogenzaka, Shibuya-ku, Tokyo 150-0043 Japan Email: info@ailex.co.jp URI: https://ailex.co.jp Yamakawa Expires 29 April 2027 [Page 53]