WEXP Core: Witnessability Appraisal Semantics for Execution-Related Claims
draft-sergeev-wexp-core-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Mikhail Sergeev , Vladimir Ikher | ||
| Last updated | 2026-10-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sergeev-wexp-core-02
Network Working Group M. Sergeev, Ed.
Internet-Draft V. Ikher
Intended status: Informational Independent Researcher
Expires: 26 April 2027 23 October 2026
WEXP Core: Witnessability Appraisal Semantics for Execution-Related
Claims
draft-sergeev-wexp-core-02
Abstract
The Witnessed Execution Protocol (WEXP) Core defines carrier-neutral
Witnessability appraisal semantics for execution-related claims. It
operationalizes selected concepts of the Witnessability Model under
the Witnessability Conceptual Core within the bounded claim domain
specified here. It defines four distinct content bases, two
independent evidence qualifiers, the Boundary Ceiling, exact-claim
support, deterministic accept, downgrade, and reject verdicts,
composition without inflation, and a normalized interface between
evidence-carrying profiles and appraisers. WEXP Core does not define
a record serialization, signature envelope, action identifier,
authorization model, or evidence-artifact schema. Carrier and
evidence profiles can supply its normalized inputs; a native record
format is optional and is not a prerequisite for this Core.
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.
Sergeev & Ikher Expires 26 April 2027 [Page 1]
Internet-Draft WEXP Appraisal Core October 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 3
1.2. Appraisal Architecture and Data Flow . . . . . . . . . . 4
1.3. Relationship to the Witnessability Conceptual Core and
Model . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Relationship to Related Work . . . . . . . . . . . . . . 7
1.4.1. Joint Use with Coverage (Informative) . . . . . . . . 7
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 8
3. Conformance Surfaces . . . . . . . . . . . . . . . . . . . . 9
4. Claim Model . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Exact Action Target . . . . . . . . . . . . . . . . . . . 9
4.2. Content Bases . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Evidence Qualifiers . . . . . . . . . . . . . . . . . . . 10
4.4. Typed Claims and Admissible Domain . . . . . . . . . . . 10
4.5. Structural Order . . . . . . . . . . . . . . . . . . . . 11
4.6. Notation and Legacy Display Labels . . . . . . . . . . . 11
5. Presentation and Display Projection . . . . . . . . . . . . . 12
6. Normalized Appraisal Input . . . . . . . . . . . . . . . . . 13
6.1. Logical Types, Identity, and Equality . . . . . . . . . . 19
6.2. Core Ingress, Validity Classes, and Fatal Precedence . . 20
7. Boundary Ceiling . . . . . . . . . . . . . . . . . . . . . . 22
8. Appraisal Procedure . . . . . . . . . . . . . . . . . . . . . 23
8.1. Supported Claim Set . . . . . . . . . . . . . . . . . . . 23
8.2. Verdict . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.3. Support Relation . . . . . . . . . . . . . . . . . . . . 25
8.4. Normative Algorithm . . . . . . . . . . . . . . . . . . . 25
8.5. Required Appraisal Result . . . . . . . . . . . . . . . . 29
8.6. Substantive Reasons and Evaluation Gaps . . . . . . . . . 30
9. Composition . . . . . . . . . . . . . . . . . . . . . . . . . 32
10. Non-Inference and Coverage Rules . . . . . . . . . . . . . . 36
11. Cross-Carrier Equivalence . . . . . . . . . . . . . . . . . . 37
12. Core Conformance and Evaluation Scope . . . . . . . . . . . . 38
13. Normative Semantic Test Vectors . . . . . . . . . . . . . . . 42
14. Security Considerations . . . . . . . . . . . . . . . . . . . 47
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
16. Normative References . . . . . . . . . . . . . . . . . . . . 51
17. Informative References . . . . . . . . . . . . . . . . . . . 51
Sergeev & Ikher Expires 26 April 2027 [Page 2]
Internet-Draft WEXP Appraisal Core October 2026
Appendix A. Changes Since draft-sergeev-wexp-core-01 . . . . . . 52
Appendix B. Compatibility and Migration . . . . . . . . . . . . 54
Appendix C. Conceptual Correspondence and Attribution . . . . . 54
Appendix D. Historical Changes from Core-00 to Core-01 . . . . . 56
Appendix E. Disclosure . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
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.
1.1. Scope and Non-Goals
This document specifies:
* the content bases observation, intent, invocation, and execution;
Sergeev & Ikher Expires 26 April 2027 [Page 3]
Internet-Draft WEXP Appraisal Core October 2026
* the qualifiers PROV and IV;
* the normalized input contract used by carrier and evidence
profiles;
* the Boundary Ceiling and exact-support rules;
* the appraisal result and the verdicts accept, downgrade, and
reject;
* composition and limitation inheritance; and
* semantic reason tokens and conformance requirements.
This document does not define JSON, CBOR, CDDL, canonicalization,
signatures, key discovery, record identifiers, global action
identity, authorization or principal binding, action lifecycle
states, chain discovery, evidence-artifact formats, trust-anchor
discovery, policy gates, or a transparency service. It also does not
assign a global EXECUTED state. Those concerns belong to carriers,
profiles, policies, or adjacent specifications.
Completion of a larger process, a durable external effect, goal
satisfaction, nonoccurrence, coverage completeness, and authorization
validity are separate facets. They are not additional content bases
in this document.
1.2. Appraisal Architecture and Data Flow
The architecture separates profile-specific input preparation from
carrier-independent Core appraisal. A carrier or evidence profile
specifies the mapping rules; a mapper implements those rules. The
normalized input and the appraisal result are logical data objects at
the boundaries of the Core procedure, not processing layers.
The following diagram shows the logical data flow. It does not
prescribe separate deployment components or a wire format.
Sergeev & Ikher Expires 26 April 2027 [Page 4]
Internet-Draft WEXP Appraisal Core October 2026
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)
The arrows denote the production and consumption of data. They do
not denote normative dependencies or evidence support, and the
processing stages do not correspond to the four content bases.
Passing through a stage does not itself establish support for a claim
or strengthen that support. Support remains subject to the exact-
claim predicates and the Boundary Ceiling, as specified in
Section 8.1.
A carrier profile maps its fields and artifacts into the normalized
input defined in Section 6. WEXP Core consumes only that normalized
input. A carrier profile MUST NOT treat field presence, a digest
reference, a signature, or an artifact label as a passing semantic
finding unless the profile-defined predicate for the exact claim has
been evaluated successfully.
The dependency is one-way: a carrier profile depends normatively on
this Core; this Core has no normative dependency on any carrier. Two
carriers that produce equivalent normalized inputs under the same
evaluation context produce the same Core appraisal.
A Core invocation begins only after an upstream mapper has produced
one complete logical AppraisalInput. Failure to parse, authenticate,
or interpret a carrier well enough to construct that input produces
no Core appraisal and remains a carrier or mapping-profile
diagnostic. A mapper does not fabricate a partial Core input solely
to transport such a failure. In particular, a carrier-specific
unknown-extension error is not a Core fatal reason and is not
translated to E_UNKNOWN_CRITICAL_SEMANTIC. That Core token has the
narrower meaning defined in Section 6.2.
Sergeev & Ikher Expires 26 April 2027 [Page 5]
Internet-Draft WEXP Appraisal Core October 2026
1.3. Relationship to the Witnessability Conceptual Core and Model
The Witnessability Conceptual Core 1.0 [WCC-CORE] provides general
claim-relative constraints on support assessment, including
separation of verification, appraisal, and reliance (W-I2), non-
amplification and preserved incomparability (W-I7), and the derived
Boundary Ceiling Rule ([WCC-CORE], Section 6.5). The Witnessability
Model 1.1 [WITNESSABILITY] specializes the subject to execution-
related evidence, qualified states, and execution-relevant
boundaries. This Core specifies an operational appraisal procedure
for the limited domain in Section 4.4.
The correspondence is scoped, not an identity of formal objects. A
WEXP typed claim is evaluated for an exact action and context; it
does not represent every Target Proposition admitted by the
Conceptual Core. A WEXP supported-claim set is not the Conceptual
Core's Support Envelope. A WEXP Appraisal records support, counter-
evidence, gaps, and limitations, but does not implement every
component of a Witness Case or prescribe a Relying-Party Decision.
The Model's qualified-state interpretation motivates the separation
of content bases from PROV and IV. In this Core, the structural
order does not entail support at another base. The Boundary Ceiling
excludes claims; it supplies no positive finding. Verification
qualifies only the exact base and target for which the applicable
predicate passed. No scalar WL label replaces those predicates.
The Model states its Boundary Ceiling as Axiom BC. The Conceptual
Core states a more general boundary rule derived from non-
amplification. Applying an exclusion rule here neither proves the
Model's axiom nor establishes a refinement theorem between these
works. Conformance or interoperability evidence for this Core
establishes only the declared implementation or comparison scope.
Appendix C records the principal correspondences and limitations.
Normative behavior is fully stated in this document; an informative
conceptual reference cannot silently add an input field, a predicate,
or an acceptance condition. Later revisions of either conceptual
publication require an explicit correspondence review before being
claimed as the basis of a later Core revision.
Sergeev & Ikher Expires 26 April 2027 [Page 6]
Internet-Draft WEXP Appraisal Core October 2026
1.4. Relationship to Related Work
RATS [RFC9334] appraises evidence about an environment. Transparency
systems provide evidence about registration or inclusion under their
verification assumptions. Provenance systems describe origin and
production history. Action-record, capsule, receipt, and audit
specifications define carriers and lifecycle objects. WEXP is
complementary: it defines the per-action evidence-to-claim appraisal
semantics that those systems can invoke through a mapping profile.
WEXP does not duplicate canonical action identity, evidence-
collection sufficiency, authorization evidence chains, action
lifecycle state, or SCITT carrier semantics [RFC9943]. Such systems
can consume a WEXP Appraisal as one typed result, and WEXP profiles
can consume their artifacts as evidence, without either layer taking
ownership of the other.
1.4.1. Joint Use with Coverage (Informative)
WEXP Coverage [WEXP-COVERAGE] defines a separate experimental
contract for claims about bounded populations of actions and records.
Core appraises exact typed claims for one target; it does not
establish population completeness. Coverage is not a Core content
base, qualifier, verdict, or legacy WL display label, and Core has no
normative dependency on Coverage. A deployment can use either
contract alone or combine them in one implementation, invocation, or
report.
A joint-use profile identifies how Core targets correspond to
elements of the Coverage scope, including the meaning of the action,
required claims, versions, contexts, cutoffs, and policies. A shared
identifier alone does not establish that a ledger append and an
external payment are the same action. A combined report preserves
the Core appraisals, the Coverage result, and a separate application-
policy decision with its dependencies. Core reject is not a Coverage
refutation, and an absent or unsupported component required by the
selected task is not a positive combined result. Receipt delivery
and consumption of an appraisal result are different events.
Shared evidence or administrative control can create common
dependencies; independence established for one claim is not
automatically transferred to the other contract. Completeness
relative to actual actions does not establish that every required
action or obligation was fulfilled. These joint-use requirements
belong to the applicable profile, not to a new Core algorithm or
conformance claim.
Sergeev & Ikher Expires 26 April 2027 [Page 7]
Internet-Draft WEXP Appraisal Core October 2026
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.
Sergeev & Ikher Expires 26 April 2027 [Page 8]
Internet-Draft WEXP Appraisal Core October 2026
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
4.1. Exact Action Target
Every asserted claim and every finding used to support it MUST be
bound to an exact action target. Equality and binding are defined by
the mapping profile. Core does not require or create a global action
identifier.
A correlation hint, record identifier, shared timestamp, similar
payload, or common signer MUST NOT be treated as an exact target
binding unless an applicable profile defines and validates that use.
4.2. Content Bases
This document defines four distinct content bases:
observation A positive finding that an event concerning the exact
action target was recorded or reported. Absence of evidence does
not support observation.
intent A specific intention, approval, plan, or decision concerning
the exact action and its bound arguments is evidenced. It does
not establish authority, approval validity, policy satisfaction,
invocation, or execution.
Sergeev & Ikher Expires 26 April 2027 [Page 9]
Internet-Draft WEXP Appraisal Core October 2026
invocation The exact invocation crossed an observed invocation
boundary. It does not establish that the invoked operation
executed or produced an effect.
execution Execution of the exact action was evidenced at an
execution-relevant controlled boundary. It does not establish
completion of a larger process, durable external effect, goal
satisfaction, authorization validity, or correctness.
The bases have a structural content-depth order:
observation < intent < invocation < execution
This order is not an entailment relation. Evidence supporting one
base does not, by that fact alone, support any other base. A mapping
profile MUST evaluate each base predicate independently.
4.3. Evidence Qualifiers
PROV The established execution of the exact action is linked to
provenance that has been semantically validated and accepted in
the evaluation context. PROV applies only to the execution base.
Provenance for intent, invocation, configuration, an environment,
or an output object does not by itself satisfy PROV for the
action's execution.
IV The exact content claim, at its exact base, has been
independently verified under an applicable profile and trust
configuration. IV can qualify any supported base and does not
raise that base.
The qualifiers are independent. Neither implies the other. IV for
invocation MUST NOT be transferred to execution, and IV or PROV for
one action MUST NOT be transferred to another.
A different key, signer, organization label, or trust root is not
sufficient by itself to establish independence. The applied IV
profile MUST define the administrative, operational, and technical
criteria it evaluates.
4.4. Typed Claims and Admissible Domain
A typed claim is a pair (base, qualifiers), where base is a content
base and qualifiers is a subset of {PROV, IV}. The claim is
admissible only if PROV is absent or the base is execution.
Sergeev & Ikher Expires 26 April 2027 [Page 10]
Internet-Draft WEXP Appraisal Core October 2026
Well-formedness and admissibility are separate: (intent, {PROV}) uses
a recognized base and qualifier set and is well-formed, but is
inadmissible as an asserted claim and is rejected at step 6 when no
earlier rejection applies in Section 6.2; an unknown base or
qualifier, wrong logical type, or malformed qualifier set fails the
structural check at step 3.
The admissible claims are:
(observation, {}) (observation, {IV})
(intent, {}) (intent, {IV})
(invocation, {}) (invocation, {IV})
(execution, {}) (execution, {PROV})
(execution, {IV}) (execution, {PROV, IV})
An asserted claim outside this domain is rejected with
E_CLAIM_OUT_OF_DOMAIN. An appraiser MUST NOT silently delete an
invalid qualifier and reinterpret the assertion as another claim.
4.5. Structural Order
For structural comparison only:
(b1, A1) <= (b2, A2) iff b1 <= b2 and A1 is a subset of A2
This is a partial order. For example, (execution, {PROV}) and
(execution, {IV}) are incomparable, as are (invocation, {IV}) and
(execution, {}).
The structural order is used for the Boundary Ceiling comparison,
maximal supported alternatives, support relations, and declared
display projections. It MUST NOT be used as an exact-support
predicate. In particular, support for execution does not accept an
intent claim unless the exact intent predicate also passes.
4.6. Notation and Legacy Display Labels
This document writes a typed claim using the base name followed by
its qualifier set. The following WL labels are retained only as a
familiar, lossy display convention:
Sergeev & Ikher Expires 26 April 2027 [Page 11]
Internet-Draft WEXP Appraisal Core October 2026
+===============+=====================+
| Display label | Typed claim |
+===============+=====================+
| WL0 | (observation, {}) |
+---------------+---------------------+
| WL1 | (intent, {}) |
+---------------+---------------------+
| WL2 | (invocation, {}) |
+---------------+---------------------+
| WL3 | (execution, {}) |
+---------------+---------------------+
| WL4 | (execution, {PROV}) |
+---------------+---------------------+
| WL5 | (execution, {IV}) |
+---------------+---------------------+
Table 1: Legacy WL Display Labels
Other admissible claims have no bare legacy label. A display
projection is not a protocol primitive, an ordering function, or a
complete appraisal. A conforming implementation MUST NOT compare,
bound, compose, or accept claims by numeric WL labels.
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.
Sergeev & Ikher Expires 26 April 2027 [Page 12]
Internet-Draft WEXP Appraisal Core October 2026
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.
Sergeev & Ikher Expires 26 April 2027 [Page 13]
Internet-Draft WEXP Appraisal Core October 2026
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[],
Sergeev & Ikher Expires 26 April 2027 [Page 14]
Internet-Draft WEXP Appraisal Core October 2026
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.
Sergeev & Ikher Expires 26 April 2027 [Page 15]
Internet-Draft WEXP Appraisal Core October 2026
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
Sergeev & Ikher Expires 26 April 2027 [Page 16]
Internet-Draft WEXP Appraisal Core October 2026
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.
Sergeev & Ikher Expires 26 April 2027 [Page 17]
Internet-Draft WEXP Appraisal Core October 2026
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.
Sergeev & Ikher Expires 26 April 2027 [Page 18]
Internet-Draft WEXP Appraisal Core October 2026
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.
6.1. Logical Types, Identity, and Equality
The abstract contract uses logical values, not carrier encodings.
Content bases, qualifiers, statuses, grounding classes, verdicts, and
the initial evaluation-scope names are closed enumerations whose
members compare by the exact names defined in this document. A typed
claim compares as the ordered pair of its base and its mathematical
qualifier set.
The target, evaluation-context identifier, evaluation time, and trust
configuration are opaque logical atoms. An applied
profile_identifier is an immutable specification-and-revision
identity, not a floating profile name. It identifies the profile-
defined equality rules and the exact reason-registry revisions used
by that profile. A basis reference or limitation is a profile-scoped
Sergeev & Ikher Expires 26 April 2027 [Page 19]
Internet-Draft WEXP Appraisal Core October 2026
atom logically equivalent to the pair (profile_identifier,
local_value). Before invoking Core, the mapper normalizes every
profile-defined atom into the stable comparison value defined by that
immutable profile revision. Core does not interpret an opaque atom;
it only compares, copies, and set-unions it using that equality.
Every collection described as a set, including qualifier, profile-
identifier, basis-reference, reason, limitation, fatal-condition,
affected-claim, supported-claim, and maximal-claim collections, is an
unordered mathematical set. Equal members occur once. A carrier
representation either normalizes repeated representations of an equal
set member before Core invocation or rejects them under its own
mapping rules. The aggregate and entry collections are unordered
sets keyed by the complete keys defined in this document. Two
aggregate entries with the same aggregate key are the duplicate
condition in this section, even if every field is byte-identical.
A recorder relation is the logical record shown in Section 6. Its
profile_identifier binds the immutable relation vocabulary;
relation_token names one member of that vocabulary; subject_ref and
object_ref are profile-scoped atoms; and its basis references and
limitations use the equality above. Recorder relations are
descriptive carried facts. Their presence does not create a content-
base or qualifier finding. Two recorder relations are equal only
when all six logical components are equal, and composition unions
them under that equality.
These equality rules govern aggregate uniqueness, structural
comparison, support-entry premise unions, inherited-limitations
unions, composition, and Core equivalence. A profile cannot
substitute serialization equality, display equality, or byte equality
for the bound logical equality unless its immutable revision
explicitly defines those values to be identical.
6.2. Core Ingress, Validity Classes, and Fatal Precedence
Core receives one complete logical AppraisalInput. Carrier parsing,
carrier authentication, carrier critical-extension processing, and
construction of the logical input occur upstream. When an upstream
failure prevents construction of a complete input, there is no Core
result. A carrier or profile can report its own diagnostic alongside
that outcome, but it does not synthesize a partial Core appraisal or
translate a carrier error into a Core reason token.
The Core rejection checks are ordered and mutually classified as
follows:
Sergeev & Ikher Expires 26 April 2027 [Page 20]
Internet-Draft WEXP Appraisal Core October 2026
1. If the outer value is not an input record, or semantics_version
is absent or is not a text atom, Core returns
E_MALFORMED_NORMALIZED_INPUT.
2. If that readable value is not wexp-core-2, Core returns
E_UNSUPPORTED_SEMANTICS_VERSION without applying the version-
specific member rules below.
3. For wexp-core-2, a missing required member, unknown member, wrong
logical type, unknown closed-enum value, or malformed set, entry,
claim, token, or recorder relation returns
E_MALFORMED_NORMALIZED_INPUT.
4. A well-typed wexp-core-2 input that violates a cross-field
invariant returns E_PROFILE_MAPPING_INVALID. Cross-field
invariants include aggregate cardinality and keys, exact target
and context scope, the counter-evidence sentinel, qualifier
combinations, conditional ceiling_base, evaluation-scope
consistency and extension-key binding, and profile or registry
identity and token category.
5. If the structurally usable input has a non-empty valid
fatal_conditions set, Core returns that complete set through the
fixed rejection projection.
6. Otherwise an inadmissible asserted claim returns
E_CLAIM_OUT_OF_DOMAIN.
E_MALFORMED_NORMALIZED_INPUT, E_UNSUPPORTED_SEMANTICS_VERSION,
E_PROFILE_MAPPING_INVALID, and E_CLAIM_OUT_OF_DOMAIN are derived only
by the ordered Core checks and are invalid as supplied members of
fatal_conditions. The Core-defined supplied fatal members are
E_UNKNOWN_CRITICAL_SEMANTIC, E_INTEGRITY_INVALID, E_BINDING_MISMATCH,
and E_CHAIN_DESCRIPTION_INVALID. An immutable applied profile can
additionally register supplied fatal tokens. If any supplied member
is appraiser-derived, unbound, ambiguous, or in the wrong category,
the cross-field check returns only E_PROFILE_MAPPING_INVALID.
A supplied E_INTEGRITY_INVALID means that an integrity or
authentication failure affecting normalized interpretation was
identified while enough structurally usable logical input remains to
report that Core condition. A supplied E_BINDING_MISMATCH means
protected fields or mandatory mapping bindings are internally
contradictory while the same minimum remains available. Ordinary
negative or unevaluated exact-target binding is represented by a
correctly scoped aggregate and is non-fatal. A supplied
E_UNKNOWN_CRITICAL_SEMANTIC means an unrecognized critical Core or
applied mapping-profile semantic can affect normalized interpretation
Sergeev & Ikher Expires 26 April 2027 [Page 21]
Internet-Draft WEXP Appraisal Core October 2026
and cannot safely be ignored. It does not mean an unknown carrier
extension, and it is not an alias for a carrier-specific error.
E_CHAIN_DESCRIPTION_INVALID has the analogous meaning for a
structurally usable input produced by an applied composition profile.
Multiple valid supplied fatal members are returned together as a set.
No later check or diagnostic is added after any earlier rejection
branch wins. The fixed projection in Section 8.4 is the only Core
result for every rejection branch.
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.
Sergeev & Ikher Expires 26 April 2027 [Page 22]
Internet-Draft WEXP Appraisal Core October 2026
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
8.1. Supported Claim Set
Let B be the set of exact supported bases. A base b is in B if and
only if all of the following hold:
1. the unique aggregate base finding for b has supported target
binding and supported semantic validation;
2. the finding names the same target and evaluation context as the
appraisal input;
3. the boundary finding is supported, target-bound, and scoped to
that same target and context; and
4. the accepted Boundary Ceiling is at least b.
For each b in B, let Q(b) contain:
* PROV only when b is execution and a PROV finding for execution has
target_binding = supported and semantic_validation = supported for
the exact target and evaluation context; and
* IV only when an IV finding for b has target_binding = supported,
semantic_validation = supported, and independence_validation =
supported for the exact target and evaluation context.
The supported claim set is:
SupportedClaims = {
(b, A) | b is in B, A is a subset of Q(b),
and (PROV in A implies b == execution)
}
Sergeev & Ikher Expires 26 April 2027 [Page 23]
Internet-Draft WEXP Appraisal Core October 2026
The procedure evaluates all findings independently of the asserted
claim. It does not restrict B or Q(b) to the asserted base or
qualifiers.
MaximalSupportedClaims is the set of members of SupportedClaims that
are not structurally dominated by another member under Section 4.5.
The complete supported set remains authoritative because maximal
claims do not encode exact support for bases they structurally
dominate.
For every member of SupportedClaims, the appraiser also produces a
support entry containing the exact claim, the union of basis
references used for its base, boundary, and qualifiers, and the
limitations attached to those same premises. Limitations from failed
or unrelated findings are not attached to that support entry, but
remain available as evaluation diagnostics where applicable.
The result's inherited_limitations is the set union of the input's
inherited limitations; limitations from each counter-evidence or
profile-gap entry whose affected claims include the asserted claim, a
member of SupportedClaims, or all-admissible-claims; boundary
limitations; every support-entry limitation; and limitations attached
to findings that determine a reason or gap for the asserted claim.
Limitations on unrelated failed findings are excluded. This rule,
not implementation policy, determines which limitations are
applicable.
8.2. Verdict
A conforming Core appraiser MUST return exactly one of accept,
downgrade, or reject.
reject The normalized input cannot be safely interpreted, a fatal
condition is present, unknown critical semantics affect the
result, or the asserted claim is outside the admissible domain.
accept The asserted claim is an exact member of SupportedClaims and
counter-evidence does not block that exact claim.
downgrade The input is safely interpretable and the asserted claim
is admissible, but it is not exactly supported, or counter-
evidence blocks acceptance.
Sergeev & Ikher Expires 26 April 2027 [Page 24]
Internet-Draft WEXP Appraisal Core October 2026
downgrade means that an admissible assertion is not accepted on this
safely interpretable input. The assertion can lack exact positive
support, or it can have exact positive support while applicable
counter-evidence blocks acceptance. In the latter case
asserted_claim_supported remains true. The verdict does not imply
that every supported alternative is structurally below the assertion;
an alternative can be below, above, or incomparable.
Counter-evidence blocks a claim when at least one entry has status
not-evaluated, unresolved-material, or defeating and that entry's
affected_claims contains the claim or all-admissible-claims. not-
supplied and resolved-no-defeat entries do not block by themselves.
The reason token is derived from each applicable blocking entry; a
defeating entry for one claim never changes the status of a separate
not-evaluated entry for another claim.
8.3. Support Relation
For each maximal supported claim, the appraisal reports a pair
{supported_claim, relation}, where relation is one of equal, support-
below-claim, support-above-claim, or incomparable. If no claim is
supported, the relation array is empty.
The support relation compares typed claims structurally. It does not
summarize whether counter-evidence was assessed or whether acceptance
was blocked; those facts remain in their separate result components.
The separate Boolean asserted_claim_supported reports exact
membership in SupportedClaims. It remains true when the exact
asserted claim is supported but a structurally deeper alternative
causes the asserted claim not to appear in MaximalSupportedClaims.
The relation is explanatory. It MUST NOT replace the exact
membership test used for accept.
8.4. Normative Algorithm
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)
Sergeev & Ikher Expires 26 April 2027 [Page 25]
Internet-Draft WEXP Appraisal Core October 2026
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
Sergeev & Ikher Expires 26 April 2027 [Page 26]
Internet-Draft WEXP Appraisal Core October 2026
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,
Sergeev & Ikher Expires 26 April 2027 [Page 27]
Internet-Draft WEXP Appraisal Core October 2026
inherited_limitations = unavailable,
evaluation_context = unavailable,
evaluation_scope = unavailable
valid_PROV_finding requires the exact PROV conditions in Section 8.1.
valid_IV_finding requires the exact IV conditions there, including
supported independence validation. counter_blocks applies the per-
entry predicate in Section 8.2. applicable_counter_entries returns
only entries whose affected claims include the asserted claim or all-
admissible-claims and whose status blocks that claim under the same
predicate; it preserves per-entry scope. For every such entry, all
registered substantive tokens in c.reasons are added to
substantive_reasons; those tokens do not independently alter
counter_blocks or the verdict. The first diagnostic loop processes
only the finding and boundary rows of the claim-required diagnostic
matrix in Section 8.6. The three counter-status rows are processed
only by the subsequent counter-entry loop, which retains each entry's
exact affected claims. The matrix is exhaustive: Core emits no other
status-derived substantive token or Core gap entry. Profile gap
entries are already validated by the cross-field check and are copied
exactly only under the affected-claim predicate shown above. A
composition profile remaps inherited premise gaps to affected exact
chain claims before invoking Core; there is no unscoped inheritance
exception.
Every Core-derived finding gap entry has the row's token, the input
target and evaluation-context identifier,
affected_claims={input.asserted_claim}, and the basis-reference and
limitation sets of the aggregate that made the row true. If the row
concerns an absent aggregate, those two sets are empty. A counter-
derived gap entry instead retains that counter entry's exact affected
claims, basis references, and limitations. Two equal gap entries
collapse under the logical equality in Section 6.1; entries that
differ in any component remain separate. Substantive reason tokens
are a set, so simultaneous causes of the same token produce one token
without suppressing any distinct token.
Sergeev & Ikher Expires 26 April 2027 [Page 28]
Internet-Draft WEXP Appraisal Core October 2026
This token projection is deliberately a compact diagnostic summary.
It does not distinguish multiple causes of the same substantive
token, such as different findings producing E_EVIDENCE_NOT_BOUND.
Structured gap entries instead retain scope and basis references for
inheritance and current-capability interpretation. Per-cause
explanation of a substantive token requires the corresponding
normalized input and profile evidence to be retained and made
available under the applicable policy; the Core result alone does not
guarantee that availability. This revision defines no
substantive_reason_entries component. Adding one requires an
explicitly versioned result contract rather than silently changing
the twenty-component result.
All twenty result components are present even in the fixed rejection
projection. The logical value unavailable is distinct from an
omitted component; its encoding is defined by a result carrier. Set
and token ordering in a serialized result is defined by the result
carrier. The logical sets produced by Core are order-independent.
Given identical normalized input, a conforming implementation MUST
produce identical values for every required logical result component,
including support and gap entries, verdict, reasons, counter-evidence
entries, and inherited limitations.
8.5. Required Appraisal Result
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
}
Sergeev & Ikher Expires 26 April 2027 [Page 29]
Internet-Draft WEXP Appraisal Core October 2026
Every component shown above is REQUIRED; arrays and sets are empty
when they have no members. fatal_reasons is non-empty if and only if
the verdict is reject. Each support entry contains claim,
basis_refs[], and limitations[]. Each support relation contains
supported_claim and relation. Each evaluation-gap entry contains
token, target and context scope, affected claims, basis references,
limitations, and the optional current_scope_capability supplied on a
profile gap; evaluation_gaps is its set-valued token projection.
counter_evidence preserves every status, affected-claim set, basis-
reference set, reason set, and limitation set from the normalized
input without cross-claim status or reason collapse. There is no
normative singular verified_state. A presentation profile can select
a display state, but that projection MUST NOT replace the supported
claim set.
For an accept or downgrade result, boundary_ceiling is the accepted
ceiling only when the boundary finding, its target binding, target,
and context all pass; otherwise it is unavailable. boundary_grounding
preserves the input grounding even when the boundary is unsupported.
A reject result uses the fixed projection in Section 8.4. Its
semantics_version identifies this result contract; all input-derived
appraisal components are unavailable, and all derived support,
relation, substantive-reason, and gap sets are empty. Carrier or
profile diagnostics can be reported alongside the Core result, but
MUST NOT be inserted as a partial appraisal. This fixed projection
prevents two implementations from exposing different subsets of an
input that Core rejected.
8.6. Substantive Reasons and Evaluation Gaps
Substantive reasons describe why evidence does not support the
asserted claim. Evaluation gaps describe assessments that were not
performed. The two categories MUST remain distinguishable.
The ordered rejection checks and supplied-fatal meanings are defined
in Section 6.2. They run before this section. A safely interpreted
artifact whose evaluated semantics merely do not bind or cover the
asserted target or base uses a correctly scoped non-passing aggregate
and E_EVIDENCE_NOT_BOUND or E_EVIDENCE_COVERAGE_MISMATCH; it remains
non-fatal. A profile MUST NOT turn ordinary lack of exact support
into a fatal error.
The following claim-required matrix is exhaustive for Core-derived
non-fatal diagnostics. After the rejection checks, every applicable
row is evaluated independently exactly once: finding and boundary
rows use the first diagnostic loop, while the three counter-status
rows use only the counter-entry loop in Section 8.4. An absent
Sergeev & Ikher Expires 26 April 2027 [Page 30]
Internet-Draft WEXP Appraisal Core October 2026
aggregate triggers only its absence row; status rows require that
aggregate to be present. A present non-passing aggregate MUST NOT be
reported as missing evidence merely because it contributes no
supported claim. No catch-all fallback adds
E_MISSING_REQUIRED_EVIDENCE or E_EXACT_CLAIM_NOT_SUPPORTED beyond
their stated row predicates. A boundary-exceeded row requires a
usable boundary and a present asserted-base aggregate whose base is
deeper than the ceiling. Consequently a present supported base
excluded by the ceiling produces E_BASE_EXCEEDS_BOUNDARY, not
E_MISSING_REQUIRED_EVIDENCE. All simultaneously applicable distinct
tokens are emitted. No condition outside this matrix creates a Core-
derived non-fatal token.
E_BOUNDARY_NOT_SUPPORTED (substantive) Boundary status =
unsupported; source: boundary finding.
E_BOUNDARY_NOT_EVALUATED (gap) Boundary status = not-evaluated;
source: boundary finding.
E_EVIDENCE_NOT_BOUND (substantive) Boundary target_binding =
unsupported; source: boundary finding.
E_BOUNDARY_NOT_EVALUATED (gap) Boundary target_binding = not-
evaluated; source: boundary finding.
E_BASE_EXCEEDS_BOUNDARY (substantive) Usable boundary with asserted
base deeper than its ceiling; sources: boundary and asserted-base
findings.
E_MISSING_REQUIRED_EVIDENCE (substantive) Asserted-base aggregate
absent; source: none.
E_EVIDENCE_NOT_BOUND (substantive) Asserted-base target_binding =
unsupported; source: asserted-base finding.
E_BASE_NOT_EVALUATED (gap) Asserted-base target_binding = not-
evaluated; source: asserted-base finding.
E_EXACT_CLAIM_NOT_SUPPORTED (substantive) Asserted-base
semantic_validation = unsupported; source: asserted-base finding.
E_BASE_NOT_EVALUATED (gap) Asserted-base semantic_validation = not-
evaluated; source: asserted-base finding.
E_MISSING_REQUIRED_EVIDENCE (substantive) Asserted PROV aggregate
absent; source: none.
E_EVIDENCE_NOT_BOUND (substantive) Asserted PROV target_binding =
unsupported; source: PROV finding.
E_PROV_NOT_EVALUATED (gap) Asserted PROV target-binding or semantic
assessment not-evaluated; source: PROV finding.
E_PROV_NOT_SUPPORTED (substantive) Asserted PROV semantic_validation
= unsupported; source: PROV finding.
E_MISSING_REQUIRED_EVIDENCE (substantive) Asserted IV aggregate
absent; source: none.
E_EVIDENCE_NOT_BOUND (substantive) Asserted IV target_binding =
unsupported; source: IV finding.
E_IV_NOT_EVALUATED (gap) Asserted IV target-binding, semantic, or
independence assessment not-evaluated; source: IV finding.
Sergeev & Ikher Expires 26 April 2027 [Page 31]
Internet-Draft WEXP Appraisal Core October 2026
E_IV_NOT_SUPPORTED (substantive) Asserted IV semantic_validation =
unsupported; source: IV finding.
E_INDEPENDENCE_NOT_ESTABLISHED (substantive) Asserted IV
independence_validation = unsupported; source: IV finding.
E_COUNTER_EVIDENCE_NOT_EVALUATED (gap) Applicable counter entry
status = not-evaluated; source: that counter entry.
E_COUNTER_EVIDENCE_UNRESOLVED (substantive) Applicable counter entry
status = unresolved-material; source: that counter entry.
E_COUNTER_EVIDENCE_DEFEATING (substantive) Applicable counter entry
status = defeating; source: that counter entry.
For every blocking counter-evidence entry applicable to the asserted
claim, the appraiser MUST add every token in that entry's reasons set
to substantive_reasons, in addition to the Core token determined by
the entry status. Reasons on entries that do not affect the asserted
claim do not enter that projection but remain preserved in the result
entry.
A profile can add more specific registered tokens. It MUST NOT
suppress a Core-required token. A finding reason is projected only
from the boundary when it determines the asserted claim or a reported
support entry, from an asserted-base or asserted-qualifier finding,
or from a finding that is an exact premise of a reported support
entry. E_EVIDENCE_COVERAGE_MISMATCH, E_CHAIN_UNBOUND,
E_COMPOSITION_WARRANT_MISSING, and E_SHARED_VERIFICATION_ROOT use
this profile-reason path on a correctly scoped exact-role aggregate.
Profile-supplied gap entries, including E_COMPOSITION_NOT_EVALUATED,
are included only when their affected claims contain the asserted
claim, a member of SupportedClaims, or all-admissible-claims. A
supplied profile gap does not by itself block acceptance. A
composition profile remaps inherited premise diagnostics to affected
exact chain claims before Core invocation; unrelated diagnostics do
not change the logical reason or gap set. For counter-evidence entry
reasons, the stricter blocking-and-asserted-claim projection rule in
the preceding paragraph applies.
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.
Sergeev & Ikher Expires 26 April 2027 [Page 32]
Internet-Draft WEXP Appraisal Core October 2026
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.
Sergeev & Ikher Expires 26 April 2027 [Page 33]
Internet-Draft WEXP Appraisal Core October 2026
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
Sergeev & Ikher Expires 26 April 2027 [Page 34]
Internet-Draft WEXP Appraisal Core October 2026
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.
Sergeev & Ikher Expires 26 April 2027 [Page 35]
Internet-Draft WEXP Appraisal Core October 2026
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;
Sergeev & Ikher Expires 26 April 2027 [Page 36]
Internet-Draft WEXP Appraisal Core October 2026
* 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.
Sergeev & Ikher Expires 26 April 2027 [Page 37]
Internet-Draft WEXP Appraisal Core October 2026
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.
Sergeev & Ikher Expires 26 April 2027 [Page 38]
Internet-Draft WEXP Appraisal Core October 2026
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;
Sergeev & Ikher Expires 26 April 2027 [Page 39]
Internet-Draft WEXP Appraisal Core October 2026
* 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.
Sergeev & Ikher Expires 26 April 2027 [Page 40]
Internet-Draft WEXP Appraisal Core October 2026
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-
Sergeev & Ikher Expires 26 April 2027 [Page 41]
Internet-Draft WEXP Appraisal Core October 2026
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
Sergeev & Ikher Expires 26 April 2027 [Page 42]
Internet-Draft WEXP Appraisal Core October 2026
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.
Sergeev & Ikher Expires 26 April 2027 [Page 43]
Internet-Draft WEXP Appraisal Core October 2026
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.
+===+====================+==========================================+
|ID |Input override | Complete varying output |
+===+====================+==========================================+
|C01|Assert I; intent | S=M={I}; A=true; relations={I:equal}; |
| |finding supported; | accept; fatal/reasons/gaps={}. |
| |ceiling intent. | |
+---+--------------------+------------------------------------------+
|C02|Assert I; only | S=M={E}; A=false; relations={E:support- |
| |execution finding | above-claim}; downgrade; |
| |supported; ceiling | reasons={E_MISSING_REQUIRED_EVIDENCE}; |
| |execution. | fatal/gaps={}. |
+---+--------------------+------------------------------------------+
|C03|Assert E+V; | S={E,E+P}; M={E+P}; A=false; |
| |execution and PROV | relations={E+P:incomparable}; downgrade; |
| |findings supported; | reasons={E_MISSING_REQUIRED_EVIDENCE}; |
| |no IV finding; | fatal/gaps={}. |
| |ceiling execution. | |
+---+--------------------+------------------------------------------+
|C04|Assert E+P; | S={E,E+V}; M={E+V}; A=false; |
| |execution and | relations={E+V:incomparable}; downgrade; |
| |IV(execution) | reasons={E_MISSING_REQUIRED_EVIDENCE}; |
| |findings supported; | fatal/gaps={}. |
| |no PROV finding; | |
| |ceiling execution. | |
+---+--------------------+------------------------------------------+
|C05|Assert N+V; | S={N,N+V}; M={N+V}; A=true; |
| |invocation and | relations={N+V:equal}; accept; |
| |IV(invocation) | fatal/reasons/gaps={}. |
| |findings supported; | |
| |ceiling invocation. | |
+---+--------------------+------------------------------------------+
|C06|Assert E+V; | S={N,N+V,E}; M={N+V,E}; A=false; |
| |invocation, | relations={N+V:support-below- |
| |IV(invocation), and | claim,E:support-below-claim}; downgrade; |
| |execution findings | reasons={E_MISSING_REQUIRED_EVIDENCE}; |
Sergeev & Ikher Expires 26 April 2027 [Page 44]
Internet-Draft WEXP Appraisal Core October 2026
| |supported; no | fatal/gaps={}. |
| |IV(execution); | |
| |ceiling execution. | |
+---+--------------------+------------------------------------------+
|C07|Assert E; execution | S=M={}; A=false; relations={}; |
| |finding supported; | downgrade; |
| |ceiling invocation. | reasons={E_BASE_EXCEEDS_BOUNDARY}; |
| | | fatal/gaps={}. |
+---+--------------------+------------------------------------------+
|C08|Assert O; no base | S=M={}; A=false; relations={}; |
| |findings; ceiling | downgrade; |
| |observation. | reasons={E_MISSING_REQUIRED_EVIDENCE}; |
| | | fatal/gaps={}. |
+---+--------------------+------------------------------------------+
|C09|Assert inadmissible | reject; semantics_version=wexp-core-2; |
| |intent+PROV. | fatal={E_CLAIM_OUT_OF_DOMAIN}; S=M={}; |
| | | A=false; support |
| | | entries/relations/reasons/gaps={}; |
| | | target/asserted claim/boundary ceiling/ |
| | | boundary grounding/recorder relations/ |
| | | counter evidence/inherited limitations/ |
| | | evaluation context/evaluation |
| | | scope=unavailable. |
+---+--------------------+------------------------------------------+
|C10|Assert I; intent | S=M={I}; A=true; relations={I:equal}; |
| |supported; ceiling | downgrade; |
| |intent; one | reasons={E_COUNTER_EVIDENCE_UNRESOLVED}; |
| |counter-evidence | fatal/gaps={}. |
| |entry has status | |
| |unresolved-material | |
| |affecting I and | |
| |empty reasons. | |
+---+--------------------+------------------------------------------+
|C11|Target is chain T; | S=M={E}; A=true; relations={E:equal}; |
| |assert E. Exact | accept; fatal/reasons/gaps={}. The |
| |execution premises | execution support entry basis is |
| |s1 and s2, | {bd,s1,s2,adj,w}. |
| |adjacency adj, and | |
| |warrant w are | |
| |supported; the | |
| |composition profile | |
| |emits an execution | |
| |finding with basis | |
| |references | |
| |{s1,s2,adj,w}; | |
| |ceiling execution. | |
+---+--------------------+------------------------------------------+
|C12|Same as C11; | S=M={E}; A=true; relations={E:equal}; |
Sergeev & Ikher Expires 26 April 2027 [Page 45]
Internet-Draft WEXP Appraisal Core October 2026
| |boundary and a | accept; gaps={}; |
| |premise carry | inherited_limitations={L-boundary}; |
| |L-boundary; | fatal/reasons={}. The support entry also |
| |independent- | carries L-boundary. The unexercised IV |
| |verification=not- | capability remains visible in |
| |evaluated; no | evaluation_scope but creates no claim- |
| |warrant resolves | unrelated gap token. |
| |either. | |
+---+--------------------+------------------------------------------+
|C13|Assert E; execution | S=M={E}; A=true; relations={E:equal}; |
| |supported; ceiling | accept; gaps={E_IV_NOT_EVALUATED}; |
| |execution. A | fatal/reasons={}; |
| |profile gap entry | inherited_limitations={L-upstream}. |
| |for target T and | evaluation_gap_entries contains exactly |
| |context C has token | the supplied entry. |
| |E_IV_NOT_EVALUATED, | |
| |affects E, basis | |
| |u1, and limitation | |
| |L-upstream. | |
+---+--------------------+------------------------------------------+
|C14|Assert E; execution | S=M={E}; A=true; relations={E:equal}; |
| |supported; ceiling | downgrade; reasons={}; |
| |execution. One | gaps={E_COUNTER_EVIDENCE_NOT_EVALUATED}; |
| |counter entry is | fatal={}. The gap entry affects only E; |
| |defeating for I; a | both counter entries are preserved and |
| |separate entry is | no E_COUNTER_EVIDENCE_DEFEATING reason |
| |not-evaluated for | is emitted for E. |
| |E; both have empty | |
| |reasons. | |
+---+--------------------+------------------------------------------+
|C15|Assert E; execution | S=M={E}; A=true; relations={E:equal}; |
| |supported; ceiling | downgrade; |
| |execution. One | reasons={E_COUNTER_EVIDENCE_UNRESOLVED, |
| |counter entry has | P_COUNTER_FAIL}; gaps={}; fatal={}. The |
| |status unresolved- | copied counter entry retains its scoped |
| |material, affects | reason. |
| |E, has reason | |
| |P_COUNTER_FAIL, | |
| |basis p1, and no | |
| |limitations. | |
+---+--------------------+------------------------------------------+
|C16|Assert E; execution | S=M={E}; A=true; relations={E:equal}; |
| |supported; ceiling | accept; fatal/reasons/gaps={}; |
| |execution. A | inherited_limitations={}. The unrelated |
| |profile gap for | profile gap and its limitation are not |
| |target T and | projected. |
| |context C has token | |
| |E_IV_NOT_EVALUATED, | |
Sergeev & Ikher Expires 26 April 2027 [Page 46]
Internet-Draft WEXP Appraisal Core October 2026
| |affects only N+V, | |
| |basis u2, and | |
| |limitation | |
| |L-unrelated. | |
+---+--------------------+------------------------------------------+
Table 2: Normative Logical Appraisal Fixtures
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.
Sergeev & Ikher Expires 26 April 2027 [Page 47]
Internet-Draft WEXP Appraisal Core October 2026
*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
Sergeev & Ikher Expires 26 April 2027 [Page 48]
Internet-Draft WEXP Appraisal Core October 2026
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.
+================================+===========+=========+===========+
|Token |Category |Default |Current- |
| | |effect |scope |
| | | |capability |
+================================+===========+=========+===========+
|E_MALFORMED_NORMALIZED_INPUT |fatal |reject |none |
+--------------------------------+-----------+---------+-----------+
|E_UNSUPPORTED_SEMANTICS_VERSION |fatal |reject |none |
+--------------------------------+-----------+---------+-----------+
|E_CLAIM_OUT_OF_DOMAIN |fatal |reject |none |
+--------------------------------+-----------+---------+-----------+
|E_UNKNOWN_CRITICAL_SEMANTIC |fatal |reject |none |
+--------------------------------+-----------+---------+-----------+
|E_INTEGRITY_INVALID |fatal |reject |none |
+--------------------------------+-----------+---------+-----------+
|E_BINDING_MISMATCH |fatal |reject |none |
+--------------------------------+-----------+---------+-----------+
|E_PROFILE_MAPPING_INVALID |fatal |reject |none |
+--------------------------------+-----------+---------+-----------+
|E_CHAIN_DESCRIPTION_INVALID |fatal |reject |none |
+--------------------------------+-----------+---------+-----------+
|E_CHAIN_UNBOUND |substantive|downgrade|none |
+--------------------------------+-----------+---------+-----------+
|E_SHARED_VERIFICATION_ROOT |substantive|downgrade|none |
+--------------------------------+-----------+---------+-----------+
|E_BASE_EXCEEDS_BOUNDARY |substantive|downgrade|none |
+--------------------------------+-----------+---------+-----------+
|E_BOUNDARY_NOT_SUPPORTED |substantive|downgrade|none |
Sergeev & Ikher Expires 26 April 2027 [Page 49]
Internet-Draft WEXP Appraisal Core October 2026
+--------------------------------+-----------+---------+-----------+
|E_EXACT_CLAIM_NOT_SUPPORTED |substantive|downgrade|none |
+--------------------------------+-----------+---------+-----------+
|E_MISSING_REQUIRED_EVIDENCE |substantive|downgrade|none |
+--------------------------------+-----------+---------+-----------+
|E_EVIDENCE_NOT_BOUND |substantive|downgrade|none |
+--------------------------------+-----------+---------+-----------+
|E_EVIDENCE_COVERAGE_MISMATCH |substantive|downgrade|none |
+--------------------------------+-----------+---------+-----------+
|E_PROV_NOT_SUPPORTED |substantive|downgrade|none |
+--------------------------------+-----------+---------+-----------+
|E_IV_NOT_SUPPORTED |substantive|downgrade|none |
+--------------------------------+-----------+---------+-----------+
|E_COUNTER_EVIDENCE_UNRESOLVED |substantive|downgrade|none |
+--------------------------------+-----------+---------+-----------+
|E_COUNTER_EVIDENCE_DEFEATING |substantive|downgrade|none |
+--------------------------------+-----------+---------+-----------+
|E_COMPOSITION_WARRANT_MISSING |substantive|downgrade|none |
+--------------------------------+-----------+---------+-----------+
|E_INDEPENDENCE_NOT_ESTABLISHED |substantive|downgrade|none |
+--------------------------------+-----------+---------+-----------+
|E_BASE_NOT_EVALUATED |evaluation-|downgrade|none |
| |gap |if needed| |
| | |by claim | |
+--------------------------------+-----------+---------+-----------+
|E_BOUNDARY_NOT_EVALUATED |evaluation-|downgrade|none |
| |gap |if needed| |
| | |by claim | |
+--------------------------------+-----------+---------+-----------+
|E_PROV_NOT_EVALUATED |evaluation-|downgrade|none |
| |gap |if needed| |
| | |by claim | |
+--------------------------------+-----------+---------+-----------+
|E_IV_NOT_EVALUATED |evaluation-|downgrade|none |
| |gap |if needed| |
| | |by claim | |
+--------------------------------+-----------+---------+-----------+
|E_COMPOSITION_NOT_EVALUATED |evaluation-|downgrade|composition|
| |gap |if needed| |
| | |by claim | |
+--------------------------------+-----------+---------+-----------+
|E_COUNTER_EVIDENCE_NOT_EVALUATED|evaluation-|downgrade|none |
| |gap |when a | |
| | |counter | |
| | |entry is | |
| | |not | |
| | |evaluated| |
| | |and | |
Sergeev & Ikher Expires 26 April 2027 [Page 50]
Internet-Draft WEXP Appraisal Core October 2026
| | |affects | |
| | |the | |
| | |asserted | |
| | |claim | |
+--------------------------------+-----------+---------+-----------+
Table 3: Initial WEXP Appraisal Reason Codes
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.
16. 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/info/rfc2119>.
[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/info/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/info/rfc8174>.
17. Informative References
Sergeev & Ikher Expires 26 April 2027 [Page 51]
Internet-Draft WEXP Appraisal Core October 2026
[I-D.sergeev-wexp-core-00]
Sergeev, M. and V. Ikher, "The Witnessed Execution
Protocol (WEXP): Core Specification", Work in Progress,
Internet-Draft, draft-sergeev-wexp-core-00, July 2026,
<https://datatracker.ietf.org/doc/html/draft-sergeev-wexp-
core-00>.
[I-D.sergeev-wexp-core-01]
Sergeev, M. and V. Ikher, "The Witnessed Execution
Protocol (WEXP): Core Specification", Work in Progress,
Internet-Draft, draft-sergeev-wexp-core-01, 14 August
2026, <https://datatracker.ietf.org/doc/html/draft-
sergeev-wexp-core-01>.
[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/info/rfc9334>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/info/rfc9943>.
[WCC-CORE] Sergeev, M. A., "Witnessability Conceptual Core 1.0 —
Ratified Release Package", Version 1.0.0,
DOI 10.5281/zenodo.21865251, July 2026,
<https://doi.org/10.5281/zenodo.21865251>.
[WEXP-COVERAGE]
Sergeev, M., "WEXP Coverage: Claims, Evidence, and
Evaluation", Work in Progress, Internet-Draft, draft-
sergeev-wexp-coverage-00, 23 October 2026,
<https://datatracker.ietf.org/doc/html/draft-sergeev-wexp-
coverage-00>.
[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",
Version 1.1, DOI 10.5281/zenodo.21970802, August 2026,
<https://doi.org/10.5281/zenodo.21970802>.
Appendix A. Changes Since draft-sergeev-wexp-core-01
RFC Editor: please remove this appendix before publication as an RFC.
Sergeev & Ikher Expires 26 April 2027 [Page 52]
Internet-Draft WEXP Appraisal Core October 2026
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.
Sergeev & Ikher Expires 26 April 2027 [Page 53]
Internet-Draft WEXP Appraisal Core October 2026
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.
Sergeev & Ikher Expires 26 April 2027 [Page 54]
Internet-Draft WEXP Appraisal Core October 2026
+=================+======================+=======================+
| Conceptual | WEXP realization | Limit of |
| source | | correspondence |
+=================+======================+=======================+
| WCC 1.0, W-I1; | Exact target, typed | Four positive content |
| Sections 2.1 | claim, evaluation | bases and two |
| and 2.7 | context | qualifiers; not all |
| | | proposition classes |
+-----------------+----------------------+-----------------------+
| WCC 1.0, W-I2 | Carrier/profile | Core does not |
| | evaluation, Core | authenticate raw |
| | appraisal, external | artifacts or make |
| | reliance | policy decisions |
+-----------------+----------------------+-----------------------+
| WCC 1.0, W-I7 | Composition | Scoped operational |
| and Section 6.5 | warrants, limitation | constraints; no |
| | inheritance, | identity with a |
| | Boundary Ceiling | Support Envelope |
+-----------------+----------------------+-----------------------+
| WCC 1.0, W-I7, | Partial structural | No universal scalar |
| Preserved | order and maximal | measure or unique |
| Incomparability | supported | maximum is required |
| | alternatives | |
+-----------------+----------------------+-----------------------+
| WCC 1.0, W-I8 | Separate support, | Core does not |
| | counter-evidence, | implement the full |
| | gaps, and context | lifecycle or |
| | | probabilistic model |
+-----------------+----------------------+-----------------------+
| Model 1.1, | Four bases, PROV/IV, | Structural depth is |
| Qualified | exclusion-only | not exact-support |
| States and | ceiling | entailment; no axiom |
| Axiom BC | | proof is claimed |
+-----------------+----------------------+-----------------------+
Table 4: Selected Conceptual Correspondences
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
Sergeev & Ikher Expires 26 April 2027 [Page 55]
Internet-Draft WEXP Appraisal Core October 2026
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
Mikhail Sergeev (editor)
Independent Researcher
Email: mikhailsergeev369@gmail.com
Sergeev & Ikher Expires 26 April 2027 [Page 56]
Internet-Draft WEXP Appraisal Core October 2026
Vladimir Ikher
Independent Researcher
Email: ikherva@gmail.com
Sergeev & Ikher Expires 26 April 2027 [Page 57]