WEXP Core: Witnessability Appraisal Semantics for Execution-Related Claims

WEXP Core: Witnessability Appraisal Semantics for Execution-Related Claims Independent Researcher

mikhailsergeev369@gmail.com

Independent Researcher

ikherva@gmail.com

Security witnessability execution evidence boundary ceiling AI agents appraisal 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.

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 under the Witnessability Conceptual Core . 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.

Scope and Non-Goals This document specifies:

the content bases observation, intent, invocation, and execution;
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.

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. 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 . A carrier profile maps its fields and artifacts into the normalized input defined in . 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 .

Relationship to the Witnessability Conceptual Core and Model The Witnessability Conceptual Core 1.0 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 (, Section 6.5). The Witnessability Model 1.1 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 . 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. 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.

Relationship to Related Work RATS 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 . 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.

Joint Use with Coverage (Informative) 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.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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 . The fixed rejection result uses unavailable, as specified in .
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.

Conformance Surfaces This document distinguishes Core-appraiser conformance from mapping-profile, composition-profile, carrier, and result-carrier conformance. 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.

Claim Model

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.

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

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.

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. 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 ; an unknown base or qualifier, wrong logical type, or malformed qualifier set fails the structural check at step 3. The admissible claims are: 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.

Structural Order For structural comparison only: 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.

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: Legacy WL Display Labels

Display label	Typed claim
WL0	`(observation, {})`
WL1	`(intent, {})`
WL2	`(invocation, {})`
WL3	`(execution, {})`
WL4	`(execution, {PROV})`
WL5	`(execution, {IV})`

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.

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 , with parentheses around the pair and braces around the qualifier set. This is the canonical form for showing qualified states. A carrier that also exposes a single bare display label MUST NOT emit a record in a qualified state without carrying that record's authoritative typed state alongside the label. A bare display label is a projection of the typed state; it is never the authority for it, and it is never a sort key. Where a display label is produced, it MUST be produced by a declared projection with the following properties. The projection is profile-defined and justified: this document presumes no total order over typed states, and any projection into one requires justification by the profile that declares it. The projection is version-identifiable: a reader of a display value can determine which revision of which projection produced it. The projection never exceeds the typed state: the label denotes a maximal eligible bare label that is less than or equal to the typed state. When there is more than one such label, the ambiguity is resolved as specified below. Where the declared projection is ambiguous for the state consisting of the execution base with both the provenance and independent-verification qualifiers, the label denotes WL4. Both WL4 and WL5 are maximal bare labels below that state and neither exceeds the other, so the projection alone does not determine the value; this resolution is fixed by this document and is not left to the projection. A display label MUST equal the value of the declared projection applied to the authoritative typed state. Consistency is defined against the projection, not against any tabular image of it. A divergence between a display label and the authoritative typed state is a fatal defect of the carrier representation. The carrier profile rejects that representation and reports its own diagnostic. When the failure prevents construction of a complete AppraisalInput, no Core appraisal is produced. Any Core rejection follows the ordered checks in ; 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.

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 , 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. ; 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 . The mapping process MUST be claim-independent: it evaluates every available base material and every evidence role, not only the asserted base or asserted qualifiers. This permits an appraisal to report an incomparable supported alternative, such as PROV-supported execution when IV-supported execution was asserted. A passing base or qualifier finding MUST state that the evidence was semantically validated, accepted under the evaluation context, and bound to the exact target and exact base named by the finding. Presence of a reference, a valid digest, a signature, or an artifact whose media type suggests provenance or attestation is insufficient. A profile MUST distinguish unsupported, meaning the relevant assessment ran and failed, from not-evaluated, meaning the assessment was unavailable or outside the evaluation scope. It MUST preserve all applicable limitations and evaluation gaps. All findings are explicitly scoped. The boundary finding, every base and qualifier aggregate, and every profile-gap entry have a target equal to the top-level target and an evaluation_context_ref equal to the top-level evaluation-context identifier. A foreign-scoped aggregate is not negative evidence for this appraisal; it violates the normalized-input cross-field contract and produces E_PROFILE_MAPPING_INVALID. Evidence that was safely evaluated but covers or binds a different target or base is represented by a correctly scoped aggregate with a non-passing status and, when applicable, E_EVIDENCE_COVERAGE_MISMATCH or E_EVIDENCE_NOT_BOUND. The boundary finding additionally requires supported target binding before its ceiling can be used. A normalized input contains exactly one aggregated boundary finding, at most one aggregated base finding for each (target, base, evaluation_context) key, and at most one aggregated qualifier finding for each (target, qualifier, qualified_base, evaluation_context) key. A mapping profile combines multiple raw artifacts into that aggregate and preserves all basis references and limitations. Duplicate or conflicting aggregate findings are fatal and produce E_PROFILE_MAPPING_INVALID. A boundary finding with status = supported MUST contain ceiling_base. Its absence is a profile-mapping failure and produces E_PROFILE_MAPPING_INVALID. A supported boundary has a grounding value of asserted-only, attributed, or attested that the evaluation context accepts. grounding = not-evaluated is valid only with status = not-evaluated; either field paired differently produces E_PROFILE_MAPPING_INVALID. When boundary status is unsupported or not-evaluated, a present ceiling_base is diagnostic carrier metadata only and is ignored by the Core algorithm. A PROV aggregate is valid only when qualified_base = execution and independence_validation = not-applicable. An IV aggregate is valid only when qualified_base is one of the four content bases and independence_validation is supported, unsupported, or not-evaluated. PROV on another base, IV with not-applicable, or another recognized but disallowed qualifier-field combination produces E_PROFILE_MAPPING_INVALID. An unknown closed-enum member or wrong logical type is malformed. A mapper does not delete or repair an invalid qualifier aggregate. A valid qualifier contributes support only when its exact qualified base is independently in B. counter_evidence is an entry set, not a single strongest status. When no counter-evidence was supplied it contains exactly one not-supplied entry with empty affected claims, basis references, reasons, and limitations. Otherwise not-supplied is absent and every entry names at least one admissible affected claim or all-admissible-claims. not-evaluated means supplied counter-evidence could not be assessed; resolved-no-defeat means it was assessed and does not defeat the named claims; unresolved-material means it is material but unresolved; and defeating means it affirmatively defeats the named claims. When the affected claims cannot be narrowed safely, affected_claims is all-admissible-claims. Entries with different affected-claim sets or statuses MUST NOT be collapsed into one status. A challenge process defined outside this document can supply a counter-evidence entry when the applicable profile admits the challenge and binds it to affected claims for this exact target and context. A challenge to the eligibility of a profile or evaluation context is not automatically an action-level counter entry; it can instead require a new context or a new mapping assessment. Core defines neither the challenge process nor its admission policy. Every member of a counter entry's reasons set MUST be a token registered in the substantive category by a registry applicable to the mapping profile and MUST apply to that entry's affected claims. Fatal tokens are carried in fatal_conditions, and evaluation-gap tokens are carried in profile_evaluation_gaps; they MUST NOT appear in counter_evidence[].reasons. A non-Core token resolves uniquely, including category, through exactly one immutable registry revision identified by an applied profile_identifier; absence, ambiguity, or category disagreement produces E_PROFILE_MAPPING_INVALID. Entry reasons are explanatory and do not change the entry status or block a claim by themselves. Core-derived counter-status tokens are emitted in addition to, not instead of, applicable entry reasons. Likewise, every token in reasons[] on a boundary, base, or qualifier finding MUST be registered in the substantive category and apply to that finding. A non-Core token resolves uniquely through an immutable registry revision identified by an applied profile_identifier. Fatal tokens belong in fatal_conditions, and evaluation-gap tokens belong in profile_evaluation_gaps. An absent, ambiguous, unregistered, or miscategorized finding reason is a profile-mapping failure and produces E_PROFILE_MAPPING_INVALID. Every member of fatal_conditions MUST be a token registered in the fatal category by the Core registry or a registry applicable to the mapping profile. Core tokens are bound to the semantics_version; every non-Core token resolves uniquely through an immutable registry revision identified by an applied profile_identifier. An absent, ambiguous, unregistered, or miscategorized member is a profile-mapping failure; the appraiser returns E_PROFILE_MAPPING_INVALID instead of treating that member as fatal. profile_evaluation_gaps carries structured gaps supplied by a mapping or composition profile that are not otherwise recoverable from a Core finding status. Every entry is scoped to the exact target and evaluation context and contains a token registered in the evaluation-gap category, at least one admissible affected claim or all-admissible-claims, basis references, and limitations. A non-Core token resolves uniquely through an immutable registry revision identified by an applied profile_identifier. The optional current_scope_capability is present only when the entry represents the current appraiser's unperformed authenticity or composition assessment; it names exactly that initial capability. The token registration also identifies that same capability: E_COMPOSITION_NOT_EVALUATED is initially registered for composition, while authenticity requires an exact profile token registered for authenticity assessment. A profile can register another evaluation-gap token for either capability. A marker-token capability mismatch produces E_PROFILE_MAPPING_INVALID. Absence of the marker means that the entry is inherited or otherwise diagnostic and does not determine a current capability status. A composition profile uses this field to preserve applicable upstream gaps after remapping them to the exact chain target. The ordered classification in 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.

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

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:

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.
If that readable value is not wexp-core-2, Core returns E_UNSUPPORTED_SEMANTICS_VERSION without applying the version-specific member rules below.
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.
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.
If the structurally usable input has a non-empty valid fatal_conditions set, Core returns that complete set through the fixed rejection projection.
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 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 is the only Core result for every rejection branch.

Boundary Ceiling For every supported claim (b, A), b MUST NOT exceed the accepted boundary_finding.ceiling_base. Qualifiers do not alter this comparison. 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 . A string or structural descriptor asserted by a producer is at most asserted-only; a valid signature associated with an accepted identity can make it attributed; and an applicable boundary-grounding profile can make it attested. Attribution is not proof of actual boundary control. boundary_finding.status = supported means that the boundary predicate required by the named evaluation context passed. The evaluation context MUST identify the minimum acceptable grounding. A profile MUST NOT mark a boundary supported merely because a boundary name or descriptor is present. An asserted-only or attributed finding can be supported only when the evaluation context explicitly accepts that grounding class; the result still reports the weaker grounding and its limitations. The boundary status has deterministic precedence. When status = not-evaluated, no base is added and the appraiser records E_BOUNDARY_NOT_EVALUATED. When status = unsupported, no base is added and it records E_BOUNDARY_NOT_SUPPORTED. Only status = supported with target_binding = supported and matching target and context makes ceiling_base usable. A failed target binding prevents use of the ceiling and adds the Core substantive reason E_EVIDENCE_NOT_BOUND; an unevaluated target binding prevents use of the ceiling and adds the Core gap E_BOUNDARY_NOT_EVALUATED, as specified by .

Appraisal Procedure

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:

the unique aggregate base finding for b has supported target binding and supported semantic validation;
the finding names the same target and evaluation context as the appraisal input;
the boundary finding is supported, target-bound, and scoped to that same target and context; and
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: 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 . 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.

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.

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.

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.

Normative Algorithm valid_PROV_finding requires the exact PROV conditions in . valid_IV_finding requires the exact IV conditions there, including supported independence validation. counter_blocks applies the per-entry predicate in . 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 . 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 ; 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. 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.

Required Appraisal Result 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 . 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.

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 . 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 . An absent 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.
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.

Composition Composition-profile mapping and Core appraisal are separate conformance surfaces. Core consumes only an ordinary normalized input for the exact chain target; it does not consume raw segments, adjacency records, or warrants and does not infer a chain finding. A Core appraiser can implement the complete Core procedure without implementing a composition profile. An implementation that separately claims composition-profile conformance identifies the immutable composition-profile revision and satisfies the additional mapping obligations in this section. A chain claim MUST NOT be derived by numeric minimum, by a display label, or by a meet of segment states alone. A composition profile MUST identify:

the exact chain target;
the exact segment claims used as premises;
the validated adjacency bindings;
the composition warrant mapping those premises to the chain claim;
the evaluation context shared by the premises; and
the independence of the independent-verification roots relied on by the premises.

The identified composition-profile revision defines the logical types and predicates for premises, adjacency bindings, warrants, their exact identity, and their target and context equality. The profile evaluates those values and emits ordinary normalized base and qualifier findings for the exact chain target. The ordinary Core algorithm then appraises those findings; composition is not a second Core appraisal algorithm. A chain base finding is supported only if every named premise is exactly supported and every required binding and warrant evaluates to supported under that immutable profile. An absent or unsupported required adjacency binding produces no positive chain finding; the profile places substantive E_CHAIN_UNBOUND on the correctly scoped non-passing chain-role aggregate. It does the same with E_COMPOSITION_WARRANT_MISSING for an absent or unsupported warrant. Where two premises rely on the same independent-verification root, that root is not independent for the purposes of this warrant, and the profile places substantive E_SHARED_VERIFICATION_ROOT on the correctly scoped non-passing chain-role aggregate. Correctness of the composition operator is not itself a warrant; the warrant consists of the binding, the coverage of the inter-segment link, and the independence of the verification roots. A required assessment that was not performed is represented by a structured E_COMPOSITION_NOT_EVALUATED profile-gap entry affecting the exact chain claim. These are safely interpretable support failures and lead to downgrade when the chain claim is not otherwise supported. If a malformed or internally contradictory chain description still permits a structurally usable Core input, the profile supplies fatal E_CHAIN_DESCRIPTION_INVALID; otherwise the upstream failure produces no Core appraisal under . Individual segment appraisals are unaffected. For this warrant, an independent-verification root is the profile-identified evidentiary source or control dependency whose independence is relied on. It is not merely a public authentication trust anchor. Two premises that repeat one verifier's assessment share an evidentiary root even if they carry different signatures. Conversely, two separately produced assessments do not share an evidentiary root merely because their records authenticate through the same public certification authority; the profile still evaluates their actual observation and control dependencies. A common authentication anchor alone neither establishes nor refutes the independence required by the warrant. For the chain-base warrant described above, an assessed absence or failure of required adjacency, of the warrant, or of the required verification-root independence sets semantic_validation = unsupported on the exact chain-base aggregate and adds the corresponding reason from the preceding paragraphs. The aggregate's target_binding retains the independently assessed binding of the evidence to the exact chain target. A failed inter-segment adjacency is a failed premise of the chain warrant; it is not by itself a failed association with that target. Thus E_CHAIN_UNBOUND does not by itself set target_binding = unsupported. If exact-target binding also fails, that field is independently unsupported. All applicable matrix diagnostics in are then emitted: for example, an otherwise supported asserted chain base with failed adjacency produces both E_CHAIN_UNBOUND and E_EXACT_CLAIM_NOT_SUPPORTED; it adds E_EVIDENCE_NOT_BOUND only when the separate exact-target-binding predicate fails. For a separately evaluated chain qualifier, the immutable composition profile identifies the exact affected qualifier role and the predicate-to-field mapping. An assessed failure of that qualifier's semantic warrant sets its semantic_validation to unsupported; an assessed failure of IV independence sets the IV aggregate's independence_validation to unsupported. Other fields retain their actual assessment results. An unperformed assessment sets its governed field to not-evaluated, with consistent evaluation scope and the applicable structured composition gap. Multiple failed or unperformed predicates retain all their field values, reasons, and applicable gaps. These are obligations of the composition profile; Core does not infer or rewrite a field from a supplied reason token. A qualifier failure does not change an independently supported chain base unless that failed predicate is also required by the base's own warrant. An inherited PROV qualifier requires exact PROV support for every required segment plus provenance coverage of every required inter-segment binding. An inherited IV qualifier requires exact IV support at the relevant base for every required segment, covered chain bindings, and a passing chain independence assessment. Alternatively, a profile can establish a new chain-level PROV or IV qualifier from a separate exact chain-level finding and explicit warrant; that finding is evaluated by the ordinary qualifier rules and cannot be inferred from segment depth alone. A composed input MUST inherit the set union of recorder relations and of unresolved limitations, freshness and revocation limits, coverage limits, and trust-context restrictions of its premises unless a named warrant explicitly resolves a specific item. Applicable upstream evaluation gaps are remapped to the exact chain target and affected chain claims and carried as structured profile_evaluation_gaps entries with their original basis references and limitations. A warrant that resolves a gap names the exact entry and records the resolving basis; it cannot silently delete all gaps of the same token. Counter-evidence entries from all premises and chain-level findings are retained separately. Entries can be coalesced only when status and affected-claim set are identical; their basis references, reasons, and limitations are then set-unioned. Statuses, affected-claim sets, or reason sets across different scopes MUST NOT be collapsed or promoted by precedence. If any evaluator cannot narrow affected claims safely, that entry uses all-admissible-claims. The composed set contains one not-supplied entry only when every premise and chain-level input reports not-supplied; otherwise all such sentinel entries are omitted. A chain claim and a terminal-action claim are distinct. Support for a chain does not establish completion, terminal effect, or goal satisfaction. A terminal-action claim uses the terminal segment's exact support plus a validated binding to the selected terminal action. The Core conformance evidence in covers only the appraisal of normalized composition outputs unless a separate composition-profile claim is declared. The C11 and C12 fixtures in 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.

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 , 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 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 . 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 or provide an additional proof of that rule. It also does not combine the separate prohibition on raising a captured content base through verification with the warrant requirement above. The following limits are normative:

observation does not imply intent, invocation, or execution;
intent does not imply authority, authorization validity, invocation, or execution;
invocation does not imply execution, completion, or effect;
execution does not imply completion of a larger process, durable external effect, goal satisfaction, correctness, safety, or policy compliance;
a provenance artifact by itself does not establish runtime occurrence; a PROV-qualified WEXP claim presupposes separately established exact execution support, and IV does not imply PROV;
a signature authenticates bytes under a key; it does not establish content truth or boundary control;
a transparency receipt supports only the exact predicate established by its verification under the applicable profile; a promise of inclusion is not proof of inclusion, and neither by itself establishes continuing custody, PROV, IV, or execution;
presence of records does not establish completeness of coverage;
absence of a record does not establish nonoccurrence;
a sole counter_evidence entry with status = not-supplied does not establish absence of counter-evidence; and
aggregation and transformation do not remove upstream limitations unless an explicit warrant resolves them.

Cross-Carrier Equivalence Two carrier inputs are Core-equivalent when, under the same semantics version and evaluation context, they normalize under 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.

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 together with any additional vectors declared in the conformance scope. Its manifest identifies the exact Core source revision, every vector and its input and complete expected logical appraisal, the fixture-profile revision, encoding and comparison rules, and the harness revision. It binds the package files by their names and digests. The expected appraisals are fixed independently of the implementation outputs before the comparison run. A package cannot replace or contradict the logical expectations in this document. The conformance record MUST provide immutable identifiers and retrieval locations for the reviewed Requirements Registry and vector-package manifest, together with the digest algorithms, the exact bytes hashed, and their digests. The claimant MUST make those bound artifacts retrievable by the recipient to check the claimed scope. These artifacts and their publication or access arrangements are supplied with the claim; no private project registry or unavailable package is an implicit normative dependency of this specification. For that exact scope, PASS means that the implementation satisfies every bound reviewed requirement, every required frozen vector was parsed under its identified non-normative harness, every complete logical appraisal equaled the independently frozen expected appraisal, and the execution recorded zero mismatch, not-run, and blocked cases. The normative authority remains this specification and its reviewed requirements; vector comparison is evidence, not the source of an expectation. A full conformance record enumerates all reviewed Core-appraiser requirements and all required vectors for the identified revision. An implementation that supports a smaller surface lists the exact included and omitted requirement and vector identifiers and labels the result PARTIAL; it does not claim full Core conformance. Mapping-profile conformance, composition-profile conformance, carrier conformance, and result-carrier conformance are separate claims with separate immutable profile identities. A Core-appraiser record does not establish that raw evidence was correctly authenticated, interpreted, or normalized by an untested upstream profile. PASS is not certification, proof of correctness or completeness, proof of security, evidence of interoperability with an untested implementation or carrier, IETF acceptance, or authority to make policy decisions. No conformance record changes the specification-to-requirements-to-vectors-to-implementation authority direction. evaluation_scope is an unordered map from capability names to exactly one of evaluated or not-evaluated. The following initial names are closed for wexp-core-2:

carrier-mapping;
authenticity;
target-binding;
boundary-grounding;
observation-support;
intent-support;
invocation-support;
execution-support;
provenance-support;
independent-verification;
composition; and
counter-evidence.

Every initial name MUST appear exactly once. An extension key is the logical pair (profile_identifier, local_name) of two non-empty text atoms, where the immutable applied profile identifier occurs in evaluation_context.profile_identifiers and local_name names an extension in that revision. The pair is its identity. Core ignores an extension status for support and gap derivation but preserves the exact pair and status in the result. A malformed pair or a missing, empty, or non-text atom produces E_MALFORMED_NORMALIZED_INPUT at the structural check in . 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 , rather than a Core result with this capability unperformed. For finding-backed capabilities, evaluated means discovery of applicable material in that declared domain completed and every supplied assessment governed by the capability has a status other than not-evaluated. Absence of an aggregate under that value means the discovery found no candidate for that role. not-evaluated records an applicable unperformed assessment or an unexercised role. If the asserted claim requires an unevaluated base or qualifier role, its exact aggregate is present; a base or PROV aggregate has a governed not-evaluated field. The shared-role rule below determines which IV or binding assessments were not performed. For counter-evidence, evaluated means the current capability-level procedure completed its assessment of the supplied entry set under the declared profile domain, including recording any entry it could not resolve. not-evaluated means that procedure was not completed. Neither value asserts discovery of all counter-evidence. Individual entries retain their own assessment statuses, including previously assessed entries preserved when the current procedure is not completed. An evaluated capability can therefore contain a not-evaluated entry. Core MUST NOT replace an entry status with the capability value. The capability value alone MUST NOT create an ingress rejection, substantive finding, or evaluation gap for counter-evidence. The entry's status and affected claims govern its effect under . For each base-support capability and for provenance-support, if the corresponding aggregate is present and the capability is not-evaluated, at least one governed status field in that aggregate MUST be not-evaluated, independently of whether the role is asserted. A present wholly assessed single-role aggregate paired with not-evaluated violates the cross-field contract and produces E_PROFILE_MAPPING_INVALID. An absent unasserted aggregate can represent an unexercised capability without creating a claim-specific gap. target-binding and independent-verification are shared across exact roles. Their not-evaluated summary does not replace a passing assessment for a different exact role. An unexercised or unperformed unrelated role can be unrepresented, as in C12; a supplied aggregate retains each actual assessment status. A claim-required IV aggregate is present when the shared IV capability is not-evaluated, but its passing statuses need not be changed merely because another role was not assessed. Claim-specific gaps are derived from the exact required aggregate, not from the shared summary alone. The external authenticity and composition capabilities use a fully syntactic rule: their scope value is not-evaluated if and only if at least one profile-gap entry names that capability in current_scope_capability, and is evaluated if and only if no entry names it. A marked entry can affect any exact admissible claim; its projection into the result remains governed separately by the affected-claim rule. Core does not decide from profile-defined trust data whether an external assessment was required. The governed status fields are: every finding's target_binding for target-binding; boundary status, binding, and grounding for boundary-grounding; the corresponding base aggregate's binding and semantic status for each base-support capability; PROV binding and semantic status for provenance-support; IV binding, semantic, and independence status for independent-verification. Counter-entry statuses are excluded from this governed-field test and follow the separate counter-evidence rule above. A scope value of evaluated with a governed not-evaluated status, a claim-required finding-backed not-evaluated capability without its aggregate, a current-scope marker whose capability is not not-evaluated, or an external capability value without the required marker presence or absence violates the cross-field contract and produces E_PROFILE_MAPPING_INVALID. A profile_evaluation_gaps entry without current_scope_capability can preserve a gap from an upstream or composed premise under its own exact scope. Its presence does not change the current appraiser's capability status. Core determines current-scope consistency only from the explicit optional field and never interprets opaque basis references for that purpose. An evaluation capability MUST NOT be used as evidence and MUST NOT create or structurally cap a claim. A role-specific Core gap entry is emitted only by the claim-required matrix when its aggregate is required by the asserted claim. A valid profile-gap entry is projected under its affected-claim rule. Otherwise the scope map alone records the unexercised capability and does not become a reason, gap, or substantive finding. Re-appraisal under a different evaluation context produces a new scoped result. It does not automatically invalidate a historical appraisal or establish that the historical result applies in the new context.

Normative Semantic Test Vectors C01 through C16 are normative logical cases, not a wire format. A conformance record binds an executable representation through an exact manifest that identifies the source revision, reviewed requirement and case identifiers, non-normative harness schema, fixture bytes, and frozen expected logical appraisals. The representation and comparison procedure do not add a Core serialization requirement. A representation passes a case only when its complete decoded logical input and complete observed appraisal equal the normative input and expectation stated here. The logical fixtures below are normative. Common input values are: semantics_version=wexp-core-2; target T; evaluation-context identifier C; evaluation time 2026-10-12T00:00:00Z; trust-configuration atom core02-fixture-trust-1, which accepts attributed boundary grounding; the singleton applied-profile set containing the immutable fixture identity defined below; a supported, target-bound, attributed boundary finding for T and C with basis bd and the stated ceiling; empty recorder relations, profile evaluation gaps, inherited limitations, and fatal conditions; counter-evidence consisting of one entry whose status is not-supplied and whose affected-claim, basis-reference, reason, and limitation sets are empty; and every initial evaluation-scope capability set to evaluated. Every supported base or qualifier finding has target T, context C, supported target binding and semantic validation, empty reasons and limitations, and the exact basis-reference set defined below. Supported IV additionally has supported independence validation; PROV uses not-applicable. A finding not stated in a row is absent. For C09, the otherwise unstated boundary ceiling is execution; the fixed rejection projection makes this input field unavailable in the result. Unless a row explicitly states otherwise, the boundary finding has empty reasons and limitations. Each counter entry introduced by a row has empty basis_refs, reasons, and limitations except for values explicitly stated in that row. A row that introduces counter entries replaces the common not-supplied entry. Profile-gap entries have no current_scope_capability unless explicitly stated. In C12, the composed execution finding carries L-boundary inherited from the stated premise. Unless a row explicitly overrides its basis-reference set, each base finding has a singleton basis-reference set whose local name is O for observation, I for intent, N for invocation, and E for execution. The PROV(execution) finding uses P(E). IV findings for observation, intent, invocation, and execution use V(O), V(I), V(N), and V(E), respectively. Each local name denotes the profile-scoped atom under the fixture profile defined below. These are exact basis-reference names, not aliases of the full base or qualifier names. C11 and C12 instead use their explicitly stated execution basis-reference set {s1,s2,adj,w}. The immutable fixture profile identity is the following exact text atom: draft-sergeev-wexp-core-02/fixture-1 This local fixture identity is not an IANA registration or a network locator. This paragraph completely defines its revision: P_COUNTER_FAIL is registered in the substantive category, is applicable to C15's counter entry, and means that the fixture's assessment found the stated material counter-evidence unresolved. It adds no status, evidence, or independent acceptance condition. The profile defines no recorder-relation tokens or scope-extension names. Opaque fixture atoms compare by exact Unicode scalar text; a displayed basis reference or limitation denotes the ordered pair of this profile identity and its displayed local name. No URI, case, or Unicode normalization is implicit. A harness MUST NOT infer an applied profile solely from a token or basis reference. An executable representation pins these profile contents and its own encoding rules in its manifest. In the table, O, I, N, and E mean unqualified observation, intent, invocation, and execution. +P and +V mean PROV and IV. S is supported_claims, M is maximal_supported_claims, and A is asserted_claim_supported. For each member of S, support_entries contains exactly one entry whose basis-reference set is the union of bd, its base finding's basis references, and any qualifier findings' basis references; its limitations are the union of those premises. support_relations contains the displayed relation for each member of M. gaps={} also means evaluation_gap_entries={}. For accept and downgrade rows, fields not varied by a row equal the common input values and carry through to the output. A reject row instead uses the complete fixed projection in . Normative Logical Appraisal Fixtures

ID	Input override	Complete varying output
C01	Assert `I`; intent finding supported; ceiling intent.	`S=M={I}; A=true; relations={I:equal}; accept; fatal/reasons/gaps={}`.
C02	Assert `I`; only execution finding supported; ceiling execution.	`S=M={E}; A=false; relations={E:support-above-claim}; downgrade; reasons={E_MISSING_REQUIRED_EVIDENCE}; fatal/gaps={}`.
C03	Assert `E+V`; execution and PROV findings supported; no IV finding; ceiling execution.	`S={E,E+P}; M={E+P}; A=false; relations={E+P:incomparable}; downgrade; reasons={E_MISSING_REQUIRED_EVIDENCE}; fatal/gaps={}`.
C04	Assert `E+P`; execution and IV(execution) findings supported; no PROV finding; ceiling execution.	`S={E,E+V}; M={E+V}; A=false; relations={E+V:incomparable}; downgrade; reasons={E_MISSING_REQUIRED_EVIDENCE}; fatal/gaps={}`.
C05	Assert `N+V`; invocation and IV(invocation) findings supported; ceiling invocation.	`S={N,N+V}; M={N+V}; A=true; relations={N+V:equal}; accept; fatal/reasons/gaps={}`.
C06	Assert `E+V`; invocation, IV(invocation), and execution findings supported; no IV(execution); ceiling execution.	`S={N,N+V,E}; M={N+V,E}; A=false; relations={N+V:support-below-claim,E:support-below-claim}; downgrade; reasons={E_MISSING_REQUIRED_EVIDENCE}; fatal/gaps={}`.
C07	Assert `E`; execution finding supported; ceiling invocation.	`S=M={}; A=false; relations={}; downgrade; reasons={E_BASE_EXCEEDS_BOUNDARY}; fatal/gaps={}`.
C08	Assert `O`; no base findings; ceiling observation.	`S=M={}; A=false; relations={}; downgrade; reasons={E_MISSING_REQUIRED_EVIDENCE}; fatal/gaps={}`.
C09	Assert inadmissible intent+PROV.	`reject; semantics_version=wexp-core-2; 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 supported; ceiling intent; one counter-evidence entry has status `unresolved-material` affecting `I` and empty reasons.	`S=M={I}; A=true; relations={I:equal}; downgrade; reasons={E_COUNTER_EVIDENCE_UNRESOLVED}; fatal/gaps={}`.
C11	Target is chain `T`; assert `E`. Exact execution premises `s1` and `s2`, adjacency `adj`, and warrant `w` are supported; the composition profile emits an execution finding with basis references `{s1,s2,adj,w}`; ceiling execution.	`S=M={E}; A=true; relations={E:equal}; accept; fatal/reasons/gaps={}`. The execution support entry basis is `{bd,s1,s2,adj,w}`.
C12	Same as C11; boundary and a premise carry `L-boundary`; `independent-verification=not-evaluated`; no warrant resolves either.	`S=M={E}; A=true; relations={E:equal}; accept; gaps={}; inherited_limitations={L-boundary}; fatal/reasons={}`. The support entry also carries `L-boundary`. The unexercised IV capability remains visible in `evaluation_scope` but creates no claim-unrelated gap token.
C13	Assert `E`; execution supported; ceiling execution. A profile gap entry for target `T` and context `C` has token `E_IV_NOT_EVALUATED`, affects `E`, basis `u1`, and limitation `L-upstream`.	`S=M={E}; A=true; relations={E:equal}; accept; gaps={E_IV_NOT_EVALUATED}; fatal/reasons={}; inherited_limitations={L-upstream}`. `evaluation_gap_entries` contains exactly the supplied entry.
C14	Assert `E`; execution supported; ceiling execution. One counter entry is `defeating` for `I`; a separate entry is `not-evaluated` for `E`; both have empty reasons.	`S=M={E}; A=true; relations={E:equal}; downgrade; reasons={}; gaps={E_COUNTER_EVIDENCE_NOT_EVALUATED}; fatal={}`. The gap entry affects only `E`; both counter entries are preserved and no `E_COUNTER_EVIDENCE_DEFEATING` reason is emitted for `E`.
C15	Assert `E`; execution supported; ceiling execution. One counter entry has status `unresolved-material`, affects `E`, has reason `P_COUNTER_FAIL`, basis `p1`, and no limitations.	`S=M={E}; A=true; relations={E:equal}; downgrade; reasons={E_COUNTER_EVIDENCE_UNRESOLVED, P_COUNTER_FAIL}; gaps={}; fatal={}`. The copied counter entry retains its scoped reason.
C16	Assert `E`; execution supported; ceiling execution. A profile gap for target `T` and context `C` has token `E_IV_NOT_EVALUATED`, affects only `N+V`, basis `u2`, and limitation `L-unrelated`.	`S=M={E}; A=true; relations={E:equal}; accept; fatal/reasons/gaps={}; inherited_limitations={}`. The unrelated profile gap and its limitation are not projected.

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 . 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 , with boundary_grounding = unavailable. Result carriers and presentation profiles preserve the reported grounding without promoting it to a stronger class. Relying parties MUST NOT erase this distinction. Self-report. A self-report can support a report about what the actor asserted. It does not provide third-party non-repudiation merely because its content base is deep or its bytes are signed. Independent verification. Independence is profile- and context-relative. Different keys or roots can remain under common administrative control, while a shared public root does not necessarily destroy operational independence. A passing IV finding needs an explicit assessment basis. Counter-evidence. Unresolved material counter-evidence blocks acceptance. No supplied counter-evidence is not proof that none exists. Coverage and nonoccurrence. A set of valid records can be incomplete. A missing record can reflect omission, capture failure, refusal to emit, loss, or an action that never occurred. WEXP Core does not distinguish those cases without positive profile-defined evidence. Composition. Composition is a common inflation point. Exact premises, bindings, warrants, and limitation inheritance are required. A chain appraisal cannot be used as evidence for a terminal effect unless a separate predicate establishes that exact claim. Evaluation context. Trust anchors, profile versions, policies, evaluation time, revocation state, and appraiser capabilities affect findings. An accept or downgrade appraisal carries the evaluation context so that the result is not detached from those dependencies. A reject appraisal instead uses the fixed projection in , 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.

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 . 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 . Its value is none for every fatal or substantive token, and for an evaluation-gap token that is not permitted with current_scope_capability. An evaluation-gap registration with value authenticity or composition permits that marker only for the named capability. The referenced specification defines the exact assessment represented by that binding. Initially, E_COMPOSITION_NOT_EVALUATED is bound to composition; no other initial token is permitted with that marker. An applicable profile registration supplies any additional binding, including a token for authenticity. A marker naming a different capability or a token without such a binding produces E_PROFILE_MAPPING_INVALID. Initial entries are shown below; the reference for every initial entry is this document. The default effect describes the condition that generates the diagnostic, not a verdict computed from token presence alone. The verdict procedure in 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. Initial WEXP Appraisal Reason Codes

Token	Category	Default effect	Current-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
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-gap	downgrade if needed by claim	none
E_BOUNDARY_NOT_EVALUATED	evaluation-gap	downgrade if needed by claim	none
E_PROV_NOT_EVALUATED	evaluation-gap	downgrade if needed by claim	none
E_IV_NOT_EVALUATED	evaluation-gap	downgrade if needed by claim	none
E_COMPOSITION_NOT_EVALUATED	evaluation-gap	downgrade if needed by claim	composition
E_COUNTER_EVIDENCE_NOT_EVALUATED	evaluation-gap	downgrade when a counter entry is not evaluated and affects the asserted claim	none

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

Normative References Key words for use in RFCs to Indicate Requirement Levels Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words Guidelines for Writing an IANA Considerations Section in RFCs Informative References Toward a Witnessability Model for AI and Software Execution Systems: A Boundary-Based Framework for Classifying Execution Evidence The Witnessed Execution Protocol (WEXP): Core Specification The Witnessed Execution Protocol (WEXP): Core Specification WEXP Coverage: Claims, Evidence, and Evaluation Work in Progress Witnessability Conceptual Core 1.0 — Ratified Release Package An Architecture for Trustworthy and Transparent Digital Supply Chains Remote ATtestation procedureS (RATS) Architecture

Changes Since draft-sergeev-wexp-core-01 RFC Editor: please remove this appendix before publication as an RFC. This appendix compares this revision with the posted Core-01 baseline .

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

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

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. Selected Conceptual Correspondences

Conceptual source	WEXP realization	Limit of correspondence
WCC 1.0, W-I1; Sections 2.1 and 2.7	Exact target, typed claim, evaluation context	Four positive content bases and two qualifiers; not all proposition classes
WCC 1.0, W-I2	Carrier/profile evaluation, Core appraisal, external reliance	Core does not authenticate raw artifacts or make policy decisions
WCC 1.0, W-I7 and Section 6.5	Composition warrants, limitation inheritance, Boundary Ceiling	Scoped operational constraints; no identity with a Support Envelope
WCC 1.0, W-I7, Preserved Incomparability	Partial structural order and maximal supported alternatives	No universal scalar measure or unique maximum is required
WCC 1.0, W-I8	Separate support, counter-evidence, gaps, and context	Core does not implement the full lifecycle or probabilistic model
Model 1.1, Qualified States and Axiom BC	Four bases, PROV/IV, exclusion-only ceiling	Structural depth is not exact-support entailment; no axiom proof is claimed

The W-I7 quotation in is attributed to Mikhail A. Sergeev, Witnessability Conceptual Core 1.0, released under the CC BY 4.0 license. The reviewed Markdown artifact is WITNESSABILITY-CORE-1.0.md, with SHA-256: 382e39864e257d93a0afd16c377c54f59a2182ecc5c38178764ded29ffb3f034 The publication's release index identifies the same artifact. This revision replaces the abbreviated source identity in Core-01 and locates the quotation precisely; it makes no additional historical-priority claim. The execution-evidence model is the joint work of Mikhail A. Sergeev and Vladimir Ikher .

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 to the posted Core-01 baseline .

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.

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.