#U.EvidenceRole: The Evidential Stance

A.2.4 · Stable · Boundary and relation-use pattern · Normative · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Boundary and relation-use pattern Status: Stable Normativity: Normative

Use this pattern when a report, proof, dataset, measurement file, standard, requirement, dashboard cell, model card, publication face, generated explanation, or other U.Episteme is being used as evidence, source, status bearer, assurance input, or causal-use input for a claim.

#Aliases

• U.EvidenceRole

#Keywords

• evidence
• claim
• support
• justification
• episteme.

#Relations

#Content

#Problem Frame

Use this pattern when a report, proof, dataset, measurement file, standard, requirement, dashboard cell, model card, publication face, generated explanation, or other U.Episteme is being used as evidence, source, status bearer, assurance input, or causal-use input for a claim.

Use it when the working question is:

• which episteme is being used;
• which claim, theory statement, status assertion, use, or causal-use question the episteme is being used for;
• which bounded context, claim scope, grounding holon, polarity, relevance window, assurance use, weight model, and provenance constraints are current;
• whether old source wording such as "evidence role", "status role", "standard role", or "the report plays a role" hides an evidence-use, status-use, source-use, publication-use, assurance-use, gate-use, or causal-use relation;
• whether the evidence-use or status-use relation is sufficiently specified for the intended reliance, or only enough for orientation, source-finding, a reversible probe, or a narrowed use.

Primary EntityOfConcern. The EntityOfConcern is the evidence-use relation or status-use relation around an episteme. It is not U.Role, not U.RoleAssignment, and not a system performing work.

First useful move. Name the episteme, the bounded context, the claim or status being addressed, and the direct governing pattern that owns the use: usually A.10, B.3, C.2.1, C.28, F.10, G.6, E.17, E.10.D2, or a direct gate, source, requirement, definition, explanation, or publication-use pattern.

What goes wrong if missed. A document starts acting like an agent, a dataset is treated as if it held a work-facing role, a dashboard status becomes permission, a proof becomes global evidence without a theory fence, or a simulation-only counterfactual output is relabelled as realized causal evidence.

What this buys. The project can use epistemes as evidence, status bearers, sources, standards, requirements, definitions, explanations, publications, or assurance inputs without creating a second role ontology for epistemes and without losing claim scope, polarity, freshness, provenance, or assurance-use distinctions.

Not this pattern when. If the current claim is a system or acting holon holding a work-facing role, use A.2 and A.2.1. If the current claim is performed work, use A.15.1. If the current claim is the full evidence-provenance graph relation, use A.10. If the current claim is assurance, use B.3. If the current claim is causal use, use C.28. If the current claim is a status family or status mapping, use F.10. If the current claim is publication-use or source-use, use E.17 and E.10.D2 as needed.

#Problem

Older FPF text used U.EvidenceRole for a useful need but chose the wrong ontology. The need was real: an episteme can be used as evidence for a claim inside a bounded context, with scope, polarity, time, assurance use, weight, and provenance constraints. The error was to model that use as a non-behavioral role held by the episteme through U.RoleAssignment.

That creates several failures:

1. Episteme-as-holder drift. A paper, proof, dataset, standard, or dashboard cell is treated as if it held a work-facing role.
2. Evidence role ontology drift. ModelFitEvidenceRole, MeasurementEvidenceRole, or AxiomaticProofRole look like role kinds instead of evidence-use relation classifications or local evidence-use labels.
3. Claim relation collapse. Target claim, grounding holon, claim scope, polarity, relevance window, assurance use, weight model, and provenance constraints are hidden behind one role name.
4. Evidence and status collapse. A status badge, standard reference, approval-looking display, publication face, or requirement source is treated as evidence, status assertion, gate passage, permission, and assurance at once.
5. Work confusion. The work that produced an episteme and the later use of that episteme as evidence are folded into one relation.
6. Causal-use laundering. Observational association, intervention, realized counterfactual sample, identified counterfactual estimate, and simulation-only output are relabelled by evidence-wording instead of being governed by C.28.
7. Cross-context leakage. Evidence accepted in one context is reused in another without an explicit bridge, source-currentness relation, or assurance-use statement.

#Forces

#Solution

Do not create or use U.EvidenceRole as a durable role kind. Do not place an episteme in U.RoleAssignment merely because it is used as evidence, source, standard, requirement, definition, explanation, publication, status bearer, or assurance input.

Use direct relation patterns instead:

#Evidence-Use Relation Slots

An evidence-use relation is a relation around an episteme and a claim or effect. It is not a role assignment.

These SlotKinds are evidence-use relation positions. They are not work-role qualifier slots, not U.Role names, and not new U-kinds by themselves.

#Status-Use Relation Slots

A status-use relation is a relation around a bearer, status value, scope, window, source, and use. It is not a status role held by an episteme.

These names do not create a generic status ontic. They are repair vocabulary for status-use relations in the current role and relation-slot settlement. Durable status families remain governed by F.10 or a direct status pattern.

#Minimal Evidence-Use Statement

For ordinary use, write only the fields needed for the current reliance question:

Episteme evidence-use statement:
  EvidenceEpisteme:
  BoundedContext:
  EvidenceTargetClaim:
  EvidenceClaimGroundingHolon:
  EvidenceClaimScope:
  EvidencePolarity:
  EvidenceRelevanceWindow:
  EvidenceAssuranceUse:
  EvidenceWeightModel:
  EvidenceProvenanceConstraint:
  DirectGoverningPattern:
  UnsupportedOverread:

UnsupportedOverread names the stronger claim not carried by this relation, such as approval, permission, gate passage, performed work, assurance, causal identification, release confidence, or global truth.

#Minimal Status-Use Statement

For status-like cases, write the smallest relation that keeps status from becoming role assignment, gate passage, or assurance by display alone:

Episteme status-use statement:
  StatusBearer:
  StatusTarget:
  StatusScope:
  StatusValue:
  StatusWindow:
  StatusUse:
  StatusProvenanceConstraint:
  DirectGoverningPattern:
  UnsupportedOverread:

If the status is used for a gate, release, work-plan readiness, assurance, or admission decision, apply the direct governing pattern for that use. A.2.4 only keeps the status-use relation typed and prevents old role-holder grammar from returning.

#Formal, Empirical, and Causal Evidence Uses

Older labels such as AxiomaticProofRole, ObservationEvidenceRole, MeasurementEvidenceRole, ModelFitEvidenceRole, ReplicationEvidenceRole, CalibrationEvidenceRole, and BenchmarkEvidenceRole become evidence-use classifications or local evidence-use labels, not U.Role values.

Formal line:

• the evidence episteme is a proof, derivation, counterexample, theory note, proof-check result, or formal publication;
• EvidenceTargetClaimSlot names the theorem or theory statement;
• EvidenceClaimScopeSlot names the theory domain or declared scope;
• EvidenceRelevanceWindowSlot usually names a theory-version fence rather than an empirical expiry date;
• EvidenceProvenanceConstraintSlot names proof checks, source publications, theory version, and dependency conditions when current.

Empirical line:

• the evidence episteme is a dataset, observation record, measurement report, replication report, calibration result, benchmark result, model-fit report, or similar episteme;
• EvidenceClaimScopeSlot, EvidenceRelevanceWindowSlot, EvidenceWeightModelSlot, and EvidenceProvenanceConstraintSlot usually decide whether the use is admissible;
• the producing work remains U.Work under A.15.1, performed by a system or acting holon under U.RoleAssignment where that trace is current.

Causal-use line:

• the causal-use question belongs to C.28;
• A.2.4 keeps the evidence-use relation typed so the episteme is not relabelled by vocabulary alone;
• exact C.28 values such as observationalAssociationSupportBasis, interventionalActionSupportBasis, realizedCounterfactualSampleSupportBasis, identifiedCounterfactualEstimateSupportBasis, and simulationOnlyCounterfactualOutputBasis remain C.28 values, not role names.

#Work, Source, and Publication Boundary

The producing work and the later evidence use are different relations.

• A lab run, proof-checking session, calibration run, benchmark run, review, model evaluation, or data extraction can be U.Work.
• The report, proof file, dataset, benchmark table, or publication produced by that work can be a U.Episteme.
• A later project can use that episteme as evidence through an evidence-use relation.
• A publication face, view, source citation, credential view, dashboard display, or generated explanation can cue evidence or status use, but it does not become the evidence-use relation by itself.

When the source-currentness, publication-use, view, explanation, or specification-use question is current, use E.17, E.17.0, E.17.2, E.17.EFP, E.10.D2, A.10, or the direct source-use pattern before relying on the evidence-use or status-use relation.

#Shortcut Cost and Reopen Condition

The baseline is the direct governing pattern: full A.10 for evidence-provenance graph relations, full B.3 for assurance, full C.28 for causal use, full F.10 for status families, full E.17 or E.10.D2 for publication-use and description-use cases, and full A.15.1 when the producing work is current.

A.2.4 is the weaker first-use representation. It saves effort by writing only the relation positions needed to stop old role wording from collapsing evidence, status, work, assurance, source, and publication claims. The loss budget is narrow: A.2.4 may name the evidence-use or status-use relation, preserve the named direct governing pattern, and state unsupported overread. It may not decide assurance value, gate passage, causal identification, source-currentness order, publication interpretation, or performed-work truth.

Open the direct governing pattern when the attempted use depends on assurance, safety, release, compliance, causal effect, gate decision, permission, performed work, source freshness, publication use, status currentness, or a contested provenance relation.

#Archetypal Grounding

#Proof Used as Evidence

Lemma-12.proof is an episteme used as evidence for Theorem-12 in GraphTheory_v3.1.

The evidence-use relation names:

• EvidenceEpistemeSlot = Lemma-12.proof;
• EvidenceTargetClaimSlot = Theorem-12;
• EvidenceClaimScopeSlot = finite DAGs inside GraphTheory_v3.1;
• EvidencePolaritySlot = supports or an entailment-specific polarity when the local value set declares one;
• EvidenceRelevanceWindowSlot = theory-version fence GraphTheory_v3.1;
• EvidenceAssuranceUseSlot = verification use;
• EvidenceProvenanceConstraintSlot = proof publication, proof-check result, dependency list, and theory version.

No episteme holds AxiomaticProofRole. The proof episteme is used in a claim-bound evidence-use relation.

#Calibration Dataset Used as Evidence

Trial-R3.csv is an episteme used as evidence for Sensor S accuracy +/-0.3 C in [0,70] C under lab conditions L.

The evidence-use relation names the claim scope, polarity, relevance window, weight model, producing work runs, method description, measurement traceability, and freshness policy. If a later assurance claim is made, B.3 consumes this relation. If the calibration run itself is being discussed, use A.15.1 for the work occurrence.

#Dashboard Status Cell

A release dashboard shows Ready.

That visible cell can be:

• a status cue;
• a status assertion if the source, status value, scope, window, and provenance constraints are recoverable;
• evidence for a gate or release claim only when A.10 and the gate pattern recover the source relation;
• no evidence-use relation if it is stale, copied, unauthenticated, or disconnected from the decision source.

It is not a status role held by the dashboard episteme.

#Standard Used as Requirement or Evidence

An ISO/IEC/IEEE standard clause can be an episteme used as a requirement source, definition source, status source, or evidence source depending on the current claim.

Do not write "the standard has a normative role" as live FPF ontology. Recover the relation governed by the current claim: standard-use, requirement-use, definition-use, source-use, evidence-use, status-use, or assurance-use.

#Simulation-Only Counterfactual Output

A simulation output mentions a counterfactual. That output may be an episteme used in an evidence-use relation. The causal-use class still belongs to C.28.

If the current C.28 value is simulationOnlyCounterfactualOutputBasis, the evidence-use relation cannot be relabelled as realizedCounterfactualSampleSupportBasis or interventionalActionSupportBasis by evidence wording, validation wording, or role wording alone.

#Bias Annotation

This pattern mainly blocks six biases:

• episteme-as-role-holder bias: an episteme is placed in U.RoleAssignment because it is useful as evidence or status;
• evidence-name-as-kind bias: local evidence-use labels become U.Role names;
• status-display-as-authority bias: a visible badge or status cell becomes gate passage, permission, or assurance;
• work-as-evidence-use collapse: producing work, produced episteme, and later evidence use are treated as one relation;
• scope-free evidence bias: target claim, grounding holon, claim scope, polarity, time, assurance use, or provenance constraints are omitted;
• causal laundering bias: causal evidence classes are changed by source vocabulary rather than by C.28 causal-use reasoning.

The repair is to recover the episteme first, then recover the evidence-use, status-use, source-use, publication-use, assurance-use, or causal-use relation that is current.

#Conformance Checklist

#Anti-Patterns and Repairs

#Consequences

The positive consequence is a simpler role ontology. Systems and acting holons hold work-facing roles; epistemes are used through evidence-use, status-use, source-use, publication-use, requirement-use, definition-use, explanation-use, assurance-use, and causal-use relations.

The cost is explicit relation recovery. A phrase such as "evidence role", "status role", "standard role", "proof role", or "benchmark role" no longer closes the claim. The user needs to recover which episteme, claim, scope, status, time window, provenance constraint, and direct pattern are current.

The payoff is that one episteme can be reused honestly across many claims. Each use can have a different target claim, grounding holon, scope, polarity, relevance window, assurance use, weight model, or provenance constraint without multiplying role kinds.

#Rationale and SoTA-Echoing

Refresh this pattern's source use when those provenance, credential, attestation, assurance, causal-use, or foundational-ontology practices change the separation between evidence presence, status display, assurance, provenance, causal class, and role assignment.

#Relations

• Builds on: A.2 for U.Role, A.2.1 for U.RoleAssignment, A.6.5 for SlotSpec discipline, and C.2.1 for episteme slot relation and episteme identity.
• Coordinates with: A.10 for evidence-provenance graph relation; B.3 for assurance; C.28 for causal-use evidence classes; F.10 for status families; G.6 for evidence graph and provenance ledgers; E.17, E.17.0, E.17.2, and E.17.EFP for publication, view, and explanation-use cases; E.10.D2 for EntityOfConcern, description episteme, and specification-use discipline.
• Separates from: A.15.1 for producing work; A.15.2 for planned work; gate patterns for gate passage; A.2.8 and A.2.9 for commitments and speech acts; source-currentness patterns for source freshness and source order.
• Feeds: A.6.RSIR and E.10.ARCH as the current repair target when source wording says "evidence role", "status role", "standard role", or another role-shaped phrase around an episteme.

#Lowering, Repair, and Refresh

Lower an attempted A.2.4 use when the episteme is known but the target claim, scope, polarity, status value, time window, or provenance constraints are not recoverable. The lowered result may be source-finding, orientation, an evidence-needed note, a status-source request, or a narrowed reliance use.

Repair the use when a neighboring relation is actually current: performed work, assurance, causal use, gate passage, permission, commitment, publication-use, source-currentness, requirement-use, definition-use, or explanation-use.

Refresh the use when the episteme edition, target claim, grounding holon, claim scope, theory version, relevance window, source-currentness relation, status source, proof check, measurement trace, method description, or assurance-use relation changes.

#A.2.4:End

Last Updated: 2026-06-17 — this section last modified in upstream FPF commit 205de763 (github.com/ailev/FPF)