#U.EvidenceRole: The Evidential Stance

Pattern A.2.4 · Stable Part A - Kernel Architecture Cluster

This pattern defines how a knowledge artefact (“episteme”) serves as evidence for a specific claim or theory inside a bounded context. It is a non-behavioural role enacted via U.RoleAssignment; the evidence-role assignment must declare the target claim, the claim-scope, and a timespan of relevance. Evidence is a classificatory status of an episteme; it is not an action and it is not an assignment of an actor.

FPF separates what exists (holons and their kinds) from what acts (systems under roles performing work) and from what is known (epistemes carried on symbols). Roles are contextual masks that holons may wear; role meanings are local to a U.BoundedContext. In this setting, we need a kernel‑level way to say that this episteme counts as evidence about that claim, here, and for this period, without confusing evidence with services, methods, or work.

#Aliases

• U.EvidenceRole

#Keywords

• evidence
• claim
• support
• justification
• episteme.

#Relations

#Content

#Context and intent

FPF separates what exists (holons and their kinds) from what acts (systems under roles performing work) and from what is known (epistemes carried on symbols). Roles are contextual masks that holons may wear; role meanings are local to a U.BoundedContext. In this setting, we need a kernel‑level way to say that this episteme counts as evidence about that claim, here, and for this period, without confusing evidence with services, methods, or work.

Intent. Provide one uniform, discipline‑neutral role by which an episteme can be assigned as evidence, while keeping:

• Agency on systems performing U.Work (not on epistemes).
• Promise and Standardual language on U.PromiseContent (not on evidence).
• Recipe and eligibility on U.Method / U.MethodDescription (not on evidence).

#Problem

1. Anthropomorphising epistemes. Models say “the paper proves…”, implicitly treating a document as an actor.
2. Citation without scope. Links exist but lack explicit target claim, applicability scope, and time window.
3. Deductive versus empirical conflation. A formal derivation and a lab dataset are both called “support” although their semantics and ageing differ.
4. Staleness and drift. Empirical evidence ages; without explicit validity windows, stale evidence keeps influencing conclusions.
5. Cross‑context leakage. Evidence is interpreted as “global,” skipping the bridge that is required to move meaning across contexts.

#Forces

#Solution — Term and definition

Term. U.EvidenceRole — a non-behavioural role that a U.Episteme may play inside a U.BoundedContext to serve as evidence for a declared target claim (or theory/version). The target claim, its applicability scope, polarity, weighting model, and other normative facets are properties of the U.EvidenceRole definition itself within that bounded context.

How it is enacted. The role is enacted by a standard U.RoleAssignment that connects:

RoleAssigning {
  holder  : U.Episteme,        // the artefact: paper, proof, dataset, report…
  role    : U.EvidenceRole,    // a context-defined role with normative properties
  context : U.BoundedContext   // where the role definition is valid
  timespan?: Interval          // optional: relevance window for this specific assignment
}

The normative properties of the role (e.g., claimRef, claimScope, polarity, weightModelRef) are set in the role’s definition in the given U.BoundedContext, not in the evidence-role assignment. U.RoleAssignment carries only the linkage between a concrete episteme and a role already defined and attributed in that context.

Non-behavioural guard. The holder is an episteme; any actions that produced it are U.Work performed by systems. Evidence classifies an artefact’s evidential status; it does not itself enact behaviour.

Minimal readable grammar (informative). <Episteme>#<EvidenceRole>:<Context> — where <EvidenceRole> in <Context> already normatively specifies polarity Claim / Scope [weight].

Examples.

• In Cardio_2026, ModelFitEvidenceRole is defined with: claim = β-blocker > placebo, claimScope = adults 40–65, polarity = supports, weightModelRef = KD:SupportMeasure. Binding: Trial-R3.csv#ModelFitEvidenceRole:Cardio_2026.

• In Theory_T, AxiomaticProofRole is defined with: claim = Theorem-12, claimScope = all x ∈ D, polarity = supports. Binding: Lemma-12.proof#AxiomaticProofRole:Theory_T.

#Role family and specialisations

U.EvidenceRole is a role kind refined by specialisation (no mereology of roles). The recommended, substrate‑neutral specialisations are:

5.1 Axiomatic line (deductive inside a fixed theory)

• AxiomaticProofRole — a proof that entails a target statement in a declared U.TheoryVersion.
• CounterexampleRole — a witness that refutes a universally quantified claim in the theory.
• DerivationRole — a lemma or intermediary derivation establishing a dependency in the proof spine.
• EquiconsistencyEvidenceRole — a metaproof establishing equiconsistency or relative strength, often used to constrain theory choice.

Semantics. In a fixed theory version, these roles are boolean and non‑decaying. If the axiom base or definitions change, the binding must be re‑issued for the new version; there is no silent carry‑over.

5.2 Experimental line (empirical, inductive, and model‑selection)

• ObservationEvidenceRole — raw or processed observations under a declared method.
• MeasurementEvidenceRole — calibrated measurements with an error model and traceability.
• ModelFitEvidenceRole — comparative fit or likelihood of data to competing models; supports one over another within the declared scope.
• ReplicationEvidenceRole — independent replication status (full, partial, failed).
• CalibrationEvidenceRole — evidence about the measurement chain (instrument validity), typically constraining claims.
• BenchmarkEvidenceRole — standardised tasks or suites producing comparable scores.

Semantics. Experimental roles require a claim‑scope and a relevance timespan. Their contribution to confidence is graded and may decay; the same artefact may carry multiple bindings for different claims or scopes (distinct role assignments).

Specialisation, not stacking. Do not build chains like “transformer‑agent‑observer role.” A system enacts behavioural roles (e.g., TransformerRole) to perform work; an episteme enacts U.EvidenceRole to classify its evidential function. Keep enactment lines separate.

#Clear distinctions (Strict Distinction, litmus tests)

#Core invariants (concept level)

1. Holder type. U.EvidenceRole is held by a U.Episteme only; never by a system, work, method, or service. # [M‑0]
2. Context anchor. Every evidence-role assignment must name a U.BoundedContext; meaning is local and does not propagate implicitly.
3. Target claim. Every evidence-role assignment must reference a resolvable claim or theory statement and declare polarity {supports | refutes | constrains | neutral}.
4. Claim-scope. Every evidence-role assignment must declare an applicability scope; for the axiomatic line this can be the theory’s domain.
5. Timespan. Every evidence-role assignment must declare a relevance interval. Axiomatic roles may be open-ended for a fixed theory version; experimental roles require finite or refreshable windows. Gating: narrative only at M-0; explicit timespan & decayClass at M-2; version fence & proofChecks at F-. # [M/F]
6. Non-self-evidence. The provenance of experimental evidence-role assignments must trace to external U.Work performed by systems under roles; an episteme cannot “evidence itself.”
7. No mixing of stances. Do not mix design‑time proof artefacts and run‑time traces in one provenance chain; relate them via separate bindings if needed.
8. No role mereology. Roles have no parts; refine by specialisation only. This prevents confusing “sub‑role” with “subsystem”. Profile note: The constraint is universal (applies to all profiles). # [all]

Minimal readable grammar (informative).
<Episteme>#<EvidenceRole>:<Context> — where <EvidenceRole> is defined inside <Context> with normative facets (claimRef, claimScope, polarity, optional weightModelRef, decay policy).

Examples (illustrative only):

Cardio (empirical line)
Role definition in Cardio_2026:
ModelFitEvidenceRole with
claimRef = (β-blocker > placebo), claimScope = adults 40–65, polarity = supports, weightModelRef = KD:SupportMeasure.
Binding:
Trial-R3.csv#ModelFitEvidenceRole:Cardio_2026

Graph theory (formal line)
Role definition in GraphTheory:
AxiomaticProofRole with claimRef = Theorem-12, claimScope = all finite DAG, polarity = supports (entails), fenced to TheoryVersion = 3.1.
Binding:
Lemma-12.proof#AxiomaticProofRole:GraphTheory

#Facets and semantics (normative)

This section deepens the definition of U.EvidenceRole by specifying which normative facets are attached to its definition within a U.BoundedContext, how decay is handled, what provenance anchors are required, and how the role contributes to assurance computation.

#Claim-scope schema

Every U.EvidenceRole definition within a U.BoundedContext MUST declare a claim-scope record. This record ties the role’s meaning to the exact target claim and its claim scope, and aligns with the typed-claim form used in B.3:

#Timespan and decay

Evidence is perishable unless proven otherwise.

• Formal (axiomatic) roles MAY have open-ended timespan.to = null only if fenced to a specific U.TheoryVersion and justified in notes.
• Empirical roles MUST have a finite or refreshable timespan. Decay parameters (half-life, renewal window) are set by the context policy and referenced in the role definition.

When the relevance window closes (validUntil reached), the evidence incurs Epistemic Debt (ED). Per B.3.4, debt must trigger one of three managed actions:

1. Refresh — new work produces fresh evidence for the same claim and scope.
2. Deprecate — role is retired; claim support is reduced or removed.
3. Waive — explicit steward decision to accept the stale evidence temporarily.

#Provenance hooks

Each U.EvidenceRole MUST anchor into the Evidence–Provenance DAG (A.10):

• Formal: verifiedBy → proof artefact carrier(s), with optional checkedBy metadata for proof-checker runs.
• Empirical: validatedBy → data carriers from observed U.Work runs; protocolRef → U.MethodDescription; fromWorkSet → IDs of those runs.
• SCR/RSCR anchors (A.10) are mandatory for all carriers.

No self-evidence rule: the producing U.Work must have been performed by a system in an external role; an episteme cannot “prove itself” without independent generation.

#Contribution to assurance

A U.EvidenceRole classifies an artefact; its contribution to the target claim’s assurance tuple ⟨F, G, R⟩ is computed in B.3 using:

• F (formality) — lower-bounded by the least formal constituent in the provenance path.
• G (ClaimScope) — limited to the claim scope; unsupported regions are dropped (WLNK).
• R (reliability) — computed as:

R_eff := max(0, min_path( min_claimR(path) − Φ(CL_min(path)) ))

Here:

• min_claimR(path) is the smallest justified reliability along the path from the role to the claim in the context’s support graph.
• CL_min(path) is the lowest congruence level on that path.
• Φ is the penalty function defined by the context policy; it must be monotonic (lower CL → greater penalty).

If any element in the support chain is postulative, the aggregate epistemicMode is postulative.

TA/VA/LA distinctions:

• TA (Typing assurance) — primary effect is to improve CL on edges, reducing penalties in R computation.
• VA (Verification assurance) — primarily raises F and the logical component of R.
• LA (Validation assurance) — raises empirical R and constrains G to the validated envelope.

#Worked examples

#Formal line — Proof as evidence for a theorem

Role definition (in GraphTheory)
AxiomaticProofRole

• claimRef = Theorem-12 (“Every finite acyclic graph admits a topological ordering”),
• claimScope = all finite DAG,
• polarity = supports (entails),
• epistemicMode = formal, assuranceUse = VA,
• fenced to TheoryVersion = 3.1 (open-ended relevance as long as that version stands).

Role assignment(s)
Lemma-12.proof#AxiomaticProofRole:GraphTheory

Provenance sketch
verifiedBy → Carrier#Proof_p1 (machine-checked), usedCarrier → Carrier#Def_graph.

Effect on assurance (informative)
High F (machine-checked proof), G = “finite DAG”, R from proof-obligation integrity; potential CL penalty if an ontology bridge is used.

#Empirical line — Sensor calibration as evidence for an accuracy claim

Role definition (in Cardio_2026)
ModelFitEvidenceRole

• claimRef = “Sensor S achieves ±0.3 °C accuracy in [0,70] °C under lab conditions L”,
• claimScope = temperature [0,70] °C; humidity 30–50%; environment L,
• polarity = supports,
• epistemicMode = postulative, assuranceUse = LA,
• weightModelRef = KD:SupportMeasure, decayPolicy = annual recalibration.

Role assignment(s)
Trial-R3.csv#ModelFitEvidenceRole:Cardio_2026

Provenance sketch
validatedBy → Carrier#Dataset_calib_v5, protocolRef → MethodDescription#ThermoCalibration, fromWorkSet → {cal_run_0502, cal_run_0503}.

Effect on assurance (informative)
F from formalised procedure, G = measured envelope, R from replication and CL on unit mapping; R decays after the policy window unless refreshed.

#Conformance checklist (normative)

CC-ER-01 (Type & holder) U.EvidenceRole MUST be held by a U.Episteme via U.RoleAssignment. Systems, services, methods, or works MUST NOT hold this role.

CC-ER-02 (Context) Every evidence-role assignment MUST name a U.BoundedContext. Role meanings are local and do not propagate without an explicit bridge.

CC-ER-03 (Target claim) Every evidence-role assignment MUST reference a resolvable claimRef@version and declare polarity ∈ {supports | refutes | constrains | neutral}.

CC-ER-04 (Claim-scope) Every evidence-role assignment MUST declare claimScope. For formal proofs this may be the theory’s domain; for empirical evidence it is mandatory to state population, environment, and parameter envelope.

CC-ER-05 (Timespan) Every evidence-role assignment MUST carry a non-empty timespan. Formal line may have open-end only if fenced to a fixed theory version; empirical line must have a finite or refreshable end.

CC-ER-06 (Provenance) Every evidence-role assignment MUST anchor into the EPV-DAG (A.10). For empirical line, fromWorkSet must point to external U.Work; self-evidence is prohibited.

CC-ER-07 (Reproducibility) Empirical evidence-role assignments MUST state reproducibility ∈ {replicated-independent, replicated-internal, not-replicated, irreproducible}, with references where applicable.

CC-ER-08 (Weight discipline) If weight.score is present, weight.modelRef MUST be named and all required inputs supplied.

CC-ER-09 (Cross-context) Cross-context reuse MUST go via U.Alignment bridge; record CL_min on the path for assurance penalties.

CC-ER-10 (Version fences) If the claim or episteme versions, create a new binding; do not mutate in place.

CC-ER-11 (No role-of-role) Roles never hold roles; there is no chaining of behavioural sub-roles into non-behavioural ones.

CC-ER-12 (Terminology) Use specialisation for role refinements; reserve sub for mereology of systems or artefacts only.

CC-ER-13 (Lane declaration) Every binding SHALL declare assuranceUse ∈ {TA | VA | LA} and, for empirical (LA) bindings, expose timespan/valid_until and decayPolicy so that SCR can report lane‑separated contributions and freshness (B.3).

#Anti-patterns and remedies

#Operators (conceptual, tooling-agnostic)

These operators extend E.6.1 citation graph capabilities for evidence analysis inside a U.BoundedContext:

12.1 Per-claim evidence evidenceFor(claim, t?) → Set[EvidenceRoleAssigning] counterEvidenceFor(claim, t?) → Set[EvidenceRoleAssigning] weight(claim, t?, model?) → score # returns ordinal at M‑mode; numeric at M‑2/F‑mode. # [M/F]

12.2 Decay and windows window(claim, [t0,t1]) — filter evidence-role assignments by timespan. decayedWeight(assignment, t) — apply context decay policy.

12.3 Replication and provenance replicationLedger(binding) → Ledger isIndependentReplication(binding) → boolean

12.4 Formal line hooks proofChecks(binding) → {assistant, status, hash, kind∈{classical, constructive}} # [F‑*] dependsOnAxioms(binding) → Set[AxiomId]

12.5 Empirical line hooks fromWorkSet(binding) → Set[WorkId] protocol(binding) → MethodDescriptionId

#Relations

Builds on: A.2 U.Role, A.2.1 U.RoleAssignment (role as mask, binding as assignment), A.10 Evidence Graph Referring (EPV-DAG), B.3 Trust & Assurance Calculus.

Coordinates with: A.3.2 U.MethodDescription (protocols, proof obligations), E.6.1 Epistemic Roles via U.RoleAssignment (didactic gateway).

Informs: KD-CAL (knowledge dynamics, assurance cases), Norm-CAL (policy claims with evidence), planned U.PromiseFulfillmentEvaluation (services judged from work and reported as epistemes with evidence bindings).

#Migration notes (quick wins)

1. Enumerate claims: For each evidence collection, identify claims and create explicit bindings with polarity.
2. Separate work from reports: Facts stay on U.Work; create report epistemes to link as evidence.
3. Name the calculus: Replace free-form confidence with context-declared weight model and required inputs.
4. Fence by version/time: Bindings carry timespan and version fences; add decay class if applicable.
5. Bridge explicitly: Cross-context evidence goes through U.Alignment, not by fiat.

#Didactic quick cards (engineer-manager ready)

These are short reminders for non-specialist readers to apply U.EvidenceRole correctly:

• Evidence ≠ Work — Work is what happened; Evidence is a documented argument (episteme) about a claim in a context.
• Local, not global — Evidence links in a room (context). Outside that room, you need a bridge (U.Alignment).
• Two lines of trust — Formal line: proof artefacts checked in a declared theory version. Empirical line: observations from Work under a declared method. Both are epistemes wearing U.EvidenceRole.
• Services are promises; Work proves — KPIs are measured from Work; service evaluations can be bound as evidence for policy claims.
• Specialise, don’t stack — Use specialisations of U.EvidenceRole to refine meaning; never chain behavioural roles into evidence.

#SCR/RSCR audit stubs (assurance scaffolding)

These stubs allow concept-level validation of evidence-role assignments, without implying any specific tooling.

SCR-A2.4-E1 (Assignment integrity) Assert: holder is U.Episteme; context present; claimRef resolves; timespan non-empty; provenance anchored to EPV.

SCR-A2.4-E2 (Weight discipline) Assert: if weight.score present → weight.modelRef present and all required inputs provided; recompute to check.

SCR-A2.4-E3 (Traceability) For empirical evidence-role assignments: assignment → fromWorkSet → each U.Work has performer U.RoleAssignment and timestamps; no missing hops.

RSCR-A2.4-R1 (Regression on version bump) When claimRef or holder episteme versions change, ensure new bindings are created; no in-place mutation.

RSCR-A2.4-R2 (Decay check) Bindings past timespan.to or with expired decayClass are flagged for review per context policy.

#Minimal evidence-role assignment schema (informative)

EvidenceRoleAssigning:
  id: ERB-…
  context: <BoundedContextId>
  holder: <EpistemeId>                # paper/proof/dataset/report
  role: <EvidenceRoleId>              # defined within the context, with normative properties
  timespan?: {from: ISO-8601, to: ISO-8601|null} # optional assignment window
  provenance:
    formal?: { theoryRef: <TheoryId>, proofArtifactRef: <CarrierId>, checkedBy?: <ProofCheckId> }
    empirical?: { protocolRef: <MethodDescriptionId>, fromWorkSet: [<WorkId>… ], dataCarrierRef?: <CarrierId> }

#Memory hooks and acceptance cross-checks (informative)

Memory hook: “Evidence links a document to a claim in a Context, for a time, with a trail.” (document = episteme; claim = scoped thesis; Context = bounded context; time = timespan/decay; trail = provenance)

Acceptance cross-checks before publishing a binding:

1. Holder: Is it a U.Episteme?
2. Context: Is the U.BoundedContext declared?
3. Claim: Does claimRef resolve? Is polarity set?
4. Scope: Is claimScope complete? For empirical, are population/env/parameters given?
5. Timespan: Is it finite or fenced (formal line)?
6. Provenance: Is EPV anchored? Any self-evidence?
7. Reproducibility: For empirical, is it declared?
8. Weight: If scored, is the model named and inputs complete?
9. Cross-context: If imported, is U.Alignment bridge in place with CL_min recorded?
10. No role-of-role: Is this role bound directly to an episteme without chaining behavioural roles?

#A.2.4:End