The Witnessed Execution Protocol (WEXP): Core Specification

2.1. 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 (Section 4.1.1).¶

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, [SCITT]), 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 (Section 8).¶

2.2. Relationship to Related Work

[AUDIT-ARCH] 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 [AUDIT-ARCH] does not specify. In [AUDIT-ARCH] 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, [ACTA-RECEIPTS], defines a portable signed receipt format for machine-to-machine access-control decisions. A subsequent profile, [ASQAV-COMPLIANCE], binds [ACTA-RECEIPTS] fields to specific regulatory obligations including EU AI Act Articles 12 and 26 and DORA Article 17. WEXP is complementary to both: [ACTA-RECEIPTS] 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 [ACTA-RECEIPTS] 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 [AGENT-AUDIT-TRAIL], which specifies a hash-chained logging format with trust outcome levels, and [VERIFICATION-STATE], which specifies a pre-action fail-closed gate primitive that may be wrapped in a [SCITT] envelope. WEXP is complementary to these: [AGENT-AUDIT-TRAIL] specifies how audit records are stored and chained; [VERIFICATION-STATE] 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 [VAC], a conversation-record format for agent sessions with post-hoc divergence detection; [POB], which combines signed behavior receipts, hash-chain linking, and a pre-execution policy gate; and [DRP], 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 [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 [AR4SI] 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 (Appendix B). Neither scheme defines a claim ceiling bound to the execution boundary of a specific action; that is the layer WEXP specifies.¶

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

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

verified_level <= min(
    attainable(boundary_type, claimed_level, evidence),
    maxCapability(CC) )

6.1. 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 Section 8.1 and Section 8.2.1). 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 Section 5, 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 (Section 7).¶

6.2. Core Record schema (CDDL)

The following CDDL ([RFC8610]) 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 (Section 6.1) and the honesty invariants (Section 7) are additional constraints the verifier enforces beyond structural validation.¶

wexp-core-record = {
  protocol: tstr,
  protocol_version: tstr,
  record_id: tstr,
  created_at: tdate,
  event: event-block,
  subject: subject-block,
  model: model-block,
  witness: witness-block,
  seal: seal-block,
  disclosure: disclosure-block,
  ? capabilities_ref: tstr, ; reference to published CC capabilities
  ? input: input-block,     ; required at WL1 and WL2
  ? execution: execution-block, ; required at WL3
  ? evidence: evidence-block,   ; top-level evidence only
  ? extensions: extensions-map,
}

; claimed_level encoding (ratified): string form
WL = "WL0" / "WL1" / "WL2" / "WL3" / "WL4" / "WL5"
; Comparison semantics (informative): "WLn" maps to integer n for the
; honesty invariants. The verified level is bounded by
;   min( claimed, attainable(boundary_type, claimed, evidence),
;        maxCapability(CC), recorder_ceiling, chain_min )
; Implementations MUST parse "WLn" as integer n for ordering
; comparisons, then re-encode as string in records.

; Hash-alg identifier; "sha-256" is the default. Each hash field
; carries its own algorithm so the record is self-describing.
hash-alg = "sha-256" / tstr

; All octet strings in JSON serialization (seal.sig, *_hash, digest)
; are encoded as base64url WITHOUT padding.

event-block = { operation: tstr, event_type: tstr }
subject-block = { agent_id: tstr, host_id: tstr }
model-block = { boundary_type: tstr, claimed_level: WL }

; witness / seal / disclosure internal fields are refined by
; profiles; beyond the mandatory identifiers below they are open
; maps pending field-byte alignment.
; id identifies the witnessing component or system (opaque).
witness-block = { id: tstr, * tstr => 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 (Section 5).¶

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

7.1. 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 (Section 11.1): 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 Section 6.1; 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:¶

attainable(boundary_type, claimed_level, evidence):
  base = base_execution_level(boundary_type)
  best = WL0
  for n in WL1..WL3:
    if n <= base and n <= claimed_level and
       the conditional-required fields for n are present:
        best = n
  if base >= 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 (Section 4.1.1), the recorder ceiling (Section 7.2), and the composition minimum (Section 8.2):¶

verified_level <= min(
    claimed_level,
    attainable(boundary_type, claimed_level, evidence),
    maxCapability(CC),
    recorder_ceiling,
    chain_min )

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

7.2. Recorder Ceiling (MUST when asserted)

Core reserves a recorder-ceiling slot in the verified-level bound (Section 8) 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:¶

claimed_WL <= max_assurance(qualification_profile)

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

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

8.1. Verifier result and verdict

A verifier computes a verified_level and emits a verdict:¶

claimed_level  = model.claimed_level
verified_level = level supported by structure, signature,
               key binding, base execution level, present
               bound evidence, Conformance Class capability,
               recorder ceiling, and chain minimum
verdict:
  reject    if the record cannot be safely interpreted or trusted
  accept    if verified_level == claimed_level
  downgrade if verified_level <  claimed_level and the record remains
            safely interpretable

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 (Section 8.2.1). 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 Section 11.2.¶

The following pseudocode is normative for the order of checks and for the accept/downgrade/reject outcome; it does not mandate a code structure:¶

if structure invalid:             reject(E_INVALID_SCHEMA)
if unknown critical extension:  reject(E_UNKNOWN_CRITICAL_EXTENSION)
if canonicalization fails:        reject(E_CANONICALIZATION_FAILED)
if timestamp invalid:             reject(E_TIMESTAMP_INVALID)
if boundary_type unregistered:    reject(E_UNKNOWN_BOUNDARY_TYPE)

; signature: absence is not an error (it caps the effective CC
; for this record); a present-but-invalid signature is rejected.
if seal.sig present:
    if seal.alg absent/unsupported: reject(E_UNSUPPORTED_ALGORITHM)
    if signature invalid:              reject(E_INVALID_SIGNATURE)
    if key binding fails:              reject(E_KEY_BINDING_FAILED)
    signed = true
else:
    signed = false

cc = resolve(capabilities_ref)        ; implementation-scoped CC
if cc unresolved or not accepted: cc = CC0  ; E_MISSING_CAPABILITIES
; a record without a valid signature is evaluated at most as
; CC1 (this record only)
effective_cc = cc if signed else min(cc, CC1)

base = min( claimed_level,
            attainable(boundary_type, claimed_level, evidence),
            maxCapability(effective_cc) )
if recorder qualification asserted:
    base = min( base, max_assurance(qualification_profile) )
verified_level = base
if a chain is supplied:
    verified_level = min( verified_level,
                       min over segments( segment.verified_level ) )

if verified_level == claimed_level: accept
else:                               downgrade

Here attainable(boundary_type, claimed_level, evidence) is the claim-relative bound of Section 7.1: 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 (Section 6.2), 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 (Section 4.1). 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.¶

8.2. Composition

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

Level(chain) = min over segments( verified_level )

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

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

11.1. 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 Section 7.1), 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 (Section 7.1, Section 7.4.1). The registry is initialized with the following values:¶

The Execution Level is the base level a boundary grounds, not a grant of the maximum claim. By Section 6.1 and Section 7.4, 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 (Section 8, Section 7.4) rather than honoring a nominal level. A boundary label by itself never raises the claimable level above the base execution level.¶

11.2. WEXP Error Codes

IANA is requested to create the WEXP Error Codes registry, with the Specification Required [RFC8126] 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 (Section 8.1). This revision registers the error codes used normatively in this document:¶

11.3. WEXP Profiles (reserved)

The WEXP Profiles registry is reserved by this document and will be specified in a subsequent revision under the Specification Required [RFC8126] policy. The Conformance Classes CC0-CC5 are defined normatively in Section 4.1; 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.¶

12.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, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

12.2. Informative References

[ACTA-RECEIPTS]

Farley, T., "Signed Decision Receipts for Machine-to-Machine Access Control", Work in Progress, Internet-Draft, draft-farley-acta-signed-receipts-02, 28 June 2026, <https://datatracker.ietf.org/doc/html/draft-farley-acta-signed-receipts-02>.

[AGENT-AUDIT-TRAIL]

Sharif, R., "Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems", Work in Progress, Internet-Draft, draft-sharif-agent-audit-trail-00, March 2026, <https://datatracker.ietf.org/doc/html/draft-sharif-agent-audit-trail-00>.

[AR4SI]

Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V. Scarlata, "Attestation Results for Secure Interactions", Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-10, 18 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-ar4si-10>.

[ASQAV-COMPLIANCE]

Marques, J. A. G., "Compliance Profile of Signed Action Receipts for AI Agents", Work in Progress, Internet-Draft, draft-marques-asqav-compliance-receipts-06, 1 July 2026, <https://datatracker.ietf.org/doc/html/draft-marques-asqav-compliance-receipts-06>.

[AUDIT-ARCH]

Kuehlewind, M. and H. Birkholz, "An Architecture for Auditing AI Agent Delegation and Interactions", Work in Progress, Internet-Draft, draft-kuehlewind-audit-architecture-00, May 2026, <https://datatracker.ietf.org/doc/html/draft-kuehlewind-audit-architecture-00>.

[DRP]

Nelson, R., "Delegation Receipt Protocol for AI Agent Authorization", Work in Progress, Internet-Draft, draft-nelson-agent-delegation-receipts-10, 13 June 2026, <https://datatracker.ietf.org/doc/html/draft-nelson-agent-delegation-receipts-10>.

[POB]

Dembowski, J., "Proof-of-Behavior Protocol for Autonomous AI Agents", Work in Progress, Internet-Draft, draft-dembowski-agentledger-proof-of-behavior-00, 20 April 2026, <https://datatracker.ietf.org/doc/html/draft-dembowski-agentledger-proof-of-behavior-00>.

[RFC7696]

Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, <https://www.rfc-editor.org/rfc/rfc7696>.

[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, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[SCITT]

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, <https://www.rfc-editor.org/rfc/rfc9943>.

[SLSA]

"Supply-chain Levels for Software Artifacts (SLSA)", <https://slsa.dev>.

[VAC]

Birkholz, H., Heldt, T., and O. Steele, "Verifiable Agent Conversation Records", Work in Progress, Internet-Draft, draft-birkholz-verifiable-agent-conversations-00, 25 February 2026, <https://datatracker.ietf.org/doc/html/draft-birkholz-verifiable-agent-conversations-00>.

[VAP-LAP]

Yamakawa, A., "Verifiable AI Provenance (VAP) Framework and Legal AI Profile (LAP)", Work in Progress, Internet-Draft, draft-ailex-vap-legal-ai-provenance-03, March 2026, <https://datatracker.ietf.org/doc/html/draft-ailex-vap-legal-ai-provenance-03>.

[VERIFICATION-STATE]

Krausz, J., "The verification.* Constraint Family: Pre-Action Fail-Closed Gates for AI Agent Decisions", Work in Progress, Internet-Draft, draft-krausz-verification-state-01, 12 June 2026, <https://datatracker.ietf.org/doc/html/draft-krausz-verification-state-01>.

[WIMSE]

"WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft-ietf-wimse-workload-creds-02, July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-02>.

[WITNESSABILITY]

Sergeev, M. A. and V. Ikher, "Toward a Witnessability Model for AI and Software Execution Systems: A Boundary-Based Framework for Classifying Execution Evidence", SSRN Abstract 6994720, 2026, <https://ssrn.com/abstract=6994720>. Deposited with SSRN; public posting pending at the time of this draft.

B.1. 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.¶

B.2. Composition points (WEXP consumes an existing substrate; no core semantics added)

WI-6 (Profile of RATS Evidence): WEXP consumes RATS [RFC9334] 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 (Section 4.1.1). WEXP adds no attestation semantics of its own here.¶

WI-7 (Profile of SCITT Transparency): WEXP treats a SCITT [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.¶

B.3. Record/role mapping