]> Independent Researcher

mikhailsergeev369@gmail.com

Independent Researcher

ikherva@gmail.com

Security witnessability execution evidence boundary ceiling AI agents audit provenance The Witnessed Execution Protocol (WEXP) defines a record format and a verification procedure for classifying the strength of execution-related evidence about actions performed by software and AI systems. A WEXP record asserts, for a single action, a Witnessability Level (WL) bounded by the execution-relevant boundary that the witness controls. WEXP grades only the evidentiary strength of an execution claim; it does not certify the action's correctness, safety, or alignment. This document specifies WEXP Core: the record model, required fields, the two classification axes (Witnessability Level and Conformance Class), the honesty invariants that bound claims, the verifier procedure, and failure semantics. WEXP Core is profile-independent and validates standalone.

Note to Readers (to be removed before publication) The archival deposit of this specification is intended to be made available under CC BY 4.0; the IETF Internet-Draft is contributed under the IETF Trust's Legal Provisions (see the boilerplate). The reference implementation is being developed by WitSeal; no co-author or party holds ownership, licensing exclusivity, or veto rights over the specification.

Introduction Modern AI and software systems produce many forms of execution-related evidence -- logs, traces, approvals, tool-call records, attestations, workflow histories -- that are frequently conflated. The conceptual foundation for distinguishing the strength of such evidence is the Witnessability Model , which defines six witnessability levels (WL0-WL5) and the Boundary Ceiling Principle: a witness cannot honestly claim a level above the strongest execution-relevant boundary it controls or can independently verify. WEXP operationalizes that model as a concrete, verifiable record protocol. Where the model is descriptive, WEXP is prescriptive: it defines what a conforming record MUST contain at each claimed level, and what a conforming verifier MUST check. Attestation answers whether a record is authentic; a transparency service answers whether it existed as claimed. WEXP answers a third question that neither resolves: given the available evidence and the boundary at which it was obtained, what claim level is warranted? A related individual Internet-Draft proposes an architecture for auditing AI-agent delegation and interactions , whose proposed work items include canonical audit data models and semantics (WI-1) and an Action Record profile produced at the boundary where each tool or service call took effect (WI-4). That architecture records, correlates, and attests audit records across delegation and evolving authorization state; it does not define the evidential-status semantics that bound what such a record may honestly claim about execution. WEXP supplies that layer: a boundary-derived claim ceiling (verified_level <= attainable(boundary_type, claimed_level, evidence)), a verifier verdict of accept, reject, or downgrade, non-inflation under composition, and fail-closed handling of unknown-critical content. WEXP is therefore an orthogonal contribution to such audit data models -- specifically the claimed-level and ceiling semantics for Action Records -- not a competing audit architecture or data model. WEXP intentionally separates three concerns that are often conflated: (1) where an action is observed, (2) how authentic the resulting record is, and (3) what evidential claim that record can honestly support. This document is differentiated by treating the boundary-derived ceiling as a verifier-enforced protocol invariant, rather than as an audit placement rule, attestation result, or transparency receipt. WEXP makes no chronological priority claim.

• Reference Implementation Non-Authority Clause. Where a reference implementation conflicts with this specification, the specification prevails. Where the specification is ambiguous, a resolution document is required before implementation behavior becomes normative.

Scope This document specifies WEXP Core only. Profiles (domain-specific bindings) and Policy (Evidence Contract gating) are layered above Core and are out of scope here, except where Core constrains them. A Core record MUST validate without reference to any profile. To bound Core precisely, the following are explicitly out of scope for this document and are left to profiles or future revisions: This document does not define a COSE or JWS envelope profile. This document does not define internal provenance or independent-verification evidence schemas. This document does not define trust-anchor discovery or revocation. This document does not define chain construction, segment discovery, or delegation linkage. This document does not define a capabilities-document format beyond the fail-closed handling of capabilities_ref (). These deferred items are expected to be addressed by separate WEXP profiles, developed independently of and layered above this Core document. Such profiles are anticipated to bind WEXP records to existing mechanisms rather than re-specify them -- for example, a JOSE or COSE serialization profile, a boundary-grounding profile referencing RATS attestation evidence, provenance and independent-verification profiles aligned with supply-chain and transparency work (for example, ), and deployment profiles that map WEXP evidence onto external record-keeping regimes. These profiles are informative with respect to this document: they extend and depend on Core, but a Core record is complete and verifiable without any of them ().

Relationship to Related Work describes an architectural framework for distributed audit-record generation, audit-context propagation, attestation, and transparency logging in agent-driven interactions, and identifies candidate record types and IETF substrate profiles (RATS, SCITT, OAuth, WIMSE). It independently arrives at recorder independence (a record produced at the boundary, not as reported by the agent; an agent that records itself cannot deliver non-repudiation to a third party). WEXP is complementary: it does not define an agent audit architecture, an identity substrate, or a transparency service. It defines verifier-facing evidence-to-claim semantics -- the boundary-derived claim ceiling, the accept/reject/downgrade verdict, non-inflation, and fail-closed handling -- that does not specify. In terms these belong in WI-1 as the claimed-level and ceiling semantics the data models require but do not define, with the WI-4 Action Record profile carrying the claimed level. A parallel line of work, , defines a portable signed receipt format for machine-to-machine access-control decisions. A subsequent profile, , binds fields to specific regulatory obligations including EU AI Act Articles 12 and 26 and DORA Article 17. WEXP is complementary to both: specifies a wire format and verification procedure for signed decision records; WEXP specifies the evidential-status semantics -- the boundary-derived claim ceiling, the verifier verdict of accept/reject/downgrade, non-inflation under composition, and fail-closed handling of unknown-critical content -- that bound what claim level any such record can honestly support. A WEXP record MAY be carried as an artifact in the format. Where an ACTA or ASQAV receipt carries a correlation identifier such as action_ref, a WEXP profile MAY use that value as a correlation hint between the receipt and the WEXP record witnessing the same action; such correlation is not execution evidence, is not required by WEXP Core, and does not raise the verified level. The WEXP layer adds the claim-strength semantics that the receipt format itself does not specify. WEXP defines no transparency service, no identity substrate, and no decision-recording wire format of its own -- it is the evidential-status layer over such substrates. Additional Internet-Drafts in adjacent slots include , which specifies a hash-chained logging format with trust outcome levels, and , which specifies a pre-action fail-closed gate primitive that may be wrapped in a envelope. WEXP is complementary to these: specifies how audit records are stored and chained; specifies a gate primitive applied before action execution. WEXP specifies the claim-strength taxonomy that bounds what any such record or gate-result may honestly assert, and the verifier ladder that enforces it. Further adjacent drafts include , a conversation-record format for agent sessions with post-hoc divergence detection; , which combines signed behavior receipts, hash-chain linking, and a pre-execution policy gate; and , which specifies pre-action delegation receipts anchored to an append-only log -- an authorization-plane object attesting what was authorized rather than what occurred. WEXP defines none of these objects; it defines the claim-strength semantics that bound what any such record, gate result, or delegation trace may honestly assert. Two adjacent level schemes deserve explicit contrast. SLSA defines graduated build-integrity levels for the software supply chain: as in WEXP, a claim is bounded by the strength of the platform boundary that produced the evidence, but SLSA grades the build provenance of artifacts, not runtime execution events -- WEXP applies the same discipline to runtime actions, and a SLSA provenance statement is one natural source of the WL4 provenance artifact. Within the IETF, RATS Attestation Results for Secure Interactions grades the trustworthiness of an attested environment from appraised evidence; WEXP grades the claim strength of an execution-event record, with environment attestation as one input that can raise the attainable level (). Neither scheme defines a claim ceiling bound to the execution boundary of a specific action; that is the layer WEXP specifies.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Witness. A system, component, runtime, service, process, organization, or verifier that records or verifies evidence about an action. Action. An operation performed by a software or AI system that changes state, produces output, invokes a tool, executes code, or otherwise affects an environment. Boundary. A control surface across which an action is observed, approved, invoked, executed, linked to provenance, or verified. WEXP Record. A structured artifact conforming to this specification that asserts an execution-evidence claim at a stated Witnessability Level. Witnessability Level (WL). A record-scoped level, WL0-WL5, expressing how deeply the runtime action is witnessed through the execution boundary (see for the model). Conformance Class (CC). An implementation-scoped class, CC0-CC5, expressing how technically verifiable a record is. Relationship to WIMSE: WEXP and its reference implementation are distinct from the WIMSE Workload Identity Credential (WIT) . A bounded-claim execution record is evidence about what occurred at a boundary, not a workload identity credential, and does not replace WIT. Note on Witnessability Level (WL) Versus Other Level Schemes. Numbered trust levels and graded conformance tiers appear in adjacent specifications and informal industry discussion (for example, trust outcome levels in , Bronze/Silver/Gold conformance tiers in , and the multi-layer agent trust models discussed in industry analyses). These schemes classify outcome quality, infrastructure capability, or authorization-stack position. WEXP WL is distinct: it classifies the claim-strength that a record can honestly support given the boundary at which the evidence was produced. WL is an epistemic ceiling on what a witness may assert, not a trust rating, infrastructure grade, authorization tier, or maturity score. A WL3 record is not "more trusted" than a WL1 record; it is a claim about a stronger execution-evidence boundary having been controlled or independently verified. Whether a particular witness is honest or compromised is a question of attribution and grounding, not of the level taxonomy: the boundary assertion, its CC-bound attribution, and their limits are specified in .

Witnessability Level (WL) and Conformance Class (CC) WEXP separates two orthogonal axes. The Core interpretation of each Witnessability Level, used by the verifier, is: WL Core interpretation WL0 No execution-evidence claim is verified. WL1 Intent or approval is bound to the action arguments. WL2 Invocation crossed an observed boundary. WL3 Execution was observed at an execution-ownership boundary. WL4 WL3 plus a bound top-level provenance artifact. WL5 WL3 plus a bound top-level independent-verification artifact. This table defines the Core interpretation used by the verifier. It does not define provenance, attestation, independent-verification, policy, or trust-anchor schemas. WL4 and WL5 are sibling evidence lifts over the WL3 base: WL4 adds a bound provenance artifact, WL5 a bound independent-verification artifact. WL5 is ordered above WL4 for verifier ceiling comparison (), but a WL5 claim does not imply the presence of a provenance artifact unless required by a profile or policy. A policy that requires provenance MUST require it explicitly and MUST NOT infer it from verified_level >= WL4. Witnessability Level (WL) is record-scoped: it describes how deeply a specific runtime action is witnessed through the execution boundary. WL ranges over WL0-WL5 as defined by the Witnessability Model. Conformance Class (CC) is implementation-scoped: it describes how technically verifiable a record is, independent of any single record's content. CC ranges over CC0-CC5. CC MUST NOT be a per-record self-claim; it is reachable only by reference (via a capabilities_ref to the implementation's published capabilities). Criticality, reversibility, operational domain, and custody are not axes of WEXP. They MAY influence the minimum required WL or CC via policy or profiles, but they are not witnessability levels and MUST NOT be encoded as such.

Conformance Class (CC) scale Conformance Class is implementation-scoped and ranges over CC0-CC5. CC describes how technically verifiable an implementation's records are; it MUST NOT be a per-record self-claim and is reachable only by reference, via a capabilities_ref to the implementation's published capabilities. CC Name Requirement CC0 No conformance The implementation does not meet WEXP structural requirements. CC1 Structural The implementation emits records that validate against the Core schema. CC2 Signature The implementation additionally emits records that carry a valid signature over the canonical signing input, per seal.alg (). CC3 Bound The implementation additionally binds each signature to a verified key identity; at CC3 and above a boundary_type assertion is attributed to that identity (stronger grounding of the assertion is out of scope for Core; see ). CC4 Composed The implementation additionally verifies chains under composition without inflation (see ). CC5 Independent The implementation additionally produces records independently verifiable by a third party without the issuer. The classes are cumulative: CCn includes the capabilities of CCn-1. CC is orthogonal to a record's Witnessability Level: a high-CC implementation MAY emit low-WL records.

Implementation capability ceiling Each Conformance Class has a maximum Witnessability Level it can ground, maxCapability(CC): CC maxCapability(CC) CC0 WL0 CC1 WL0 CC2 WL2 CC3 WL3 CC4 WL4 CC5 WL5 The full Boundary Ceiling invariant () therefore caps a claim by BOTH the boundary-and-evidence attainable level and the implementation Conformance Class:

A verifier MUST enforce both bounds; a high-capability boundary does not raise a record above the issuing implementation's Conformance Class. For example, a record claiming WL4 at a tee boundary with a bound provenance artifact, from a CC3 implementation (maxCapability WL3), is bounded by min(WL4, WL3) = WL3 and is downgraded accordingly. Core treats capabilities_ref as an opaque reference. A verifier resolves it through local configuration or a profile-defined mechanism to an accepted Conformance Class; Core does not define the serialization, discovery, revocation, or trust-anchor model for such capabilities. If capabilities_ref is absent, unavailable, expired, unverifiable, or not accepted by the verifier's trust configuration, resolution fails and the effective Conformance Class is CC0: the record MAY still be structurally valid, but its verified level is bounded by maxCapability(CC0) = WL0 (fail-closed). Core interoperability therefore covers structure, signature, and the ladder mechanics; the assignment of a verified level above WL0 is relative to the verifier's trust configuration, in the same way that RATS appraisal is relative to appraisal policy. Rationale for the maxCapability(CC) mapping. The mapping assigns to each Conformance Class the highest Witnessability Level whose claims that class can actually ground; it tracks verifier capability, not witness output. At CC0 and CC1 no signature is verified, so no runtime claim above observation (WL0) can be grounded. At CC2 a record's signature is verified against a published key: intent (WL1) and invocation (WL2) claims become groundable, since both are carried in the signed content and differ only in their conditional-required fields (); execution claims are not, because CC2 does not ground the boundary assertion itself. CC3 adds that grounding -- key identity bound to the declared boundary through attestation or an established trust anchor -- which sets as the minimum for execution ownership, so maxCapability rises to WL3. CC4 adds verified composition (), the property that makes a provenance bridge trustworthy across chained records, raising the bound to WL4. CC5 adds verification of an independent-verification path, the implementation-side counterpart of WL5. The scale is monotonic non-decreasing by construction, and the combined invariant of -- which bounds the verified level by both the claim-relative attainable level of the boundary and maxCapability(CC) -- ensures that neither a high-ceiling boundary nor a high-capability implementation alone can raise a record's verified level.

Record Model A WEXP artifact is composed of the following layers. WEXP Core Record. MUST be present; otherwise the artifact is not a WEXP Record. WEXP Profile Binding. MUST be present inside a specific profile; OPTIONAL in pure-Core records. WEXP Top-level Evidence. Typed blocks: provenance (for WL4), independent-verification / attestation (for WL5), and transparency (orthogonal). Each is carried as a typed evidence-ref (); Core checks only its presence and syntactic binding to the record, not its internal semantics. Such evidence is REQUIRED at its claimed WL, and a verifier MUST honor evidence only when carried at the top level. This evidence MUST NOT be carried inside extensions. WEXP Extensions. An OPTIONAL map of the form { "<registered-name>": { "critical": <bool>, "value": <...> } }. Extensions MAY strengthen explainability. Extensions MUST NOT raise the WL, and MUST NOT carry WL4 or WL5 evidence. Profiles MUST NOT redefine Core fields; profiles MAY constrain, extend, or specialize them. A Core record MUST validate standalone, without a profile.

Core Record Fields A WEXP Core Record answers seven questions. The following fields MUST be present in every Core Record. Question Field(s) What happened? event.operation, event.event_type Who or what acted? subject{ agent_id, host_id } Where was the witness boundary? model.boundary_type What level is claimed? model.claimed_level (a WL) Who witnessed, and signed with what? witness{}, seal{} What is disclosed? disclosure{} Identity of protocol and record protocol, protocol_version, record_id, created_at The record_id is an opaque identifier: uniqueness is the issuing implementation's responsibility, and Core defines no format, namespace, or collision semantics beyond exact-match comparison.

Conditional-required fields by claimed level The following fields are conditionally required by model.claimed_level. These requirements are enforced by the verifier when evaluating the claimed level; their absence does not by itself make a Core Record structurally invalid and MUST instead result in a downgrade to the highest level, not exceeding the claim, whose own requirements are met (see and ). The schema validates structure; the verifier validates the claimed level. WL1 -- input.arguments_hash MUST be present. WL2 -- input.arguments_hash MUST be present, and only that (invocation-evidence). At WL2, policy and timing are OPTIONAL and are not Core-required: policy is orthogonal to WL and is profile-scoped. A profile MAY require policy for gate-mediated actions. WL3 -- execution.{ started_at, ended_at, outcome, result_hash } MUST be present. WL4 -- a provenance artifact (see , Top-level Evidence) MUST be present, in addition to the WL3 requirements. WL5 -- an independent-verification path MUST be present, in addition to the WL3 requirements. Raw payloads MUST NOT be required by Core; see the Minimal Evidence floor ().

Core Record schema (CDDL) The following CDDL () is the normative schema for a WEXP Core Record. A complete worked JSON example, with accept and downgrade verification walkthroughs, will be provided in a subsequent revision. A Core Record MUST validate against this schema; conditional-required fields by claimed level () and the honesty invariants () are additional constraints the verifier enforces beyond structural validation.

any } ; alg, sig, and kid are present iff the record is signed (CC2+); ; sig is base64url-encoded, no padding; kid is an opaque ; identifier of the signing key (resolution is out of scope). seal-block = { ? alg: tstr, ? sig: tstr, ? kid: tstr, * tstr => any } disclosure-block = { * tstr => any } input-block = { arguments_hash_alg: hash-alg, arguments_hash: tstr, ; base64url, no padding * tstr => any } execution-block = { started_at: tdate, ended_at: tdate, outcome: tstr, result_hash_alg: hash-alg, result_hash: tstr ; base64url, no padding } ; Top-level typed evidence refs. Core verifies their PRESENCE and ; SYNTACTIC binding (digest + optional bound_record_id); ; it does not validate internal semantics of the referenced artifact. evidence-ref = { type: tstr, digest_alg: hash-alg, digest: tstr, ; base64url, no padding ? uri: tstr, ? bound_record_id: tstr, * tstr => any } evidence-block = { ; provenance is required for WL4; at WL5 it is optional ; unless a profile or policy requires it ? provenance: evidence-ref, ? independent_verification: evidence-ref, ; required for WL5 ? transparency: evidence-ref, ; orthogonal } extensions-map = { * tstr => { critical: bool, value: any } } ]]>

Extensions MUST NOT raise the Witnessability Level and MUST NOT carry WL4 or WL5 evidence (). A top-level evidence artifact is bound to a WEXP record when the record carries an evidence-ref whose digest identifies that artifact and that reference is included in the signed record payload; bound_record_id, when present, is a reverse reference from the artifact to the WEXP record. Core validates the presence and syntax of this binding; validation of the artifact's internal semantics is profile-specific.

Honesty Invariants (Ceilings) Two ceilings and a floor bound what a record may honestly claim. A verifier MUST enforce the Boundary Ceiling and, when a qualification is asserted, the Recorder Ceiling; the Minimal Evidence floor is a content discipline on the producer.

Boundary Ceiling (MUST) The Boundary Ceiling separates two mechanisms: the execution-evidence level a boundary directly grounds, and the lift that bound top-level evidence adds on top of it. Base execution level. Each boundary type grounds a base execution-evidence level, base_execution_level(boundary_type), taken from the WEXP Boundary Types registry (): an intent or approval boundary grounds WL1, an invocation boundary WL2, and an execution-ownership boundary (including a trusted execution environment) WL3. No boundary grounds WL4 or WL5 by itself. Evidence lift. WL4 and WL5 are reached only by adding a bound top-level evidence artifact to an execution-ownership boundary, and each lift level is satisfied only by the artifact that defines it: a bound provenance artifact satisfies WL4; a bound independent-verification artifact satisfies WL5; neither satisfies the other's level. Attainability is claim-relative across the whole ladder -- the highest level, not exceeding the claimed level, whose own requirements are met. For WL1-WL3 the requirements are the boundary base and the conditional-required fields of ; for WL4 and WL5 they are an execution-ownership base, the WL3 execution evidence (the level table defines WL4 and WL5 as "WL3 plus" an artifact), and the corresponding bound artifact. Here evidence denotes both the record's conditional-required fields and its bound top-level artifacts:

= WL3 and claimed_level >= WL4 and the WL3 requirements are met and a bound provenance artifact is present: best = WL4 if base >= WL3 and claimed_level >= WL5 and the WL3 requirements are met and a bound independent-verification artifact is present: best = WL5 return best ]]>

An intent or invocation boundary (base < WL3) cannot reach WL4 or WL5: a provenance or independent-verification artifact attached to a manual-approval or proxy record does not raise it. WL4 and WL5 are available at host-hook, kernel, tool-runtime, and tee boundaries, each requiring the corresponding bound artifact. Combined invariant. The verified level MUST NOT exceed any of the claimed level, the boundary-and-evidence attainable level, the implementation Conformance Class capability (), the recorder ceiling (), and the composition minimum ():

The verifier MUST derive base_execution_level from the boundary-types registry based on the actual boundary_type, and MUST NOT derive it from the implementation's Conformance Class. A high-capability boundary does not raise a record above the implementation's Conformance Class: an implementation at CC3 (maxCapability WL3) emitting a record at a tee boundary with a bound provenance artifact is still bounded at WL3, since min(WL4, WL3) = WL3.

Recorder Ceiling (MUST when asserted) Core reserves a recorder-ceiling slot in the verified-level bound () but defines no recorder qualifications: the qualification vocabulary, its record fields, and the max_assurance() mapping are profile-defined. When no profile-defined qualification is asserted, the slot is inactive and does not constrain the record. When a profile asserts one, the claimed level MUST NOT exceed that profile's maximum assurance:

Minimal Evidence floor (SHOULD) Record content SHOULD be minimal-sufficient for the claimed WL. Raw payloads are excluded by default (Core never requires them); hashes, commitments, references, summaries, or encrypted material SHOULD be preferred. Minimality is relative to the claimed WL: verification metadata grows with WL, while the payload does not.

Evidence is required, not implied WL4 and WL5 require an actual bound evidence artifact, not merely a boundary label: a provenance artifact for WL4, and an independent-verification artifact for WL5. The boundary_type field is an assertion of the witness. At CC3 and above the assertion is bound to a verified key identity, which attributes it to a known signer but does not by itself prove the action was observed at the asserted boundary; stronger grounding of the boundary assertion (for example, boundary attestation evidence) is out of scope for Core and left to profiles and future work. Accordingly, a WEXP record does not prove that the declared boundary matches the actual execution environment.

WL4 attainability WL4 is attainable when both hold: (a) the boundary grounds an execution level of at least WL3 (base_execution_level(boundary_type) >= WL3), and (b) a bound top-level provenance artifact is present (see and ). WL4 is therefore reachable at any execution-ownership boundary -- host-hook, kernel, tool-runtime, or tee -- not only at tee: it is the bound provenance artifact, not a special boundary, that lifts WL3 execution evidence to WL4. WL5 is reached analogously, with a bound independent-verification artifact in place of the provenance artifact. An intent or invocation boundary (base_execution_level < WL3) cannot reach WL4 or WL5 regardless of any attached artifact.

Verifier Requirements A conforming verifier MUST evaluate a record through the following ladder; the overview below is informative, and the normative order of checks is the pseudocode of . The procedure is modular: Core, then (if present) Profile, then (if present) Policy.

canonical signing input (JCS for JSON) -> signature (per seal.alg; "Ed25519" MTI for JSON Core) -> key binding -> base execution level (boundary) -> conditional-required + evidence lift (WL4/WL5 artifact) -> Conformance Class capability -> recorder ceiling -> composition-min (chains) -> [profile: action taxonomy, maker-checker, correction] -> [policy: Evidence Contract gate -> ALLOW | DENY | REQUIRE_REVIEW] ]]>

Within this ladder, for the JSON serialization defined by this document, the signing input is the UTF-8 encoding of the JCS canonical form of the WEXP Core Record with seal.sig absent, so that seal.alg and, when present, seal.kid are part of the signed payload. The signature is computed and verified according to seal.alg, a string identifier that MUST name a fully specified signature algorithm -- one requiring no external parameters such as an unstated curve or hash. For this JSON serialization, the value "Ed25519" of seal.alg identifies Ed25519 as specified in and is mandatory to implement (); a verifier MAY implement additional profile-defined algorithms. Additional values of seal.alg MUST be introduced by a WEXP serialization or cryptographic profile that specifies the algorithm identifier namespace and the exact verification procedure; such profiles SHOULD reuse registered JOSE or COSE algorithm identifiers, including post-quantum signature algorithms, rather than minting WEXP-specific algorithm names. This document defines no algorithm registry of its own. Algorithms that are unsupported, unrecognized, or disallowed by the verifier's trust configuration fail closed (E_UNSUPPORTED_ALGORITHM). Canonicalization is a property of the serialization: JCS applies to this JSON serialization, and profiles defining other envelopes (for example, COSE) define their own canonical signing input. After signature computation, seal.sig is inserted as a base64url-encoded octet string without padding. All octet strings in the JSON serialization -- seal.sig, input.arguments_hash, execution.result_hash, and any evidence digest -- MUST be base64url-encoded without padding. If seal.sig is present and seal.alg is absent, unsupported, or unrecognized, the record is rejected (E_UNSUPPORTED_ALGORITHM); if seal.sig is absent, the record is not rejected on that basis and is evaluated at most as CC1 for that record (). An unsupported or unrecognized hash algorithm likewise fails closed: if the algorithm of a conditional-required hash (input.arguments_hash_alg, execution.result_hash_alg) or of an evidence digest_alg is unsupported, the affected field or artifact is not honored and the verified level is computed as if it were absent (). The key-binding step resolves seal.kid to a verified key identity; the resolution mechanism (a local key store or profile-defined discovery) is out of scope for Core.

Verifier result and verdict A verifier computes a verified_level and emits a verdict:

The schema validates structure; the verifier validates the claimed level. A missing or unbound top-level evidence artifact required by the claimed level does not by itself cause rejection; it lowers verified_level and yields downgrade (). A verifier result SHOULD carry verdict, claimed_level, verified_level, downgrade_reason (zero or more error-code tokens), and errors (zero or more error-code tokens), with tokens drawn from . The following pseudocode is normative for the order of checks and for the accept/downgrade/reject outcome; it does not mandate a code structure:

Here attainable(boundary_type, claimed_level, evidence) is the claim-relative bound of : the highest level, not exceeding the claimed level, whose own evidence requirements are met -- WL4 only by a bound provenance artifact, WL5 only by a bound independent-verification artifact. A timestamp is invalid when created_at, or any execution timestamp present, is not a syntactically valid tdate per the schema (), or when execution.ended_at precedes execution.started_at. Freshness, skew tolerance, and validity windows are policy concerns, not Core: Core takes no position on how old a record may be. A record without a valid seal.sig is not rejected on that basis alone; for that record the effective Conformance Class is at most CC1 (maxCapability WL0), since a valid signature is a property of CC2 and above (). This is deliberate: an unsigned record can be structurally valid, but nothing binds its content to a producer, so it grounds no execution-evidence claim. A seal.sig that is present but cryptographically invalid, or present with an absent or unsupported seal.alg, or present without seal.kid, is rejected.

Composition For a chain of segments, the verified level is the minimum over segments:

Aggregation MUST NOT inflate the level: a chain MUST NOT be assigned a level higher than the lowest level any of its segments supports.

Downgrade target for missing required evidence At the conditional-required + evidence-lift step (), if any evidence required by the claimed level -- a conditional-required field () or a bound top-level artifact -- is absent, the verifier MUST NOT reject solely on that basis; it MUST instead downgrade the verified level to the highest level, not exceeding the claimed level, whose own evidence requirements are met (the claim-relative attainable level of ): claimed WL5, a provenance artifact present but no independent-verification path -> WL4; claimed WL4 or WL5 with neither artifact -> the level grounded by the boundary alone; claimed WL4 with an independent-verification path but no provenance artifact -> the level grounded by the boundary alone: an independent-verification artifact satisfies WL5, not WL4, and a level above the claim is never assigned. The same rule applies below the lift levels: a claimed WL1-WL3 whose conditional-required fields () are absent is downgraded to the highest level, not exceeding the claim, whose requirements are met; a field or artifact whose hash algorithm is unsupported is treated as absent for this purpose (). For example, a record claiming WL3 at an execution-ownership boundary with no execution block is downgraded to WL2 when input.arguments_hash is present, and to WL0 when it is not. When neither artifact is present, the floor is at most the boundary's base execution level (), provided the corresponding conditional-required fields () are present: WL1 for an intent or approval boundary, WL2 for an invocation boundary, and WL3 for an execution-ownership boundary (host-hook, kernel, tool-runtime, tee). For example, a tee record claiming WL5, whose independent-verification artifact is absent or unbound and which carries no provenance artifact, is downgraded to WL3: the attestation grounds execution ownership (WL3) but, absent a bound independent-verification artifact, does not support WL5. A level downgraded in this way propagates through composition under the non-inflation rule (): a chain is never assigned a level higher than the lowest its segments support.

Safe failure Unknown fields or extensions marked critical: true MUST fail closed, with error E_UNKNOWN_CRITICAL_EXTENSION. Unknown non-critical extensions MAY be ignored. A verifier MUST NOT accept unknown critical content partially, heuristically, or as non-critical content.

Implementation Status This section records the implementation status of WEXP, in the spirit of . It is informational and is to be removed before publication as an RFC. The reference implementation of WEXP is being developed by WitSeal: a witnessed-execution runtime implemented in TypeScript. The runtime today produces signed, hash-chained execution receipts in its v0.2 lineage format (policy-decision capture, approval state, artifact and result digests); these receipts are a compatibility lineage, not WEXP Core Records. A WEXP-conformant Core Record emitter and an offline verifier implementing the ladder of are the next implementation milestone, tracked against this document. A prospective design-partner deployment is evaluating WEXP across the WL0-WL3 boundaries. Implementation status is informational and does not affect the specification's standing.

Security Considerations WEXP grades the strength of evidence about execution. It does not certify the correctness, safety, or alignment of the action. Implementers and relying parties MUST NOT treat a WEXP record as more than an execution-evidence claim at its stated level. In particular: Provenance is not runtime. A provenance artifact establishes origin/build, not that a specific runtime action occurred. Conflating the two is the error E_PROVENANCE_RUNTIME_CONFUSION; this code belongs to the policy layer -- it names a relying-party interpretation error, is not emitted by the Core verifier ladder, and its registered default handling is policy. Attestation is not semantic correctness. Remote attestation can establish environment identity/integrity, not that the executed action was correct. A hash is not payload truth. A hash-only payload proves integrity of a referenced object, not the truth of its contents. Boundary assertion. As stated in , a record does not prove that the declared boundary matches the actual execution environment; this is grounded externally (CC3+/attestation), not by the record. These non-claims are normative limits on interpretation, not optional caveats. Consistent with , WEXP does not address an adversarial executor that refuses to produce a record at its boundary, operator collusion across all roles, or model alignment. Under WEXP these do not yield a positive claim: missing or unobtainable evidence produces a downgraded or rejected verdict, never an inflated one. A transparency-log receipt establishes existence and content at registration, not the truth of the underlying claim; a self-asserted record does not establish that user intent was satisfied; a complete trace does not establish that authorization was valid. In particular, a transparency receipt alone does not constitute the independent-verification artifact required for WL5: a transparency log MAY carry or timestamp such an artifact, but WL5 requires an independent verification of the execution-evidence claim itself (). WEXP forbids these inferences (non-inflation). Independent custody of a record (for example, third-party countersigning or transparency-log registration) and independent observation of an executed effect (for example, attestation by a receiving counterparty) strengthen evidence in different ways: the former makes the record's custody independent while its content remains as originated; the latter corroborates the observed effect itself. Both are graded, like all other evidence, under the honesty invariants above and never inflate a claim. A note on privacy and selective disclosure. WEXP references execution content by hash: input.arguments_hash and result commitments pin claims to specific payloads without storing them (the Minimal Evidence floor). Verification of integrity and claim strength therefore proceeds on hashes and record structure alone, and deployments may keep content fields opaque across administrative or domain boundaries. Profiles may add selective-disclosure mechanisms; Core neither requires nor precludes them. Hashes and digests are integrity commitments, not confidentiality mechanisms; low-entropy or guessable payloads may be vulnerable to dictionary or correlation attacks. Privacy-sensitive profiles SHOULD use salted commitments, keyed commitments, encryption, or selective disclosure. A note on algorithm migration and long-lived evidence. The signature algorithm lies on the authenticity axis (Conformance Class), not the witnessability axis: a stronger algorithm does not raise WL, and non-inflation holds. The relevant quantum-era threat to signed records is not retrospective decryption but future forgery: records signed with a classical algorithm remain verifiable, but once that algorithm is broken an adversary can forge new records, including backdated ones. Durable evidentiary force therefore comes from contemporaneous anchoring -- a transparency registration or an independent countersignature fixed while the algorithm is unbroken (see the custody discussion above) -- and from algorithm migration via seal.alg and profiles, not from any single algorithm choice made today.

IANA Considerations This document defines registries for WEXP boundary types, error codes, and WEXP profiles. This revision specifies the WEXP Boundary Types registry and seeds the WEXP Error Codes registry; the WEXP Profiles registry is reserved here and specified in a subsequent revision. This document does not request a Conformance Classes registry: the classes CC0-CC5 are defined by this document (). All registries in this section use the Specification Required registration policy.

WEXP Boundary Types IANA is requested to create the WEXP Boundary Types registry. Each entry has a Boundary Type identifier, an Execution Level (the base execution-evidence level the boundary grounds, used as base_execution_level(boundary_type) in the Boundary Ceiling invariant of ), and a description of the control surface the boundary observes. The Execution Level is a base level, not a grant of the maximum claim: WL4 and WL5 are reached only by adding a bound top-level provenance or independent-verification artifact (, ). The registry is initialized with the following values: Boundary Type Execution Level Description manual-approval WL1 Recorded human approval, captured out of band; witnesses intent or authorization, not invocation or execution. proxy WL2 Interposed invocation mediator (e.g. API or tool proxy); witnesses that a call crossed the boundary, not execution outcome. workflow WL2 Workflow or orchestration engine recording step transitions; witnesses invocation and ordering, not in-process execution. Activity-owned execution should use host-hook or tool-runtime as appropriate. host-hook WL3 In-host instrumentation (runtime, ABI, or syscall hook); witnesses execution start, outcome, and result commitment. A bound provenance artifact lifts to WL4; a bound independent-verification artifact lifts to WL5. kernel WL3 Kernel-level mediation at the OS boundary; witnesses execution. A bound provenance artifact lifts to WL4; a bound independent-verification artifact lifts to WL5. tool-runtime WL3 Tool or agent runtime performing the action in process; records execution directly. A bound provenance artifact lifts to WL4; a bound independent-verification artifact lifts to WL5. tee WL3 Trusted execution environment owning execution; grounds WL3. Its attestation MAY contribute to a bound independent-verification artifact lifting to WL5 (and a bound provenance artifact lifts to WL4) when profile-defined, independently appraised, present, and bound. The Execution Level is the base level a boundary grounds, not a grant of the maximum claim. By and , a WL4 claim still requires a bound provenance artifact and a WL5 claim a bound independent-verification artifact, each carried as top-level evidence. WL4 and WL5 are therefore reachable at any execution-ownership boundary (host-hook, kernel, tool-runtime, tee) when the corresponding artifact is present and bound; a tee attestation is one source of the WL5 independent-verification artifact, not a privileged path. Where the required artifact is absent or not bound to the record, a verifier downgrades or rejects the record (, ) rather than honoring a nominal level. A boundary label by itself never raises the claimable level above the base execution level.

WEXP Error Codes IANA is requested to create the WEXP Error Codes registry, with the Specification Required policy. Each entry has an error-code token, a default handling disposition (reject, downgrade, or policy), and a reference to its defining specification. The default handling indicates how a conforming verifier treats the condition absent an overriding profile or policy (). This revision registers the error codes used normatively in this document: Error Code Default handling Reference E_INVALID_SCHEMA reject (this document) E_CANONICALIZATION_FAILED reject (this document) E_UNSUPPORTED_ALGORITHM reject (this document) E_INVALID_SIGNATURE reject (this document) E_KEY_BINDING_FAILED reject (this document) E_TIMESTAMP_INVALID reject (this document) E_UNKNOWN_BOUNDARY_TYPE reject (this document) E_MISSING_CAPABILITIES downgrade (this document) E_CAPABILITY_BELOW_CLAIM downgrade (this document) E_BOUNDARY_CEILING_EXCEEDED downgrade (this document) E_MISSING_REQUIRED_EVIDENCE downgrade (this document) E_EVIDENCE_NOT_BOUND downgrade (this document) E_RECORDER_CEILING_EXCEEDED downgrade (this document) E_CHAIN_INFLATION downgrade (this document) E_UNKNOWN_CRITICAL_EXTENSION reject (this document) E_PROVENANCE_RUNTIME_CONFUSION policy (this document)

WEXP Profiles (reserved) The WEXP Profiles registry is reserved by this document and will be specified in a subsequent revision under the Specification Required policy. The Conformance Classes CC0-CC5 are defined normatively in ; this document does not request an IANA registry for them. No values are registered here. Unknown registered values MUST be handled deterministically. Profiles MUST NOT introduce unregistered boundary types without a corresponding registry update.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Deposited with SSRN; public posting pending at the time of this draft. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. ScopeBlind (Veritas Acta) This document defines a portable, cryptographically signed receipt format for recording machine-to-machine access control decisions. Each receipt captures the identity of the decision maker, the tool or resource being accessed, the policy evaluation result, and a timestamp — all signed with Ed25519 [RFC8032] and serialized using deterministic JSON canonicalization [RFC8785]. The format is designed for environments where AI agents invoke tools on behalf of human operators, particularly the Model Context Protocol (MCP) ecosystem. Receipts are independently verifiable without contacting the issuer, enabling offline audit, regulatory compliance, and cross-organizational trust federation. Asqav This document defines a multi-jurisdiction compliance profile of the signed action receipt format used by AI agents to record machine- readable evidence of access-control decisions. The profile binds receipt fields to two regulatory surfaces: on the European Union side, Articles 12 and 26 of the EU AI Act (Regulation (EU) 2024/1689) and Article 17 of DORA (Regulation (EU) 2022/2554); on the United States side, the NIST AI Risk Management Framework, the Colorado AI Act, the Texas Responsible AI Governance Act, the New York Department of Financial Services Cybersecurity Regulation (23 NYCRR Part 500), the HIPAA Security Rule, SEC Rule 17a-4, and the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA). Working entirely within the existing wire format, canonicalization transformation, and signing algorithms of the underlying receipt format, the profile tightens a subset of the OPTIONAL fields to REQUIRED, imposes a retention floor, and requires at least one timestamping anchor (RFC 3161 or OpenTimestamps). It registers OPTIONAL extension fields for risk and incident classification, cross-agent envelope binding, per-action freshness and integrity, build provenance, threat-framework taxonomy, server-built enforcement attestation, producer-asserted risk acceptance, and producer-asserted code authorship, each subject to false-attestation guards where applicable, and registers receipt type namespaces for passive- telemetry, result-bound observation, risk-acceptance, and code- authorship receipts. The full field set and its normative requirements are defined in the body of this document. TK Collective This document specifies the verification.* constraint family --- a pre-action, fail-closed gate primitive for AI agent decisions, sibling in shape to the environment.* family used in Verifiable Intent specifications. A verification.* receipt is a JWS-signed artifact ([RFC7515]) carrying a canonical input, a derived binary act/halt output, and a versioned mapping identifier that binds them. A relying party recomputes the gate locally from signed primitives under the named mapping; the verifier never trusts the issuer's runtime. This shape provides decision explainability and traceability evidence aligned with EU AI Act Article 12 record- keeping obligations and with the Decision Explainability tier of Anthropic's Zero Trust for AI Agents framework [ANTHROPIC-ZT]. The format is forward-compatible across mapping revisions: receipts signed under one mapping ID remain verifiable as correct-under-that- mapping after newer mappings ship. Autonomous agents based on large language models increasingly perform consequential tasks on behalf of humans and other agents. Demonstrating that recorded agent behavior truthfully represents actual behavior is essential for accountability, compliance, and human oversight. This document defines a data format for verifiable agent conversation records using CDDL, with representations in both JSON and CBOR. The format captures session metadata, message exchanges, tool invocations, reasoning traces, and system events in a structured, extensible CDDL definition for verifiable agent conversation records. COSE is used as the signing method to allow for native interoperability in SCITT Transparency Services and the CDDL definition allows for seemless integration in Evidence as specified in RFC 9334. The specification supports cross-vendor interoperability by defining a common representation that accommodates translation from multiple existing agent implementations with distinct data structure layouts that are typically represented in JSON. Autonomous AI agents execute actions — file writes, API calls, shell commands — on behalf of human principals. No standard mechanism exists for a third party to verify that an agent acted within its declared behavioral rules, that policy enforcement occurred before execution (not after), or that the action log has not been tampered with after the fact. This document defines the Proof-of-Behavior (PoB) protocol: a minimal, language-agnostic standard for tamper-evident audit trails and pre-execution policy enforcement in AI agent systems. The protocol specifies a signed receipt format, a hash-chain linking scheme, a policy gate contract, and a cross-agent reference mechanism. Authproof This document defines the Delegation Receipt Protocol (DRP), a cryptographic authorization primitive for AI agent deployments. Before any agent action executes, the authorizing user signs an Authorization Object containing scope boundaries, time window, operator instruction hash, and model state commitment. This signed receipt is published to an append-only log before the agent runtime receives control. The protocol reduces reliance on the operator as a trusted intermediary by making the user's private key the sole signing authority over the delegation record. Cisco Systems Fraunhofer SIT MIT Linaro Intel This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

SCITT Mapping (WL4-WL5) This appendix is informative. WEXP is complementary to supply-chain transparency efforts. It maps WEXP WL4-WL5 evidence to SCITT vocabulary, so that a WEXP provenance artifact (WL4) and an independent-verification path (WL5) can be expressed against, or cross-checked with, a SCITT transparency service. WEXP remains a meta-layer over such services: it classifies what their receipts can honestly claim, rather than competing with them. Detailed field-level mapping will be provided in a subsequent revision.

Mapping to the AI Agent Audit Architecture This appendix is informative. WEXP relates to the proposed work items of in two distinct modes. At the contribution points WEXP supplies semantics the architecture does not define; at the composition points WEXP consumes an existing substrate without adding core semantics. WEXP does not redefine identity, attestation, transparency, or context-propagation substrates.

Contribution points (WEXP supplies what the data models do not define) WI-1 (Audit Data Models and Semantics): WEXP contributes the evidential-status semantics absent from the record structure -- the boundary-derived claim ceiling (verified_level <= attainable(boundary_type, claimed_level, evidence)), the verifier verdict of accept, reject, or downgrade, non-inflation under composition, and fail-closed handling of unknown-critical content. WEXP is a semantic layer for WI-1, not a competing data model. WI-4 (Action Record Profile): WEXP contributes a claimed_level bound to the boundary_type at which the action took effect, so that an Action Record produced "at the boundary" cannot claim more than that boundary can honestly witness. Placement (WI-4's concern) and claim strength (WEXP's contribution) are distinct.

Composition points (WEXP consumes an existing substrate; no core semantics added) WI-6 (Profile of RATS Evidence): WEXP consumes RATS Evidence and Attestation Results as environmental evidence inputs. RATS is not required by WEXP Core; profiles MAY use attestation evidence to ground a higher published Conformance Class, which Core still resolves only through capabilities_ref (). WEXP adds no attestation semantics of its own here. WI-7 (Profile of SCITT Transparency): WEXP treats a SCITT receipt as custody/existence evidence -- it establishes existence and content at registration, not the truth of the underlying claim. A WEXP record MAY be carried as a SCITT-registered payload or a receipt-bound artifact. WEXP defines no transparency service. WI-11 (Audit Context Propagation): WEXP uses audit trace, parent, and delegation-chain references as context bindings only. Correlation is not proof of authorization; WEXP does not treat propagated context as a positive claim.

Record/role mapping AUDIT Architecture record/role WEXP role Mode Interaction Record evidence input (interaction-scoped) input Action Record (boundary of effect) boundary-observation evidence; boundary sets ceiling contribution (WI-4) Delegation Record authority-chain evidence (correlation, not proof) input Authorization Transition Record temporal-authorization evidence input Audit Context (trace/parent/OBO) context binding -- correlation, not proof composition (WI-11) RATS Evidence / Attestation Result environmental evidence input (not required by Core) composition (WI-6) SCITT Receipt custody/existence evidence (not truth-of-claim) composition (WI-7) Auditor verifier (accept / reject / downgrade) contribution (WI-1) verification result portable bounded-claim execution receipt output

Design Rationale (non-normative) This appendix preserves internal design-record provenance for the frozen Core decisions. These records are non-normative and do not alter the requirements above. Frozen Core rationale marker Non-normative rationale preserved here WEXP-R-01 Criticality, reversibility, operational domain, and custody are not WEXP axes. They may influence policy or profile requirements, but they are not witnessability levels. WEXP-R-02 Policy is orthogonal to Witnessability Level and is profile-scoped. At WL2, policy and timing are optional and are not Core-required. WEXP-R-03 Conformance Class is not a per-record self-claim; it is reachable only by reference, for example through capabilities_ref. WEXP-R-04 A Core record validates standalone, without a profile. WEXP-R-05 WL4 and WL5 evidence is honored only when carried as top-level evidence; it is never carried in extensions. WEXP-R-06 WL2 requires input.arguments_hash only as invocation evidence. Policy and timing remain optional at Core level. WEXP-R-07 WL1 (Intent) requires input.arguments_hash so the intent claim is bound to specific arguments. Without this commitment an Intent claim would be a bare, non-falsifiable self-assertion, since arguments could be substituted later against the same record; the hash pins the claimed intent without storing the raw payload (Minimal Evidence floor). At WL2 the same hash additionally serves as invocation evidence.

Disclosure One author, Mikhail Sergeev, has a commercial interest in execution-evidence and runtime-assurance tooling. WitSeal is the reference implementation of WEXP. This specification presents a vendor-neutral open protocol and does not describe, evaluate, or endorse any specific proprietary implementation.