#Episteme Evidence-Use and Status-Use Relations

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.

#Keywords

• evidence-use
• status-use
• source-use
• episteme
• claim
• provenance.

#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 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 exact episteme and the claim or governed status for which it is being used. Then point outward, when current, to the dated producing/evaluating work and actual bindings, domain-local result and direct governor, C.2.1 result episteme, A.10/G.6 provenance, G.11 currentness, receiving work and direct use relation, local RelianceDisposition, and B.3 assurance boundary.

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. A cheap first-use classification that keeps evidence-use and status-use available without turning the episteme into a role holder or letting the classification absorb performed work, a domain result, provenance, currentness, assurance, or receiving reliance.

Not this pattern when. Use A.15.1/A.6.1 for performed work and actual bindings; the exact formal, measurement, causal, diagnostic, conformance, comparison, selection, acceptance, gate, permission, commitment, role, or decision pattern for its local result; C.2.1 for the result episteme; A.10/G.6 for provenance and bounded reliance; G.11 for currentness; B.3 for assurance; F.10 or another direct status pattern for status; and E.17 for publication. A.2.4 classifies only the episteme's first evidence-use or status-use.

#Problem

Source text may name U.EvidenceRole or evidence-like role labels for a real need: 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 FPF repair is to model that use as an evidence-use relation, not 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:

#First-use split

An A.2.4 assertion answers only: which episteme is classified for which evidence-use or status-use, in which bounded context, with which scope, polarity or status value, and window. When source production, evaluation, a local result, result episteme, provenance, currentness, receiving work, reliance, or assurance matters, the assertion names the direct object and governor; it does not re-express them as slots of a generic evidence result.

#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

Write only fields that decide this first use:

Episteme evidence-use statement:
  EvidenceEpisteme:
  BoundedContext:
  EvidenceTargetClaim:
  ClaimScopeAndPolarity:
  RelevanceWindow:
  DirectClaimOrResultGovernor:
  ProducingOrEvaluatingWorkRef:        # when current
  DomainLocalResultAndEpistemeRef:     # when current
  ProvenancePathRef:                   # A.10/G.6 when current
  CurrentnessRef:                      # G.11 when current
  ReceivingWorkAndUseRelationRef:      # when actual use is claimed
  RelianceDispositionRef:              # A.10 when reliance is judged
  UnsupportedOverread:

#Minimal Status-Use Statement

Episteme status-use statement:
  StatusBearer:
  StatusTarget:
  StatusScope:
  StatusValue:
  StatusWindow:
  DirectStatusGovernor:
  SourceAndProvenanceRef:
  CurrentnessRef:                      # G.11 when current
  ReceivingWorkAndUseRelationRef:      # when actual use is claimed
  RelianceDispositionRef:              # A.10 when reliance is judged
  UnsupportedOverread:

A.2.4 does not fill a missing direct governor with a generic status, evidence, work-result, or evaluation-result relation.

#Formal, empirical, causal, and status first uses

Source labels such as AxiomaticProofRole, ObservationEvidenceRole, MeasurementEvidenceRole, ModelFitEvidenceRole, CalibrationEvidenceRole, and BenchmarkEvidenceRole are first-use classifications, not U.Role values or result kinds.

Formal line. Classify the exact proof, derivation, counterexample, theory note, or proof-result episteme against the named theorem and theory-version fence. The formal pattern owns entailment, refutation, malformed-proof, timeout, or checker-failure results; C.2.1 owns the episteme that states the result. Proof-checking work is dated U.Work with exact method and bindings. A.2.4 states only how the episteme is used.

Empirical and measurement line. Classify the exact dataset, observation episteme, C.16 measurement-result episteme, replication result, calibration result, benchmark result, or model-fit result episteme against one named claim. The producing or evaluating occurrence remains dated U.Work under A.15.1 with direct relations or A.6.1 bindings; each local result remains with C.16 or its exact domain governor; A.10/G.6 retain provenance; G.11 retains currentness.

Causal line. C.28 owns the causal-use question, estimand, support basis, identification, realizability, verdict, supported use, and unsupported use. A.2.4 may classify the exact C.2.1 episteme used at first contact; evidence wording cannot turn simulation-only output into interventional or realized-counterfactual evidence.

Status line. A visible status carrier is classified separately from the governed status assertion. F.10 or the exact status pattern owns the status value, G.11 owns edition currentness, and a gate, permission, commitment, role, work, assurance, or decision pattern owns its own result. Display presence establishes none of them.

#Work, result, provenance, and receiving-use boundary

Keep these objects separately recoverable whenever they are current:

1. the classified episteme and the exact claim or status for which it is used;
2. the dated source-producing or evaluating work, performer, method, resources, and actual direct/A.6.1 bindings;
3. the domain-local result and its direct governor;
4. the distinct C.2.1 episteme that states that result;
5. the A.10/G.6 source and provenance path;
6. the G.11 currentness result when currentness affects use;
7. the receiving dated work and exact premise, reference, decision-use, operation-argument, or other direct use relation; and
8. the local A.10 RelianceDisposition, with B.3 entered only for an assurance claim or material reliance.

A.2.4 owns only the evidence-use or status-use classification around the episteme. A publication face, carrier, graph edge, MethodDescription, plan, compatible signature, result field, or stored reference does not establish work, participation, a domain result, actual use, currentness, or assurance.

When episteme inception through work matters, A.15.PROD supplies the local entity-identity inception claim. A.2.4 introduces no generic work-to-episteme or evidence-use result.

#Shortcut cost and reopen condition

A.2.4 is the inexpensive first-use classifier. It may identify the episteme, target claim/status, bounded context, scope, polarity/value, window, intended use, direct governor, and unsupported overread. It does not decide the source work, local result, provenance, currentness, assurance, causal support, gate passage, permission, commitment, publication interpretation, or receiving action.

Open only the direct pattern whose fact decides the use: A.15.1/A.6.1 for performed work and bindings, the domain result owner plus C.2.1 for result content, A.10/G.6 for provenance and bounded reliance, G.11 for currentness, B.3 for assurance, C.28 for causal use, F.10 for a status family, or E.17 for publication. Reopen the A.2.4 classification when the episteme, target claim/status, scope, polarity/value, window, or intended use changes.

#Archetypal Grounding

#Proof result used as evidence

ProofResult-12 is a C.2.1 episteme stating an entailment under GraphTheory_v3.1. Dated checker work, its method, theory and proof bindings, and the formal entailment result are recovered under their direct owners. A.2.4 classifies the episteme as supporting Theorem-12 inside the theory-version fence. A.10 records source/provenance; later review work uses the episteme through an exact premise relation. Timeout or checker failure would remain distinct from refutation.

#Measurement result used in acceptance

PressureResult-E is the C.16 measurement-result episteme for gas pressure at port P. It states the measurand, Characteristic, Scale, value, uncertainty, model, calibration basis, time stance, and dated measurement work. A.2.4 classifies it as evidence used for the exact pressure-limit claim. Separate evaluation work applies the G.4 clause through A.6.1 bindings and obtains unknown; a different C.2.1 episteme states that verdict. A.10/G.6 preserve provenance, G.11 currentness, and later C.11 decision work relies on the verdict episteme. Raw detector output, indication, pressure state, measurement result, verdict, and decision remain distinct.

#Dashboard status cell

A release dashboard displays Ready. A.2.4 may classify the cell as a status-use carrier for one named status assertion. The source register, scope, window, status value, G.11 currentness, and provenance must be recoverable. A.21 still owns any gate decision, C.11 any release decision, A.2.8.PER any permission, A.15.1 any performed work, and B.3 any assurance claim. A copied or stale cell establishes none of them.

#Simulation-only output

A simulation-output episteme is classified for one bounded C.28 claim. C.28 retains simulationOnlyCounterfactualOutputBasis, model assumptions, validation basis, causal-use verdict, supported use, and unsupported use. A.2.4 cannot relabel the episteme as realized-counterfactual or interventional evidence; producing simulation work, local simulator result, result episteme, provenance, and later reliance remain separate.

#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

#Common Anti-Patterns and How to Avoid Them

#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

Evidence-use and status-use remain admitted first-use relation positions because one episteme can be classified for different claims or governed statuses without becoming a work-facing role holder. The classification points outward to, and never replaces, performed work, the domain-local result, the C.2.1 result episteme, provenance, currentness, receiving reliance, or assurance.

#SoTA-Echoing

Source qualification was checked against the publishers' current surfaces on 2026-07-30. It remains qualified through 2027-07-30 unless a Recommendation, specification/tag, assurance standard, online causal edition, or adopted foundational-ontology account changes earlier. Only sources that change A.2.4's first-use classifier are decision-governing; other lineage examples remain non-governing.

Source refresh is local: replay the row's named SlotKind or rule, one case, and checklist locus before widening. A changed source cannot by itself alter the domain-local result, work, provenance, currentness, assurance, causal verdict, or role assignment owned by a neighbouring pattern.

#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 and G.6 for descriptive source/provenance paths; G.11 for currentness; B.3 for assurance; C.28 for causal-use results; F.10 for status families; C.2.1 for result epistemes; exact domain patterns for local results; and E.17/E.10.D2 for publication, view, explanation, and description-use cases.
• Separates from: A.15.1/A.6.1 for performed work and actual bindings; A.15.PROD for episteme inception when current; gate, permission, commitment, role, measurement, formal, diagnostic, conformance, comparison, selection, acceptance, causal, and decision patterns for their local results; and receiving-work patterns for actual later use.
• Precision-restoration owners: When source wording says "evidence role", "status role", "standard role", or another role-shaped phrase around an episteme, use A.6.RSIR for relation-slot or role-like slot recovery and E.10.ARCH for ontology-first repair architecture.

#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 object is current: dated work and actual bindings, a domain-local result, its C.2.1 episteme, source/provenance, G.11 currentness, receiving work and direct use, A.10 reliance, B.3 assurance, gate passage, permission, commitment, publication, requirement, definition, or explanation.

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-08-04 — upstream FPF commit 7ba40a95 (github.com/ailev/FPF)