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 appraisal semantics for execution-related evidence. 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. A companion Native Record profile can encode the normalized inputs defined here, and other carriers can do so without adopting that record format.

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 . This document is self-contained: conceptual publications are informative and are not required to implement the normative appraisal procedure.

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.

Layered Architecture 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 Related Work RATS appraises evidence about an environment. Transparency systems establish registration and custody. 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.

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.

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 Classes This document defines the Conformance Classes CC0 through CC5. A Conformance Class classifies the capability of an appraising implementation. It is orthogonal to the appraisal result: it scopes what an implementation assesses, and it never bounds, raises, or lowers the state a record is found to support. A Conformance Class MUST NOT be used as an input to the appraisal procedure of , as a ceiling on a supported claim, or as a sort key over claims. Where an implementation lacks the capability required to assess a claim, the applicable fail-closed *_NOT_EVALUATED outcome of applies; the implementation MUST NOT downgrade the appraisal result in place of reporting that it did not evaluate. No capability bound on a verified state is defined by this document. A profile or deployment that requires a minimum Conformance Class states that requirement in its own terms; it does not thereby alter what any record supports.

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

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 bracketed notation of . The bracketed notation 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 the greatest bare label that is less than or equal to the typed state under the declared projection. 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 input: the record is rejected and no claim is appraised. The concrete error token for that condition is bound by the carrier (), not by this document. A conforming reader is cautioned that a schema-valid record is not thereby a correctly projected record: schema validity concerns the integrity of the bytes, 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 input at the execution level; a claim at the execution level therefore binds the execution, not the input. A profile that needs the input bound at that level MUST require it. Binding an input at the execution level would add a field, not a witness: the declaring sentence above and this deferring sentence are about one and the same object, and that is said here plainly rather than left to be inferred. 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-1. 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. 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. An entry with an empty affected-claim set, an absent, ambiguous, unregistered, or non-evaluation-gap token binding, an incorrect target or evaluation-context scope, an invalid current-scope marker, or malformed basis references or limitations is a profile-mapping failure. A valid entry whose affected claims include neither the asserted claim nor a member of SupportedClaims is unrelated to this appraisal and is not projected.

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:

1. If the outer value is not an input record, or semantics_version is absent or is not a text atom, Core returns E_MALFORMED_NORMALIZED_INPUT.
2. If that readable value is not wexp-core-1, Core returns E_UNSUPPORTED_SEMANTICS_VERSION without applying the version-specific member rules below.
3. For wexp-core-1, a missing required member, unknown member, wrong logical type, unknown closed-enum value, or malformed set, entry, claim, token, or recorder relation returns E_MALFORMED_NORMALIZED_INPUT.
4. A well-typed wexp-core-1 input that violates a cross-field invariant returns E_PROFILE_MAPPING_INVALID. Cross-field invariants include aggregate cardinality and keys, exact target and context scope, the counter-evidence sentinel, qualifier combinations, conditional ceiling_base, evaluation-scope consistency and extension-key binding, and profile or registry identity and token category.
5. If the structurally usable input has a non-empty valid fatal_conditions set, Core returns that complete set through the fixed rejection projection.
6. Otherwise an inadmissible asserted claim returns E_CLAIM_OUT_OF_DOMAIN.

E_MALFORMED_NORMALIZED_INPUT, E_UNSUPPORTED_SEMANTICS_VERSION, E_PROFILE_MAPPING_INVALID, and E_CLAIM_OUT_OF_DOMAIN are derived only by the ordered Core checks and are invalid as supplied members of fatal_conditions. The Core-defined supplied fatal members are E_UNKNOWN_CRITICAL_SEMANTIC, E_INTEGRITY_INVALID, E_BINDING_MISMATCH, and E_CHAIN_DESCRIPTION_INVALID. An immutable applied profile can additionally register supplied fatal tokens. If any supplied member is appraiser-derived, unbound, ambiguous, or in the wrong category, the cross-field check returns only E_PROFILE_MAPPING_INVALID. A supplied E_INTEGRITY_INVALID means that an integrity or authentication failure affecting normalized interpretation was identified while enough structurally usable logical input remains to report that Core condition. A supplied E_BINDING_MISMATCH means protected fields or mandatory mapping bindings are internally contradictory while the same minimum remains available. Ordinary negative or unevaluated exact-target binding is represented by a correctly scoped aggregate and is non-fatal. A supplied E_UNKNOWN_CRITICAL_SEMANTIC means an unrecognized critical Core or applied mapping-profile semantic can affect normalized interpretation 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. The result MUST preserve the boundary grounding status and its limitations. 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 or unevaluated target binding prevents use of the ceiling and adds the corresponding profile reason or gap.

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:

1. the unique aggregate base finding for b has supported target binding and supported semantic validation;
2. the finding names the same target and evaluation context as the appraisal input;
3. the boundary finding is supported, target-bound, and scoped to that same target and context; and
4. the accepted Boundary Ceiling is at least b.

For each b in B, let Q(b) contain:

• PROV only when b is execution and a PROV finding for execution has target_binding = supported and semantic_validation = supported for the exact target and evaluation context; and
• IV only when an IV finding for b has target_binding = supported, semantic_validation = supported, and independence_validation = supported for the exact target and evaluation context.

The supported claim set is: 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 "valid but unsupported as claimed". It does not imply that every supported alternative is structurally below the asserted claim. 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. Informatively: a downgrade result means that the level originally claimed is not supported as claimed, while some lower or incomparable claim may still be supported. This sentence explains the term and introduces no second verdict. 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 claim-required diagnostic matrix in 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. 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 row is evaluated independently. An absent aggregate triggers only its absence row; status rows require that aggregate to be present. 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, and E_COMPOSITION_WARRANT_MISSING 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; and
• 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. 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 , part 4: "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 rule and claims no novelty for it; the material below that derives from it is cited, not restated. 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 . Provenance of this section: the W-I7 material here is a byte-exact, attributed quotation from (SHA-256 382e3986…), which was demonstrably in hand when this section was authored. The underlying non-inflation principle appeared in the WEXP line — , submitted 2026-07-05/06 — before the earliest provable carrier of the W-I7 twelve-pair formulation (2026-07-23); no WEXP text reproduces W-I7 wording other than as an attributed quotation. The inherited invariant lands together with its third part, Preserved Incomparability, and not alone: a total order over typed states is not presumed, and a projection into one requires justification by the profile that declares it. A single maximum among supported states is not guaranteed, and monotonicity is not presumed. Two boundaries of this landing are stated so that nothing is quietly raised by it. The Boundary Ceiling of is untouched by this section and its status is not elevated by appearing beside an inherited invariant. The corollary that verifiability does not raise the captured level belongs to a different axis and is not merged with the rule 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 establishes registration or custody; it does not establish 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 prevent a Core-00 result, a Snapshot-001 result, or a result from another Core-01 source from being presented as evidence for different bytes. For that exact scope, PASS means that the implementation asserts 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. Composition-profile conformance, carrier conformance, and result-carrier conformance are separate claims with separate immutable profile identities. 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-1:

• 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), where the immutable applied profile identifier occurs in evaluation_context.profile_identifiers and local_name is a non-empty name 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. An unbound, malformed, duplicate, or ambiguous extension key produces E_PROFILE_MAPPING_INVALID. The scope map is a deterministic summary of the assessments represented by the normalized input. carrier-mapping is evaluated for every complete Core input. For each finding-backed or counter-evidence capability, evaluated means discovery of applicable material completed and every supplied assessment governed by that capability has a status other than not-evaluated; absence of an aggregate under that value means discovery completed and found no candidate evidence. not-evaluated means at least one applicable governed assessment could not be performed. When such an assessment is required by the asserted claim, that value is accompanied by the exact role aggregate with its relevant status set to not-evaluated. 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; and counter-entry status for counter-evidence. A scope value of evaluated with a governed not-evaluated status, a 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. The cumulative CC0-CC5 scale from draft-sergeev-wexp-core-00 is not part of the Core appraisal algorithm in this revision. Producer capability declarations and carrier conformance belong to carrier profiles.

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-1; target T; evaluation-context identifier C; 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 a basis identifier matching its name. Supported IV additionally has supported independence validation; PROV uses not-applicable. A finding not stated in a row is absent. P_COUNTER_FAIL is an opaque fixture token assumed to be registered in the substantive category by the fixture's mapping profile. 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 is the union of bd, its base basis, and any qualifier bases; 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 .

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-1; 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 bases {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. Appraisals preserve whether it was asserted, attributed, attested, or not evaluated. 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. The appraisal carries the evaluation context so that a result is not detached from those dependencies. 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 "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, and reference. Initial entries are shown below; the reference for every initial entry is this document.

Token	Category	Default effect
E_MALFORMED_NORMALIZED_INPUT	fatal	reject
E_UNSUPPORTED_SEMANTICS_VERSION	fatal	reject
E_CLAIM_OUT_OF_DOMAIN	fatal	reject
E_UNKNOWN_CRITICAL_SEMANTIC	fatal	reject
E_INTEGRITY_INVALID	fatal	reject
E_BINDING_MISMATCH	fatal	reject
E_PROFILE_MAPPING_INVALID	fatal	reject
E_CHAIN_DESCRIPTION_INVALID	fatal	reject
E_CHAIN_UNBOUND	substantive	downgrade
E_SHARED_VERIFICATION_ROOT	substantive	downgrade
E_BASE_EXCEEDS_BOUNDARY	substantive	downgrade
E_BOUNDARY_NOT_SUPPORTED	substantive	downgrade
E_EXACT_CLAIM_NOT_SUPPORTED	substantive	downgrade
E_MISSING_REQUIRED_EVIDENCE	substantive	downgrade
E_EVIDENCE_NOT_BOUND	substantive	downgrade
E_EVIDENCE_COVERAGE_MISMATCH	substantive	downgrade
E_PROV_NOT_SUPPORTED	substantive	downgrade
E_IV_NOT_SUPPORTED	substantive	downgrade
E_COUNTER_EVIDENCE_UNRESOLVED	substantive	downgrade
E_COUNTER_EVIDENCE_DEFEATING	substantive	downgrade
E_COMPOSITION_WARRANT_MISSING	substantive	downgrade
E_INDEPENDENCE_NOT_ESTABLISHED	substantive	downgrade
E_BASE_NOT_EVALUATED	evaluation-gap	downgrade if needed by claim
E_BOUNDARY_NOT_EVALUATED	evaluation-gap	downgrade if needed by claim
E_PROV_NOT_EVALUATED	evaluation-gap	downgrade if needed by claim
E_IV_NOT_EVALUATED	evaluation-gap	downgrade if needed by claim
E_COMPOSITION_NOT_EVALUATED	evaluation-gap	downgrade if needed by claim
E_COUNTER_EVIDENCE_NOT_EVALUATED	evaluation-gap	downgrade if material

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 require one unambiguous condition, deterministic category and default effect, and a stable public specification. A registration that would create claim support from an evaluation capability, display label, boundary name, or artifact presence should be rejected.

Normative References Informative References Witnessability Project

Changes Since draft-sergeev-wexp-core-00

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