WEXP Core: Witnessability Appraisal Semantics for Execution-Related Claims

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 26 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Software and AI systems produce logs, traces, approvals, tool-call records, attestations, provenance statements, and transparency receipts. These artifacts answer different questions and are often treated as if they were interchangeable. An authentic record can contain an unsupported claim; a provenance statement can identify origin without proving a runtime event; and an independently verifiable invocation remains evidence of invocation rather than execution.¶

WEXP provides a bounded appraisal layer. Given normalized findings about an exact action, a claimed content base, an evidence-producing boundary, and any applicable provenance or independent-verification evidence, WEXP determines the set of exact claims that the findings support. It then compares the asserted claim with that set and returns one of three verdicts. The result grades support for a claim. It does not certify correctness, safety, authority, policy compliance, or alignment.¶

The conceptual basis for this work is the Witnessability Model [WITNESSABILITY] under the Witnessability Conceptual Core [WCC-CORE]. Section 1.3 identifies the scope and limits of that relationship. This document is self-contained: conceptual publications are informative and are not required to implement the normative appraisal procedure. WEXP retains the project identifier introduced as the Witnessed Execution Protocol; the title of this revision identifies the appraisal role of its Core.¶

This Informational document specifies a carrier-neutral appraisal contract. Its normative requirements apply when claiming conformance to that contract; they do not designate an Internet Standards Track protocol. The companion Coverage document is Experimental because its bounded coverage-evaluation approach requires experimental evaluation of operational assumptions and interoperability.¶

Carrier artifacts and appraisal parameters (data)
        |
        v
Mapper implementing a carrier or evidence profile
  parse, authenticate, evaluate profile predicates,
  bind findings to an exact target and base
        |
        v
Normalized Appraisal Input (data)
        |
        v
WEXP Appraisal Core (procedure)
        |
        v
Witnessability Appraisal (data)

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Action Target

The exact action, decision, invocation, execution, or observed event to which a claim and its supporting findings are bound. Core treats the target as opaque and defines no identifier format.¶

Content Base

The kind of action-related content asserted by a claim: observation, intent, invocation, or execution.¶

Qualifier

An additional property of evidence supporting an exact content claim. A qualifier does not change the content base.¶

Normalized Evidence Fact

A profile-produced finding with an exact target, an exact content base or qualifier role, an evaluation status, basis references, and limitations.¶

Boundary Ceiling

The strongest content base that the accepted evidence-producing boundary can warrant. It excludes stronger claims but never creates support.¶

Boundary Grounding

The reported grounding class of a boundary finding: asserted-only, attributed, attested, or not-evaluated. It records the kind of grounding reported under the applicable profile and context, not a guarantee that the boundary is true or controlled by the asserted actor. It is distinct from the groundedness of an argument graph in [WCC-CORE]. The fixed rejection result uses unavailable, as specified in Section 8.4.¶

Exact Support

Support established by the predicate for the same action target, content base, qualifier set, and evaluation context as the claim.¶

Witnessability Appraisal

The result produced by the Core procedure, including the supported claim set, verdict, reasons, evaluation gaps, limitations, boundary information, and evaluation context.¶

3. Conformance Surfaces

This document distinguishes Core-appraiser conformance from mapping-profile, composition-profile, carrier, and result-carrier conformance. Section 12 defines the evidence required for a Core-appraiser claim. Each other claim identifies the exact profile and the obligations it covers.¶

A capability declaration describes the assessments represented by a normalized input. It MUST NOT be used as positive evidence, as a structural ceiling on claims, or as a sort key over claims. An unperformed assessment is reported through its exact status and applicable evaluation gap; a verdict alone MUST NOT replace that information.¶

This revision defines no numbered Conformance Classes. An implementation of the complete Core-appraiser surface need not implement a native carrier or a composition profile. Conversely, implementing a carrier or profile does not establish Core-appraiser conformance. Producer capability declarations remain matters for their identified profiles.¶

4. Claim Model

observation < intent < invocation < execution

(observation, {})       (observation, {IV})
(intent, {})            (intent, {IV})
(invocation, {})        (invocation, {IV})
(execution, {})         (execution, {PROV})
(execution, {IV})       (execution, {PROV, IV})

(b1, A1) <= (b2, A2)  iff  b1 <= b2 and A1 is a subset of A2

5. Presentation and Display Projection

The authoritative form of a claim in this document is its typed state: the pair of a content base and a set of evidence qualifiers, written in the tuple notation of Section 4, with parentheses around the pair and braces around the qualifier set. This is the canonical form for showing qualified states.¶

A carrier that also exposes a single bare display label MUST NOT emit a record in a qualified state without carrying that record's authoritative typed state alongside the label. A bare display label is a projection of the typed state; it is never the authority for it, and it is never a sort key.¶

Where a display label is produced, it MUST be produced by a declared projection with the following properties. The projection is profile-defined and justified: this document presumes no total order over typed states, and any projection into one requires justification by the profile that declares it. The projection is version-identifiable: a reader of a display value can determine which revision of which projection produced it. The projection never exceeds the typed state: the label denotes a maximal eligible bare label that is less than or equal to the typed state. When there is more than one such label, the ambiguity is resolved as specified below.¶

Where the declared projection is ambiguous for the state consisting of the execution base with both the provenance and independent-verification qualifiers, the label denotes WL4. Both WL4 and WL5 are maximal bare labels below that state and neither exceeds the other, so the projection alone does not determine the value; this resolution is fixed by this document and is not left to the projection.¶

A display label MUST equal the value of the declared projection applied to the authoritative typed state. Consistency is defined against the projection, not against any tabular image of it. A divergence between a display label and the authoritative typed state is a fatal defect of the carrier representation. The carrier profile rejects that representation and reports its own diagnostic. When the failure prevents construction of a complete AppraisalInput, no Core appraisal is produced. Any Core rejection follows the ordered checks in Section 6.2; a carrier diagnostic is not by itself a Core rejection or a Core reason token.¶

A conforming reader is cautioned that a schema-valid record is not thereby a correctly projected record: schema validity concerns conformance to representation constraints, while a projection concerns semantic continuity between the label and the state. A reader of an earlier revision of this protocol should not assume that a bare label carried there denotes the same state under the projection declared here.¶

6. Normalized Appraisal Input

The set of inputs this document requires is exhaustive for WEXP Core: for each claimed state it is the complete set of Core-required inputs. A profile MAY require more; Core does not. Requirements are keyed on the authoritative typed state of Section 5, never on a display label.¶

Core does not require a commitment to the action's input arguments at the execution level; a claim at the execution level therefore binds the execution, not those arguments. A profile that needs the action's input arguments bound at that level MUST require it. Such a requirement adds a profile-specific input-binding obligation; field presence alone does not satisfy it or change the content base.¶

A mapping profile supplies the following logical input. This is an abstract contract, not a wire schema.¶

AppraisalInput = {
  semantics_version,       ; "wexp-core-2"
  target,
  asserted_claim,
  evaluation_context: {
    id,
    evaluated_at,
    trust_configuration,
    profile_identifiers[]  ; immutable profile revisions;
                           ; bind applicable registries
  },

  boundary_finding: {
    target,
    evaluation_context_ref,
    ? ceiling_base,         ; REQUIRED when status is supported;
                             ; ignored otherwise
    status,                 ; supported | unsupported | not-evaluated
    target_binding,         ; supported | unsupported | not-evaluated
    grounding,              ; asserted-only | attributed | attested |
                             ; not-evaluated
    basis_refs[],
    reasons[],
    limitations[]
  },

  base_findings[]: {
    target,
    evaluation_context_ref,
    base,
    target_binding,         ; supported | unsupported | not-evaluated
    semantic_validation,    ; supported | unsupported | not-evaluated
    basis_refs[],
    reasons[],
    limitations[]
  },

  qualifier_findings[]: {
    target,
    evaluation_context_ref,
    qualifier,              ; PROV | IV
    qualified_base,
    target_binding,
    semantic_validation,
    independence_validation, ; supported | unsupported |
                             ; not-evaluated | not-applicable
    basis_refs[],
    reasons[],
    limitations[]
  },

  recorder_relations[]: {
    profile_identifier,
    relation_token,
    subject_ref,
    object_ref,
    basis_refs[],
    limitations[]
  },
  counter_evidence[]: {
    status,                 ; not-supplied | not-evaluated |
                             ; resolved-no-defeat |
                             ; unresolved-material | defeating
    affected_claims[],      ; or all-admissible-claims
    basis_refs[],
    reasons[],              ; substantive-category profile tokens
    limitations[]
  },
  evaluation_scope,         ; initial-capability-name or
                             ; (profile_identifier, local_name) ->
                             ; evaluated | not-evaluated
  profile_evaluation_gaps[]: {
    target,
    evaluation_context_ref,
    token,
    ? current_scope_capability, ; authenticity | composition;
                                ; absent for inherited gaps
    affected_claims[],      ; or all-admissible-claims
    basis_refs[],
    limitations[]
  },
  inherited_limitations[],
  fatal_conditions[]
}

Every displayed top-level component is REQUIRED. The only semantics version defined by this document is wexp-core-2. Any other text-atom value is fatal and produces E_UNSUPPORTED_SEMANTICS_VERSION. An absent or non-text value is malformed under Section 6.2.¶

The mapping process MUST be claim-independent: it evaluates every available base material and every evidence role, not only the asserted base or asserted qualifiers. This permits an appraisal to report an incomparable supported alternative, such as PROV-supported execution when IV-supported execution was asserted.¶

A passing base or qualifier finding MUST state that the evidence was semantically validated, accepted under the evaluation context, and bound to the exact target and exact base named by the finding. Presence of a reference, a valid digest, a signature, or an artifact whose media type suggests provenance or attestation is insufficient.¶

A profile MUST distinguish unsupported, meaning the relevant assessment ran and failed, from not-evaluated, meaning the assessment was unavailable or outside the evaluation scope. It MUST preserve all applicable limitations and evaluation gaps.¶

All findings are explicitly scoped. The boundary finding, every base and qualifier aggregate, and every profile-gap entry have a target equal to the top-level target and an evaluation_context_ref equal to the top-level evaluation-context identifier. A foreign-scoped aggregate is not negative evidence for this appraisal; it violates the normalized-input cross-field contract and produces E_PROFILE_MAPPING_INVALID. Evidence that was safely evaluated but covers or binds a different target or base is represented by a correctly scoped aggregate with a non-passing status and, when applicable, E_EVIDENCE_COVERAGE_MISMATCH or E_EVIDENCE_NOT_BOUND. The boundary finding additionally requires supported target binding before its ceiling can be used.¶

A normalized input contains exactly one aggregated boundary finding, at most one aggregated base finding for each (target, base, evaluation_context) key, and at most one aggregated qualifier finding for each (target, qualifier, qualified_base, evaluation_context) key. A mapping profile combines multiple raw artifacts into that aggregate and preserves all basis references and limitations. Duplicate or conflicting aggregate findings are fatal and produce E_PROFILE_MAPPING_INVALID.¶

A boundary finding with status = supported MUST contain ceiling_base. Its absence is a profile-mapping failure and produces E_PROFILE_MAPPING_INVALID. A supported boundary has a grounding value of asserted-only, attributed, or attested that the evaluation context accepts. grounding = not-evaluated is valid only with status = not-evaluated; either field paired differently produces E_PROFILE_MAPPING_INVALID. When boundary status is unsupported or not-evaluated, a present ceiling_base is diagnostic carrier metadata only and is ignored by the Core algorithm.¶

A PROV aggregate is valid only when qualified_base = execution and independence_validation = not-applicable. An IV aggregate is valid only when qualified_base is one of the four content bases and independence_validation is supported, unsupported, or not-evaluated. PROV on another base, IV with not-applicable, or another recognized but disallowed qualifier-field combination produces E_PROFILE_MAPPING_INVALID. An unknown closed-enum member or wrong logical type is malformed. A mapper does not delete or repair an invalid qualifier aggregate. A valid qualifier contributes support only when its exact qualified base is independently in B.¶

counter_evidence is an entry set, not a single strongest status. When no counter-evidence was supplied it contains exactly one not-supplied entry with empty affected claims, basis references, reasons, and limitations. Otherwise not-supplied is absent and every entry names at least one admissible affected claim or all-admissible-claims. not-evaluated means supplied counter-evidence could not be assessed; resolved-no-defeat means it was assessed and does not defeat the named claims; unresolved-material means it is material but unresolved; and defeating means it affirmatively defeats the named claims. When the affected claims cannot be narrowed safely, affected_claims is all-admissible-claims. Entries with different affected-claim sets or statuses MUST NOT be collapsed into one status.¶

A challenge process defined outside this document can supply a counter-evidence entry when the applicable profile admits the challenge and binds it to affected claims for this exact target and context. A challenge to the eligibility of a profile or evaluation context is not automatically an action-level counter entry; it can instead require a new context or a new mapping assessment. Core defines neither the challenge process nor its admission policy.¶

Every member of a counter entry's reasons set MUST be a token registered in the substantive category by a registry applicable to the mapping profile and MUST apply to that entry's affected claims. Fatal tokens are carried in fatal_conditions, and evaluation-gap tokens are carried in profile_evaluation_gaps; they MUST NOT appear in counter_evidence[].reasons. A non-Core token resolves uniquely, including category, through exactly one immutable registry revision identified by an applied profile_identifier; absence, ambiguity, or category disagreement produces E_PROFILE_MAPPING_INVALID. Entry reasons are explanatory and do not change the entry status or block a claim by themselves. Core-derived counter-status tokens are emitted in addition to, not instead of, applicable entry reasons.¶

Likewise, every token in reasons[] on a boundary, base, or qualifier finding MUST be registered in the substantive category and apply to that finding. A non-Core token resolves uniquely through an immutable registry revision identified by an applied profile_identifier. Fatal tokens belong in fatal_conditions, and evaluation-gap tokens belong in profile_evaluation_gaps. An absent, ambiguous, unregistered, or miscategorized finding reason is a profile-mapping failure and produces E_PROFILE_MAPPING_INVALID.¶

Every member of fatal_conditions MUST be a token registered in the fatal category by the Core registry or a registry applicable to the mapping profile. Core tokens are bound to the semantics_version; every non-Core token resolves uniquely through an immutable registry revision identified by an applied profile_identifier. An absent, ambiguous, unregistered, or miscategorized member is a profile-mapping failure; the appraiser returns E_PROFILE_MAPPING_INVALID instead of treating that member as fatal.¶

profile_evaluation_gaps carries structured gaps supplied by a mapping or composition profile that are not otherwise recoverable from a Core finding status. Every entry is scoped to the exact target and evaluation context and contains a token registered in the evaluation-gap category, at least one admissible affected claim or all-admissible-claims, basis references, and limitations. A non-Core token resolves uniquely through an immutable registry revision identified by an applied profile_identifier. The optional current_scope_capability is present only when the entry represents the current appraiser's unperformed authenticity or composition assessment; it names exactly that initial capability. The token registration also identifies that same capability: E_COMPOSITION_NOT_EVALUATED is initially registered for composition, while authenticity requires an exact profile token registered for authenticity assessment. A profile can register another evaluation-gap token for either capability. A marker-token capability mismatch produces E_PROFILE_MAPPING_INVALID. Absence of the marker means that the entry is inherited or otherwise diagnostic and does not determine a current capability status. A composition profile uses this field to preserve applicable upstream gaps after remapping them to the exact chain target. The ordered classification in Section 6.2 applies to these entries. A missing member, a wrong logical type, or a malformed atom or set member produces E_MALFORMED_NORMALIZED_INPUT at the structural check. For a structurally valid entry, an empty affected-claim set, an absent, ambiguous, unregistered, or non-evaluation-gap token binding, an incorrect target or evaluation-context scope, a disallowed or mismatched current-scope marker, or an unbound profile-scoped atom produces E_PROFILE_MAPPING_INVALID at the cross-field check. A valid entry is unrelated to this appraisal and is not projected only when its affected claims include none of the asserted claim, a member of SupportedClaims, or all-admissible-claims.¶

7. Boundary Ceiling

For every supported claim (b, A), b MUST NOT exceed the accepted boundary_finding.ceiling_base. Qualifiers do not alter this comparison.¶

supported_content_base <= accepted_boundary_ceiling

The Boundary Ceiling is an exclusion rule, not an evidence source. A boundary finding can prevent a base from being supported; it MUST NOT create a positive base finding. Observation itself requires a positive exact observation finding.¶

An accept or downgrade result MUST preserve the boundary grounding status and its limitations. A reject result instead uses the fixed projection in Section 8.4. A string or structural descriptor asserted by a producer is at most asserted-only; a valid signature associated with an accepted identity can make it attributed; and an applicable boundary-grounding profile can make it attested. Attribution is not proof of actual boundary control.¶

boundary_finding.status = supported means that the boundary predicate required by the named evaluation context passed. The evaluation context MUST identify the minimum acceptable grounding. A profile MUST NOT mark a boundary supported merely because a boundary name or descriptor is present. An asserted-only or attributed finding can be supported only when the evaluation context explicitly accepts that grounding class; the result still reports the weaker grounding and its limitations.¶

The boundary status has deterministic precedence. When status = not-evaluated, no base is added and the appraiser records E_BOUNDARY_NOT_EVALUATED. When status = unsupported, no base is added and it records E_BOUNDARY_NOT_SUPPORTED. Only status = supported with target_binding = supported and matching target and context makes ceiling_base usable. A failed target binding prevents use of the ceiling and adds the Core substantive reason E_EVIDENCE_NOT_BOUND; an unevaluated target binding prevents use of the ceiling and adds the Core gap E_BOUNDARY_NOT_EVALUATED, as specified by Section 8.6.¶

8. Appraisal Procedure

SupportedClaims = {
  (b, A) | b is in B, A is a subset of Q(b),
           and (PROV in A implies b == execution)
}

appraise(input):
  if input is not a logical record or
     semantics_version is absent or not a text atom:
      return rejected_result(E_MALFORMED_NORMALIZED_INPUT)
  if input.semantics_version != "wexp-core-2":
      return rejected_result(E_UNSUPPORTED_SEMANTICS_VERSION)
  if any required wexp-core-2 member, closed enum, logical type,
     set, entry, claim, token, or recorder relation is malformed:
      return rejected_result(E_MALFORMED_NORMALIZED_INPUT)
  if any cross-field invariant enumerated in Section 6.2 fails:
      return rejected_result(E_PROFILE_MAPPING_INVALID)
  if input.fatal_conditions is not empty:
      return rejected_result(input.fatal_conditions)
  if input.asserted_claim is outside the admissible domain:
      return rejected_result(E_CLAIM_OUT_OF_DOMAIN)

  B = {}
  SupportEntries = {}
  for every base finding f, independently of the asserted claim:
      if f.target == input.target and
         f.evaluation_context_ref == input.evaluation_context.id and
         f.target_binding == supported and
         f.semantic_validation == supported and
         input.boundary_finding.status == supported and
         input.boundary_finding.target == input.target and
         input.boundary_finding.evaluation_context_ref ==
             input.evaluation_context.id and
         input.boundary_finding.target_binding == supported and
         f.base <= input.boundary_finding.ceiling_base:
          add f.base to B

  SupportedClaims = {}
  for b in B:
      Q = {}
      if b == execution and
         valid_PROV_finding(input.target, b,
                            input.evaluation_context.id):
          add PROV to Q
      if valid_IV_finding(input.target, b,
                          input.evaluation_context.id):
          add IV to Q
      for every admissible (b, A), A subset of Q:
          add (b, A) to SupportedClaims
          add support_entry((b, A), exact premises, basis,
                            limitations)
              to SupportEntries

  MaximalSupportedClaims = maximal members of SupportedClaims
  asserted_claim_supported = input.asserted_claim in SupportedClaims
  fatal_reasons = {}
  reasons = {}
  GapEntries = {}

  for every non-counter row of the claim-required diagnostic matrix:
      if that row's exact predicate is true:
          if the row is substantive:
              add its token to reasons
          else:
              add its exact Core gap entry to GapEntries

  for every boundary, base, or qualifier finding that is the
      asserted role or an exact premise of a SupportEntry:
      add its registered substantive reasons to reasons

  for every profile gap entry whose affected claims include
      the asserted claim, a member of SupportedClaims, or
      all-admissible-claims:
      add that exact entry to GapEntries

  for c in applicable_counter_entries(input.counter_evidence,
                                       input.asserted_claim):
      reasons = reasons union c.reasons
      if c.status == not-evaluated:
          add gap_entry(E_COUNTER_EVIDENCE_NOT_EVALUATED,
                        input.target, input.evaluation_context.id,
                        c.affected_claims,
                        c.basis_refs, c.limitations)
              to GapEntries
      if c.status == unresolved-material:
          add E_COUNTER_EVIDENCE_UNRESOLVED to reasons
      if c.status == defeating:
          add E_COUNTER_EVIDENCE_DEFEATING to reasons

  gaps = token projection of GapEntries
  limitations = the applicable union defined in Section 8.1

  if asserted_claim_supported and not counter_blocks(
         input.counter_evidence, input.asserted_claim):
      verdict = accept
  else:
      verdict = downgrade

  return Appraisal with every required component

rejected_result(fatal_tokens):
  return Appraisal with verdict = reject,
         semantics_version = "wexp-core-2",
         fatal_reasons = fatal_tokens,
         substantive_reasons = {}, evaluation_gaps = {},
         evaluation_gap_entries = {},
         supported_claims = {}, maximal_supported_claims = {},
         support_entries = {}, support_relations = {},
         asserted_claim_supported = false,
         boundary_ceiling = unavailable,
         boundary_grounding = unavailable,
         target = unavailable, asserted_claim = unavailable,
         recorder_relations = unavailable,
         counter_evidence = unavailable,
         inherited_limitations = unavailable,
         evaluation_context = unavailable,
         evaluation_scope = unavailable

Appraisal = {
  semantics_version,
  verdict,
  fatal_reasons[],
  target,
  asserted_claim,
  asserted_claim_supported,
  support_entries[],
  supported_claims,
  maximal_supported_claims,
  support_relations,
  boundary_ceiling,
  boundary_grounding,
  recorder_relations[],
  substantive_reasons[],
  evaluation_gaps[],
  evaluation_gap_entries[],
  counter_evidence[],
  inherited_limitations[],
  evaluation_context,
  evaluation_scope
}

9. Composition

Composition-profile mapping and Core appraisal are separate conformance surfaces. Core consumes only an ordinary normalized input for the exact chain target; it does not consume raw segments, adjacency records, or warrants and does not infer a chain finding. A Core appraiser can implement the complete Core procedure without implementing a composition profile. An implementation that separately claims composition-profile conformance identifies the immutable composition-profile revision and satisfies the additional mapping obligations in this section.¶

A chain claim MUST NOT be derived by numeric minimum, by a display label, or by a meet of segment states alone. A composition profile MUST identify:¶

• the exact chain target;¶

• the exact segment claims used as premises;¶

• the validated adjacency bindings;¶

• the composition warrant mapping those premises to the chain claim;¶

• the evaluation context shared by the premises; and¶

• the independence of the independent-verification roots relied on by the premises.¶

The identified composition-profile revision defines the logical types and predicates for premises, adjacency bindings, warrants, their exact identity, and their target and context equality. The profile evaluates those values and emits ordinary normalized base and qualifier findings for the exact chain target. The ordinary Core algorithm then appraises those findings; composition is not a second Core appraisal algorithm.¶

A chain base finding is supported only if every named premise is exactly supported and every required binding and warrant evaluates to supported under that immutable profile. An absent or unsupported required adjacency binding produces no positive chain finding; the profile places substantive E_CHAIN_UNBOUND on the correctly scoped non-passing chain-role aggregate. It does the same with E_COMPOSITION_WARRANT_MISSING for an absent or unsupported warrant. Where two premises rely on the same independent-verification root, that root is not independent for the purposes of this warrant, and the profile places substantive E_SHARED_VERIFICATION_ROOT on the correctly scoped non-passing chain-role aggregate. Correctness of the composition operator is not itself a warrant; the warrant consists of the binding, the coverage of the inter-segment link, and the independence of the verification roots. A required assessment that was not performed is represented by a structured E_COMPOSITION_NOT_EVALUATED profile-gap entry affecting the exact chain claim. These are safely interpretable support failures and lead to downgrade when the chain claim is not otherwise supported. If a malformed or internally contradictory chain description still permits a structurally usable Core input, the profile supplies fatal E_CHAIN_DESCRIPTION_INVALID; otherwise the upstream failure produces no Core appraisal under Section 6.2. Individual segment appraisals are unaffected.¶

For this warrant, an independent-verification root is the profile-identified evidentiary source or control dependency whose independence is relied on. It is not merely a public authentication trust anchor. Two premises that repeat one verifier's assessment share an evidentiary root even if they carry different signatures. Conversely, two separately produced assessments do not share an evidentiary root merely because their records authenticate through the same public certification authority; the profile still evaluates their actual observation and control dependencies. A common authentication anchor alone neither establishes nor refutes the independence required by the warrant.¶

For the chain-base warrant described above, an assessed absence or failure of required adjacency, of the warrant, or of the required verification-root independence sets semantic_validation = unsupported on the exact chain-base aggregate and adds the corresponding reason from the preceding paragraphs. The aggregate's target_binding retains the independently assessed binding of the evidence to the exact chain target. A failed inter-segment adjacency is a failed premise of the chain warrant; it is not by itself a failed association with that target. Thus E_CHAIN_UNBOUND does not by itself set target_binding = unsupported. If exact-target binding also fails, that field is independently unsupported. All applicable matrix diagnostics in Section 8.6 are then emitted: for example, an otherwise supported asserted chain base with failed adjacency produces both E_CHAIN_UNBOUND and E_EXACT_CLAIM_NOT_SUPPORTED; it adds E_EVIDENCE_NOT_BOUND only when the separate exact-target-binding predicate fails.¶

For a separately evaluated chain qualifier, the immutable composition profile identifies the exact affected qualifier role and the predicate-to-field mapping. An assessed failure of that qualifier's semantic warrant sets its semantic_validation to unsupported; an assessed failure of IV independence sets the IV aggregate's independence_validation to unsupported. Other fields retain their actual assessment results. An unperformed assessment sets its governed field to not-evaluated, with consistent evaluation scope and the applicable structured composition gap. Multiple failed or unperformed predicates retain all their field values, reasons, and applicable gaps. These are obligations of the composition profile; Core does not infer or rewrite a field from a supplied reason token. A qualifier failure does not change an independently supported chain base unless that failed predicate is also required by the base's own warrant.¶

An inherited PROV qualifier requires exact PROV support for every required segment plus provenance coverage of every required inter-segment binding. An inherited IV qualifier requires exact IV support at the relevant base for every required segment, covered chain bindings, and a passing chain independence assessment. Alternatively, a profile can establish a new chain-level PROV or IV qualifier from a separate exact chain-level finding and explicit warrant; that finding is evaluated by the ordinary qualifier rules and cannot be inferred from segment depth alone.¶

A composed input MUST inherit the set union of recorder relations and of unresolved limitations, freshness and revocation limits, coverage limits, and trust-context restrictions of its premises unless a named warrant explicitly resolves a specific item. Applicable upstream evaluation gaps are remapped to the exact chain target and affected chain claims and carried as structured profile_evaluation_gaps entries with their original basis references and limitations. A warrant that resolves a gap names the exact entry and records the resolving basis; it cannot silently delete all gaps of the same token.¶

Counter-evidence entries from all premises and chain-level findings are retained separately. Entries can be coalesced only when status and affected-claim set are identical; their basis references, reasons, and limitations are then set-unioned. Statuses, affected-claim sets, or reason sets across different scopes MUST NOT be collapsed or promoted by precedence. If any evaluator cannot narrow affected claims safely, that entry uses all-admissible-claims. The composed set contains one not-supplied entry only when every premise and chain-level input reports not-supplied; otherwise all such sentinel entries are omitted.¶

A chain claim and a terminal-action claim are distinct. Support for a chain does not establish completion, terminal effect, or goal satisfaction. A terminal-action claim uses the terminal segment's exact support plus a validated binding to the selected terminal action.¶

The Core conformance evidence in Section 12 covers only the appraisal of normalized composition outputs unless a separate composition-profile claim is declared. The C11 and C12 fixtures in Section 13 assume that an identified external composition profile has already emitted the stated ordinary finding. They test Core support construction and limitation carry-through, not premise discovery, adjacency validation, warrant evaluation, or composition-profile conformance.¶

10. Non-Inference and Coverage Rules

The limits in this section are an application of an invariant this protocol inherits rather than states. Quoting Witnessability Conceptual Core 1.0 [WCC-CORE], Section 4, W-I7: "No transition, inference, transformation, aggregation, or composition may increase the Support Envelope without an explicit warrant and any additional premises or basis required by that warrant." Every downstream result inherits the relevant limitations of upstream materials and arguments unless those limitations are explicitly resolved. This document does not introduce that invariant and claims no novelty for it. The scoped operational requirements below apply it to the objects defined here. The composition warrant of Section 9 is this document's operational form of the warrant named in the quoted invariant.¶

The corresponding rule of this document is stated over claim strength: no transition, inference, transformation, aggregation, or composition may increase the strength of a supported claim without an explicit warrant and the premises that warrant requires. This document inherits the quoted invariant by intent and not by identity of objects; Support Envelope is not defined here, and remains the object of [WCC-CORE].¶

This application includes the invariant's Preserved Incomparability clause. It does not presume a total order over typed states; a profile that projects them into one supplies the justification for that projection. A single maximum among supported states is not guaranteed, and monotonicity is not presumed.¶

This correspondence has two limits. It does not change the Boundary Ceiling rule in Section 7 or provide an additional proof of that rule. It also does not combine the separate prohibition on raising a captured content base through verification with the warrant requirement above.¶

The following limits are normative:¶

• observation does not imply intent, invocation, or execution;¶

• intent does not imply authority, authorization validity, invocation, or execution;¶

• invocation does not imply execution, completion, or effect;¶

• execution does not imply completion of a larger process, durable external effect, goal satisfaction, correctness, safety, or policy compliance;¶

• a provenance artifact by itself does not establish runtime occurrence; a PROV-qualified WEXP claim presupposes separately established exact execution support, and IV does not imply PROV;¶

• a signature authenticates bytes under a key; it does not establish content truth or boundary control;¶

• a transparency receipt supports only the exact predicate established by its verification under the applicable profile; a promise of inclusion is not proof of inclusion, and neither by itself establishes continuing custody, PROV, IV, or execution;¶

• presence of records does not establish completeness of coverage;¶

• absence of a record does not establish nonoccurrence;¶

• a sole counter_evidence entry with status = not-supplied does not establish absence of counter-evidence; and¶

• aggregation and transformation do not remove upstream limitations unless an explicit warrant resolves them.¶

11. Cross-Carrier Equivalence

Two carrier inputs are Core-equivalent when, under the same semantics version and evaluation context, they normalize under Section 6.1 to equal algorithm-relevant targets, asserted claims, finding statuses, scopes, and reason sets, boundary ceilings and grounding, recorder relations, basis references, profile-gap entries, evaluation scope, limitations, and fatal conditions. Counter-evidence equivalence includes every entry's status, affected claims, reasons, basis references, and limitations. Applied profile identifiers and their immutable revisions are part of that equality.¶

A conforming Core appraiser MUST return the same complete logical appraisal for Core-equivalent inputs. Carrier-specific parse, authentication, and transport metadata can differ without affecting Core equivalence only when they do not change a normalized component. Inputs that differ only in opaque basis-reference identifiers are not completely Core-equivalent; when all other normalized components are equal, their appraisals MUST nevertheless be identical except for those carried basis references and any carrier metadata that the result profile explicitly preserves.¶

12. Core Conformance and Evaluation Scope

A full Core-appraiser conformance claim is binary only for an exact declared revision and scope. The claim record identifies the Core document name and immutable source digest, semantics_version, reviewed Requirements Registry identifier and digest, required vector-package identifier and manifest digest, implementation and runner revisions, and the complete requirement and vector identifier sets in scope. These identities let a recipient check whether the evidence concerns the declared source and package bytes; they do not by themselves establish that the run occurred or prevent a misleading presentation.¶

A Requirements Registry in this section is a versioned conformance artifact supplied by the claimant, not an IANA registry or an unstated external document. It enumerates the normative Core-appraiser obligations for the exact source revision, including obligations not expressed with BCP 14 keywords. Each entry has a unique requirement identifier, an exact source locator, the obligation and its applicability, and a documented review disposition. The artifact identifies its reviewer, review date, and included and omitted scope. A claim of full conformance requires a reviewed complete inventory for that surface; mechanical keyword extraction alone does not establish completeness.¶

A vector package is an executable representation of the normative logical fixtures in Section 13 together with any additional vectors declared in the conformance scope. Its manifest identifies the exact Core source revision, every vector and its input and complete expected logical appraisal, the fixture-profile revision, encoding and comparison rules, and the harness revision. It binds the package files by their names and digests. The expected appraisals are fixed independently of the implementation outputs before the comparison run. A package cannot replace or contradict the logical expectations in this document.¶

The conformance record MUST provide immutable identifiers and retrieval locations for the reviewed Requirements Registry and vector-package manifest, together with the digest algorithms, the exact bytes hashed, and their digests. The claimant MUST make those bound artifacts retrievable by the recipient to check the claimed scope. These artifacts and their publication or access arrangements are supplied with the claim; no private project registry or unavailable package is an implicit normative dependency of this specification.¶

For that exact scope, PASS means that the implementation satisfies every bound reviewed requirement, every required frozen vector was parsed under its identified non-normative harness, every complete logical appraisal equaled the independently frozen expected appraisal, and the execution recorded zero mismatch, not-run, and blocked cases. The normative authority remains this specification and its reviewed requirements; vector comparison is evidence, not the source of an expectation.¶

A full conformance record enumerates all reviewed Core-appraiser requirements and all required vectors for the identified revision. An implementation that supports a smaller surface lists the exact included and omitted requirement and vector identifiers and labels the result PARTIAL; it does not claim full Core conformance. Mapping-profile conformance, composition-profile conformance, carrier conformance, and result-carrier conformance are separate claims with separate immutable profile identities. A Core-appraiser record does not establish that raw evidence was correctly authenticated, interpreted, or normalized by an untested upstream profile.¶

PASS is not certification, proof of correctness or completeness, proof of security, evidence of interoperability with an untested implementation or carrier, IETF acceptance, or authority to make policy decisions. No conformance record changes the specification-to-requirements-to-vectors-to-implementation authority direction.¶

evaluation_scope is an unordered map from capability names to exactly one of evaluated or not-evaluated. The following initial names are closed for wexp-core-2:¶

• carrier-mapping;¶

• authenticity;¶

• target-binding;¶

• boundary-grounding;¶

• observation-support;¶

• intent-support;¶

• invocation-support;¶

• execution-support;¶

• provenance-support;¶

• independent-verification;¶

• composition; and¶

• counter-evidence.¶

Every initial name MUST appear exactly once. An extension key is the logical pair (profile_identifier, local_name) of two non-empty text atoms, where the immutable applied profile identifier occurs in evaluation_context.profile_identifiers and local_name names an extension in that revision. The pair is its identity. Core ignores an extension status for support and gap derivation but preserves the exact pair and status in the result. A malformed pair or a missing, empty, or non-text atom produces E_MALFORMED_NORMALIZED_INPUT at the structural check in Section 6.2. For a structurally valid key, an unbound or ambiguous profile or local-name binding, or a duplicate key in the scope map, produces E_PROFILE_MAPPING_INVALID at the following cross-field check.¶

The scope map summarizes assessments represented by the normalized input under the applied profiles and evaluation context. Discovery refers only to the material domain declared by those profiles and that context; it does not establish complete capture or discovery in the world. carrier-mapping is evaluated for every complete Core input. A structurally valid input with carrier-mapping = not-evaluated violates this cross-field invariant and produces E_PROFILE_MAPPING_INVALID. Retaining this capability in the uniform scope map makes the completed normalization prerequisite explicit to a result consumer. It is not a claim that Core parsed or authenticated a carrier. Failure to complete that upstream prerequisite produces no Core input or appraisal under Section 1.2, rather than a Core result with this capability unperformed.¶

For finding-backed capabilities, evaluated means discovery of applicable material in that declared domain completed and every supplied assessment governed by the capability has a status other than not-evaluated. Absence of an aggregate under that value means the discovery found no candidate for that role. not-evaluated records an applicable unperformed assessment or an unexercised role. If the asserted claim requires an unevaluated base or qualifier role, its exact aggregate is present; a base or PROV aggregate has a governed not-evaluated field. The shared-role rule below determines which IV or binding assessments were not performed.¶

For counter-evidence, evaluated means the current capability-level procedure completed its assessment of the supplied entry set under the declared profile domain, including recording any entry it could not resolve. not-evaluated means that procedure was not completed. Neither value asserts discovery of all counter-evidence. Individual entries retain their own assessment statuses, including previously assessed entries preserved when the current procedure is not completed. An evaluated capability can therefore contain a not-evaluated entry. Core MUST NOT replace an entry status with the capability value. The capability value alone MUST NOT create an ingress rejection, substantive finding, or evaluation gap for counter-evidence. The entry's status and affected claims govern its effect under Section 8.6.¶

For each base-support capability and for provenance-support, if the corresponding aggregate is present and the capability is not-evaluated, at least one governed status field in that aggregate MUST be not-evaluated, independently of whether the role is asserted. A present wholly assessed single-role aggregate paired with not-evaluated violates the cross-field contract and produces E_PROFILE_MAPPING_INVALID. An absent unasserted aggregate can represent an unexercised capability without creating a claim-specific gap.¶

target-binding and independent-verification are shared across exact roles. Their not-evaluated summary does not replace a passing assessment for a different exact role. An unexercised or unperformed unrelated role can be unrepresented, as in C12; a supplied aggregate retains each actual assessment status. A claim-required IV aggregate is present when the shared IV capability is not-evaluated, but its passing statuses need not be changed merely because another role was not assessed. Claim-specific gaps are derived from the exact required aggregate, not from the shared summary alone.¶

The external authenticity and composition capabilities use a fully syntactic rule: their scope value is not-evaluated if and only if at least one profile-gap entry names that capability in current_scope_capability, and is evaluated if and only if no entry names it. A marked entry can affect any exact admissible claim; its projection into the result remains governed separately by the affected-claim rule. Core does not decide from profile-defined trust data whether an external assessment was required.¶

The governed status fields are: every finding's target_binding for target-binding; boundary status, binding, and grounding for boundary-grounding; the corresponding base aggregate's binding and semantic status for each base-support capability; PROV binding and semantic status for provenance-support; IV binding, semantic, and independence status for independent-verification. Counter-entry statuses are excluded from this governed-field test and follow the separate counter-evidence rule above. A scope value of evaluated with a governed not-evaluated status, a claim-required finding-backed not-evaluated capability without its aggregate, a current-scope marker whose capability is not not-evaluated, or an external capability value without the required marker presence or absence violates the cross-field contract and produces E_PROFILE_MAPPING_INVALID.¶

A profile_evaluation_gaps entry without current_scope_capability can preserve a gap from an upstream or composed premise under its own exact scope. Its presence does not change the current appraiser's capability status. Core determines current-scope consistency only from the explicit optional field and never interprets opaque basis references for that purpose.¶

An evaluation capability MUST NOT be used as evidence and MUST NOT create or structurally cap a claim. A role-specific Core gap entry is emitted only by the claim-required matrix when its aggregate is required by the asserted claim. A valid profile-gap entry is projected under its affected-claim rule. Otherwise the scope map alone records the unexercised capability and does not become a reason, gap, or substantive finding.¶

Re-appraisal under a different evaluation context produces a new scoped result. It does not automatically invalidate a historical appraisal or establish that the historical result applies in the new context.¶

13. Normative Semantic Test Vectors

C01 through C16 are normative logical cases, not a wire format. A conformance record binds an executable representation through an exact manifest that identifies the source revision, reviewed requirement and case identifiers, non-normative harness schema, fixture bytes, and frozen expected logical appraisals. The representation and comparison procedure do not add a Core serialization requirement. A representation passes a case only when its complete decoded logical input and complete observed appraisal equal the normative input and expectation stated here.¶

The logical fixtures below are normative. Common input values are: semantics_version=wexp-core-2; target T; evaluation-context identifier C; evaluation time 2026-10-12T00:00:00Z; trust-configuration atom core02-fixture-trust-1, which accepts attributed boundary grounding; the singleton applied-profile set containing the immutable fixture identity defined below; a supported, target-bound, attributed boundary finding for T and C with basis bd and the stated ceiling; empty recorder relations, profile evaluation gaps, inherited limitations, and fatal conditions; counter-evidence consisting of one entry whose status is not-supplied and whose affected-claim, basis-reference, reason, and limitation sets are empty; and every initial evaluation-scope capability set to evaluated. Every supported base or qualifier finding has target T, context C, supported target binding and semantic validation, empty reasons and limitations, and the exact basis-reference set defined below. Supported IV additionally has supported independence validation; PROV uses not-applicable. A finding not stated in a row is absent. For C09, the otherwise unstated boundary ceiling is execution; the fixed rejection projection makes this input field unavailable in the result.¶

Unless a row explicitly states otherwise, the boundary finding has empty reasons and limitations. Each counter entry introduced by a row has empty basis_refs, reasons, and limitations except for values explicitly stated in that row. A row that introduces counter entries replaces the common not-supplied entry. Profile-gap entries have no current_scope_capability unless explicitly stated. In C12, the composed execution finding carries L-boundary inherited from the stated premise.¶

Unless a row explicitly overrides its basis-reference set, each base finding has a singleton basis-reference set whose local name is O for observation, I for intent, N for invocation, and E for execution. The PROV(execution) finding uses P(E). IV findings for observation, intent, invocation, and execution use V(O), V(I), V(N), and V(E), respectively. Each local name denotes the profile-scoped atom under the fixture profile defined below. These are exact basis-reference names, not aliases of the full base or qualifier names. C11 and C12 instead use their explicitly stated execution basis-reference set {s1,s2,adj,w}.¶

The immutable fixture profile identity is the following exact text atom:¶

draft-sergeev-wexp-core-02/fixture-1

This local fixture identity is not an IANA registration or a network locator. This paragraph completely defines its revision: P_COUNTER_FAIL is registered in the substantive category, is applicable to C15's counter entry, and means that the fixture's assessment found the stated material counter-evidence unresolved. It adds no status, evidence, or independent acceptance condition. The profile defines no recorder-relation tokens or scope-extension names. Opaque fixture atoms compare by exact Unicode scalar text; a displayed basis reference or limitation denotes the ordered pair of this profile identity and its displayed local name. No URI, case, or Unicode normalization is implicit. A harness MUST NOT infer an applied profile solely from a token or basis reference. An executable representation pins these profile contents and its own encoding rules in its manifest.¶

In the table, O, I, N, and E mean unqualified observation, intent, invocation, and execution. +P and +V mean PROV and IV. S is supported_claims, M is maximal_supported_claims, and A is asserted_claim_supported. For each member of S, support_entries contains exactly one entry whose basis-reference set is the union of bd, its base finding's basis references, and any qualifier findings' basis references; its limitations are the union of those premises. support_relations contains the displayed relation for each member of M. gaps={} also means evaluation_gap_entries={}. For accept and downgrade rows, fields not varied by a row equal the common input values and carry through to the output. A reject row instead uses the complete fixed projection in Section 8.4.¶

14. Security Considerations

WEXP limits inference; it does not make a dishonest or compromised witness honest. A false boundary assertion, malicious mapping profile, compromised signer, or colluding evidence evaluator can manufacture normalized findings unless the evaluation context independently constrains those actors.¶

Authenticity is not truth. A valid signature establishes that bytes verify under a key. Key-to-identity binding attributes the assertion. Neither establishes that the action occurred, that the signer controlled the claimed boundary, or that the signer was authorized.¶

Reference integrity is not semantic support. A digest can bind an appraisal input to artifact bytes. It does not establish the artifact's type, exact-action coverage, accepted root, or independence. Qualifier support requires the exact profile predicate in Section 6.¶

Boundary grounding. A declared boundary can be false. An accept or downgrade appraisal preserves whether it was asserted, attributed, attested, or not evaluated. A reject appraisal instead uses the fixed projection in Section 8.4, with boundary_grounding = unavailable. Result carriers and presentation profiles preserve the reported grounding without promoting it to a stronger class. Relying parties MUST NOT erase this distinction.¶

Self-report. A self-report can support a report about what the actor asserted. It does not provide third-party non-repudiation merely because its content base is deep or its bytes are signed.¶

Independent verification. Independence is profile- and context-relative. Different keys or roots can remain under common administrative control, while a shared public root does not necessarily destroy operational independence. A passing IV finding needs an explicit assessment basis.¶

Counter-evidence. Unresolved material counter-evidence blocks acceptance. No supplied counter-evidence is not proof that none exists.¶

Coverage and nonoccurrence. A set of valid records can be incomplete. A missing record can reflect omission, capture failure, refusal to emit, loss, or an action that never occurred. WEXP Core does not distinguish those cases without positive profile-defined evidence.¶

Composition. Composition is a common inflation point. Exact premises, bindings, warrants, and limitation inheritance are required. A chain appraisal cannot be used as evidence for a terminal effect unless a separate predicate establishes that exact claim.¶

Evaluation context. Trust anchors, profile versions, policies, evaluation time, revocation state, and appraiser capabilities affect findings. An accept or downgrade appraisal carries the evaluation context so that the result is not detached from those dependencies. A reject appraisal instead uses the fixed projection in Section 8.4, with evaluation_context = unavailable. A result carrier can retain request provenance alongside a rejection, but that provenance is not the Core evaluation context and does not alter the fixed rejection projection.¶

Privacy. Even opaque targets, basis references, reason codes, and timing information can enable correlation. Carrier and evidence profiles should minimize disclosure and state the confidentiality properties of any commitments they use.¶

15. IANA Considerations

This document requests creation of a "Witnessed Execution Protocol (WEXP)" registry group containing a "WEXP Appraisal Reason Codes" registry. The registration policy is Specification Required as defined by [RFC8126]. Each entry contains a token, category (fatal, substantive, or evaluation-gap), default verdict effect, current-scope capability (none, authenticity, or composition), and reference. Tokens begin with an uppercase ASCII letter and contain only uppercase ASCII letters, digits, and underscores. Token comparison is case-sensitive. No particular prefix, including E_, is required. This registration syntax does not prescribe a carrier encoding or limit on artifact size.¶

The current-scope capability column is part of the immutable registration semantics resolved under Section 6. Its value is none for every fatal or substantive token, and for an evaluation-gap token that is not permitted with current_scope_capability. An evaluation-gap registration with value authenticity or composition permits that marker only for the named capability. The referenced specification defines the exact assessment represented by that binding. Initially, E_COMPOSITION_NOT_EVALUATED is bound to composition; no other initial token is permitted with that marker. An applicable profile registration supplies any additional binding, including a token for authenticity. A marker naming a different capability or a token without such a binding produces E_PROFILE_MAPPING_INVALID.¶

Initial entries are shown below; the reference for every initial entry is this document. The default effect describes the condition that generates the diagnostic, not a verdict computed from token presence alone. The verdict procedure in Section 8.4 is authoritative. In particular, a reason carried by a finding or a profile-supplied evaluation gap can coexist with accept; its presence does not negate a passing exact predicate. An unevaluated counter entry affecting the asserted claim blocks acceptance even when its materiality has not been established.¶

The appraiser derives E_MALFORMED_NORMALIZED_INPUT, E_UNSUPPORTED_SEMANTICS_VERSION, E_PROFILE_MAPPING_INVALID, and E_CLAIM_OUT_OF_DOMAIN through the ordered checks in Section 6.2; they are not valid supplied fatal conditions. The remaining initial fatal tokens can be supplied only under the exact meanings and structurally usable-input rule in that section. Carrier-specific parse or extension errors are outside this Core registry and are neither aliases nor automatic mappings to Core tokens.¶

The Designated Expert should verify the token syntax and uniqueness, one unambiguous condition, a deterministic category and default effect, a valid current-scope capability value and its consistency with the category and referenced assessment, and a stable public specification. Changing the meaning, category, or current-scope capability of an existing token requires a new token; an existing registration is not reinterpreted by an incompatible update. A registration that would create claim support from an evaluation capability, display label, boundary name, or artifact presence should be rejected.¶

Appendix A. Changes Since draft-sergeev-wexp-core-01

RFC Editor: please remove this appendix before publication as an RFC.¶

This appendix compares this revision with the posted Core-01 baseline [I-D.sergeev-wexp-core-01].¶

• Renamed the document to describe its Witnessability appraisal role while retaining the WEXP project and Internet-Draft identifier.¶

• Introduced wexp-core-2 for the clarified and tightened ingress contract; see Appendix B.¶

• Resolved the Section 12/C14 conflict by separating the counter-evidence capability summary from each entry's status and affected claims.¶

• Defined the immutable fixture profile, token registry, comparison rules, and complete common context for C01-C16, including C15.¶

• Required present single-role base and PROV aggregates to agree with a not-evaluated capability, independently of the asserted claim, and stated shared-role scope behavior explicitly.¶

• Replaced the residual CC0-CC5 declaration with separate conformance surfaces.¶

• Clarified downgrade, full result preservation, diagnostic row predicates, and the blocking-only projection of counter-entry reasons.¶

• Distinguished profile rules, mapper and Core procedures, and their data flow in the architecture description.¶

• Clarified maximal display labels, structural versus mapping failures, the rejection projection, receipt predicates, and condition-scoped diagnostic effects.¶

• Distinguished evidentiary verification roots from public authentication trust anchors without relaxing the chain warrant.¶

• Clarified reported boundary grounding, input-binding obligations, external challenge routing, and the separation of Core appraisal from Coverage and application-policy decisions.¶

• Made gap-token capability bindings, composition predicate-to-field mappings, carrier-failure handling, and claim-required scope checks explicit; aligned the pseudocode helper and diagnostic projection text.¶

• Pinned the conceptual references and documented the scope and limits of their operational correspondence.¶

Appendix B. Compatibility and Migration

The Internet-Draft revision, Core semantics version, profile revision, and executable-corpus identity are separate versioned objects. This document defines only wexp-core-2. A multi-version implementation selects an explicit semantic procedure before invoking it; it does not relabel a wexp-core-1 input or silently apply these rules to a historical result.¶

The version change reflects ingress differences. Core-01 [I-D.sergeev-wexp-core-01] contained a conflict between its general counter-evidence scope rule and C14; this revision preserves C14's entry-specific intent without claiming that all Core-01 readers agreed. It also makes the previously unresolved single-role scope case an explicit mapping rejection and states the shared-role interpretation. Those choices can change admission for the same findings. Unchanged support algebra does not make the whole contract interchangeable.¶

Existing Core-01 fixtures, source bytes, results, and issue records retain their identities. The new common fixture context changes the complete logical inputs and non-reject outputs, even where verdicts and supported sets remain the same. Representations of this revision therefore use new manifests and expectations. A Core-01 conformance or interoperability result is not evidence of conformance to this revision without a separately recorded evaluation.¶

Appendix C. Conceptual Correspondence and Attribution

This informative table describes selected relationships. It is not a general conformance claim to either conceptual publication or a proof that their formal objects and this Core are equivalent.¶

The W-I7 quotation in Section 10 is attributed to Mikhail A. Sergeev, Witnessability Conceptual Core 1.0, released under the CC BY 4.0 license. The reviewed Markdown artifact is WITNESSABILITY-CORE-1.0.md, with SHA-256:¶

382e39864e257d93a0afd16c377c54f59a2182ecc5c38178764ded29ffb3f034

The publication's release index identifies the same artifact. This revision replaces the abbreviated source identity in Core-01 and locates the quotation precisely; it makes no additional historical-priority claim. The execution-evidence model is the joint work of Mikhail A. Sergeev and Vladimir Ikher [WITNESSABILITY].¶

Appendix D. Historical Changes from Core-00 to Core-01

RFC Editor: please remove this appendix before publication as an RFC.¶

This list records the transition from [I-D.sergeev-wexp-core-00] to the posted Core-01 baseline [I-D.sergeev-wexp-core-01].¶

• Separated carrier-neutral appraisal semantics from the Native Record format.¶

• Replaced scalar WL arithmetic with typed claims consisting of a content base and qualifier set.¶

• Made IV applicable to an exact claim at any supported base without raising that base.¶

• Replaced a singular verified level with an exact supported claim set and maximal supported alternatives.¶

• Made appraisal claim-independent and separated exact support from structural order.¶

• Fixed the verdict vocabulary to accept, downgrade, and reject.¶

• Replaced cumulative CC arithmetic with a non-evidentiary evaluation capability vector.¶

• Added normative semantic vectors, exact qualifier predicates, limitation inheritance, and explicit non-inference rules.¶

Appendix E. Disclosure

Portions of this document were developed with the assistance of generative AI tools under human editorial control. The listed authors are responsible for the resulting text.¶

Authors' Addresses