#Evidence Graph Referring (C-4)

A.10 · Stable · 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-memory 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.

“A claim without a chain is only an opinion.”

FPF is a holonic framework: wholes are built from parts (A.1, A.14), and reasoning travels across scales via Γ‑flavours (B.1). To keep this reasoning honest and reproducible, every published assertion must be anchored in concrete symbol carriers and well‑typed transformations performed by an external TransformerRole (A.12, A.15). Publication itself is the typed projection I→D→S (Publ_ID, Formalize_DS) per A.7 and is not execution; any physical/digital release, rendering, or upload is Work by an external transformer on carriers, cited in SCR.

#Keywords

• evidence
• traceability
• provenance
• evidence carrier
• claim support
• authority-reliance evidence path
• generated-explanation source support
• exact governing source
• probe/distributed/export/causal evidence
• SCR/RSCR.

#Relations

#Content

#Context

FPF is a holonic framework: wholes are built from parts (A.1, A.14), and reasoning travels across scales via Γ‑flavours (B.1). To keep this reasoning honest and reproducible, every published assertion must be anchored in concrete symbol carriers and well‑typed transformations performed by an external TransformerRole (A.12, A.15). Publication itself is the typed projection I→D→S (Publ_ID, Formalize_DS) per A.7 and is not execution; any physical/digital release, rendering, or upload is Work by an external transformer on carriers, cited in SCR.

Practitioner shorthand:

Claim → (Proof or Test) → Confidence badge …where the proof/test is traceable to real carriers and to an external system/Transformer who executed an agreed method.

This pattern defines the Evidence Graph Referring Standard common to all Γ‑flavours (Γ_sys — formerly Γ_core, Γ_epist, Γ_method, Γ_time, Γ_work) and clarifies: (a) the difference between mereology (part‑whole; builds holarchies) and provenance (why a claim is admissible; does not build holarchies); (b) the run‑time / design‑time separation (A.4) across Role–Method–Work (A.15).

Use this when a model, report, metric, confidence badge, review note, or QL reading is starting to act like evidence but the carrier, transformer, method, time stance, or provenance edge is still implicit. The action is to turn the assertion into a small because-graph: name the claim, name the carriers, name the external transformer role, name the method or work trace, state the time/coverage condition, and attach the resulting evidence edge to the claim rather than to the holon itself.

Useful output: a claim that can answer "because of which carriers, by which transformer, using which method, and when?" without making provenance pretend to be part-whole structure.

#Problem

Without a uniform anchor, models drift into five failure modes:

1. Weightless claims. Metrics or arguments appear in the model with no link to their symbol carriers (files, datasets, lab notebooks, figures).
2. Collapsed scopes. Design‑time method specs are silently mixed with run‑time traces; results cannot be reproduced because “what was planned” and “what actually ran” are conflated.
3. Self‑justifying loops. A holon attempts to evidence itself (violates A.12 externality), producing cyclic provenance and unverifiable conclusions.
4. Source loss during aggregation. As Γ combines parts, some sources “fall out”; later audit cannot reconstruct why a compound claim was accepted.
5. Temporal ambiguity. Time‑series are aggregated without interval coverage or dating source; gaps/overlaps invalidate comparisons and trend claims.

The business effect is predictable: confidence badges cannot be defended, cross‑scale consistency (A.9) is broken, and iteration slows because every review re‑litigates “where did this come from?”.

#Forces

#Solution — The Evidence Graph Referring Standard

The Standard is a small set of primitives applied uniformly, with practitioner-first clarity and formal hooks for proof obligations. Its governed object is the evidence/provenance path for a claim: carriers, external transformer roles, method/work traces, time stance, and evidence edges. Authority-looking reliance and causal-use support are specialized uses of that same evidence path; they do not redefine A.10 as a pattern about labels, dashboard wording, or source rhetoric.

#EPV‑DAG (Evidence–Provenance DAG).

A typed, acyclic graph disjoint from mereology. Node types: SymbolCarrier (a s.System in CarrierRole, A.15), TransformerRole (external Transformer, A.12), MethodDescription (design‑time blueprint of a method, A.15), Observation (a dated assertion/result), s.Episteme (knowledge holon). Edge vocabulary is small and normative: evidences, derivedFrom, measuredBy, interpretedBy, usedCarrier, happenedBefore (temporal), etc. Practitioner view: it is the “because‑graph”: every claim answers “because of these carriers, by this Transformer, using that method, then.”

#Anchors (two relations, two flavours).**

• verifiedBy — links a claim to formal evidence (proof obligations, static guarantees, model‑checking artefacts).
• validatedBy — links a claim to empirical evidence (tests, measurements, trials, observations). Both anchors terminate in the EPV‑DAG, not in the mereology graph.

#A.10:4.3 SCR / RSCR (Symbol Carrier Registers).

Every Γ_epist aggregation SHALL emit an SCR: an exhaustive register of symbol carriers materially used in the aggregate, with id, type, version/date, checksum, source/conditions and optional PortionOf (A.14) for sub‑carriers. Every Γ_epist^compile SHALL emit an RSCR: SCR specialised to a bounded context (vocabularies, units) with publication‑grade identifiers and hashes. Why this matters: it prevents “lost sources” during composition and underwrites reproducibility without mandating any specific tool.

#A.10:4.4 Scope alignment (A.4) across Role–Method–Work (A.15).

• Design‑time: MethodDescription lives here; methods are blueprints; anchors reference what would constitute proof or test.
• Run‑time: Work (actual execution) lives here; traces reference which MethodDescription they instantiate and record happenedBefore. Bridging edges are explicit (“this run trace instantiates that spec”), so scopes never silently mix.

#A.10:4.5 External TransformerRole (A.12).

The system that produces or interprets evidence is external to the holon under evaluation. If true reflexivity is essential, model a meta‑holon (A.12): the self‑updating holon becomes the object of a meta-holon external transformer (the “mirror”), restoring objectivity.

#A.10:4.6 Γ‑flavour hooks (how each flavour anchors).

• Γ_sys (formerly Γ_core): physical properties are anchored by measurement models, boundary conditions, calibration carriers, and dated observations.
• Γ_epist: always outputs SCR/RSCR; every provenance/evidence node resolves to an SCR/RSCR entry.
• Γ_method: order‑sensitive composition; at design‑time a Method Instantiation Card (MIC) states Precedes/Choice/Join and guards; at run‑time traces record happenedBefore and point to the MethodDescription they instantiate.
• Γ_time: temporal claims state interval coverage; Monotone Coverage (no unexplained gaps/overlaps) is required.
• Γ_work: resource spending and yield are evidenced by instrumented carriers (meters, logs) and their MethodDescriptions; keep resource rosters separate from SCR/RSCR.

Practitioner shortcut: If you can answer what carriers, which system, which method, when, the anchor is likely sufficient; if any of the four is missing, it is not.

#Authority-reliance use of ordinary A.10 evidence paths

Use this subsection when an authority-looking case is being used as evidence for reliance. The evidence path is claim-bound: it supports a named claim or intended stronger use, not "authority" in general. This subsection does not change the governed object of A.10; it applies the same evidence/provenance path to high-pressure cases where displays, credentials, copied/generated text, dashboards, provenance labels, or attestations are being overread. If the live work, gate, speech-act, commitment, or evidence source is already clear, recover and cite that source directly instead of analyzing nearby wording first.

A10-lite is enough for source-finding, orientation, learning, and bounded reversible probes:

Minimum path for routine reliance:

Expanded fields are collected only insofar as they decide the live reliance question. Evidence depth scales with consequence severity, reuse, contestability, cross-context movement, and claim strength. Do not expand a source-finding note into a full evidence dossier, and do not collect every expanded field merely because a carrier is copied, generated, credential-like, provenance-like, or cross-context.

Adversarial misuse guard. Do not let carrier authenticity, provenance, copied approval, generated summary, stale screenshot, credential status view, or dashboard export convert into claim truth/currentness. Treat each as a rival explanation to test against issuer/source role, method/work trace, time/window, and relying context.

Data-minimization and privacy posture. Preserve minimum sufficient support for the intended reliance use. Use redacted, hashed, scoped, or role-mediated carrier refs when raw evidence would expose personal identity, access tokens, cryptographic proof material, tenant identifiers, security logs, incident details, internal release metadata, audit trails, privileged reviewer names, or sensitive model/data provenance. Redaction does not create source support; it must preserve enough recoverability for the relying context.

Case repairs:

| Copied approval or review summary | Show the original A.2.9 SpeechActRef / issuing act when approval or authorization is claimed, or the original reviewed source when only review-content currentness is claimed. Add copy relation, currentness, scope/window, evidence-producing work/event, and whether separate commitment/work support is live. Copy evidence is not approval by itself. | | Provenance/authenticity/attestation label | Show the bounded origin/history/build/process claim, source material, method/work trace, source-specific proof, carrier integrity, verifier/relying policy that accepts it for this use, and rival explanation. Provenance does not show truth, safety, approval, release, gate passage, permission, or assurance unless another exact source carries that stronger claim. | | Dashboard status tile | For gate-passage or release reliance, show dashboard query/source/time/window/currentness, source order, freshness policy, rival explanation, and the current A.21 GateDecision / DecisionLogRef with gate profile/version and release/work target; the A.10 path evidences that source chain. A status display is not gate passage or work occurrence by itself. |

| Rollback command-like cue | Show command/authorization source, actor, affected object, scope/window, and whether the cue is only an action invitation. A command cue is not execution evidence. | | Rollback execution result | Show A.15.1 U.Work occurrence, method/work trace, logs/traces, outcome evidence, and time/window. Execution evidence is not approval, assurance, or gate passage by itself. | | Generated explanation | Use E.17.EFP to classify the explanation relation and source-finding posture. For reliance, show claim-level attribution alignment: every operative claim relied on maps to a source passage, carrier, or exact governing source that supports that claim in the relying context. When that mapping is complete, A.10 may support those operative claims as source-backed evidence; the explanation itself still does not issue, approve, authorize, pass a gate, evidence execution, or raise assurance. |

| Model card or datasheet used as evidence | Show documented intended use, version/window, evaluation condition, limitations, evidence carriers, and whether a B.3 assurance claim is live. Documentation does not become readiness or assurance by presence. | | Extracted-source chain to gate/release use | Name the source locus, the first lossy or non-commutative transform step, the FPF relation or pattern governing that transform (A.6.3.CR, A.6.3.RT, A.6.3.CSC, E.17.EFP, E.17.ID.CR, or E.18 where applicable), the allowed inference move after the step, the exact governing source exit, the source reopen trigger, and the stronger use blocked until those supports are recoverable. | | Conflicting sources | When display, source carrier, decision log, recency/freshness signal, copied summary, generated summary, credential status, provenance label, or assurance evidence disagree, name the visible source, rival source, source order, decision source, freshness policy, and supersession rule. Do not choose by color, visual salience, confidence wording, copied wording, or apparent recency; stronger reliance is contested until the source-order question is resolved. |

| Sensitive evidence path | Use redacted, hashed, scoped, or role-mediated carrier refs when raw carriers expose secrets, personal data, security-sensitive material, privileged logs, tenant identifiers, or unnecessary identities. Redaction does not create source support; it must preserve enough recoverability for the relying context. | | Pointer/proof-status evidence path | Use a hash, proof/status verification result, source ref, scoped pointer, disclosure receipt, or role-mediated view instead of copying raw sensitive material when that artifact preserves enough recoverability for the relied-on claim/use. Do not copy raw secrets, tokens, privileged logs, personal identities, or tenant details merely to make the evidence path look fuller. |

If the path is incomplete, A.10 returns evidence/source posture, not action or reliance support for the attempted stronger use. Valid dispositions include source-finding only, reopen original carrier, request issuer/status verification, refresh dashboard/API query, mark stale/contested, downgrade intended use, proceed only with reversible/local action, or block the unsupported stronger reliance.

Broken-source repair route. If the relying actor cannot recover or verify the source path, return the repair to the accountable source role: issuer/performer, verifier/status service, evidence-producing work role/system, gate-decision source, role/status source, or boundary source. The A.10 result should name the missing source and blocked use rather than making the relying actor reconstruct a source they cannot issue or verify.

Role prompts for evidence/currentness use:

Repeated missing-source signal. If the same visible-item family repeatedly returns stale, contested, no-source, or no-currentness A.10 results, record a source-system repair item: instrument the source, expose decision/source refs, add currentness/status checks, preserve claim-level source links for generated or copied outputs, require credential views to show status/currentness windows, require model/data documentation to expose intended-use and evaluation-condition fields, or require provenance/attestation labels to name their bounded claim type. Repetition is a sign that the source path or display needs repair; it is not a reason to make each acting user rebuild the path manually.

Display guidance for evidence/currentness: an evidence or status display should show the claim/use, carrier/source role, exact ref or link, time/window/freshness, relying context, and unsupported stronger uses. A display that can only show source availability should say so; it must not imply approval, permission, gate passage, work occurrence, or assurance.

Incident-learning fields for evidence/currentness overread: visible carrier, intended claim/use, missing source-path field, exact carrier/source role/method-work/time relation needed, rival explanation that made the overread plausible, current safe disposition, and upstream repair item for instrumentation, source refs, status/currentness, claim-level source links, credential view, model/data documentation, or provenance/attestation label.

Contestability/redress route: when an evidence/currentness path affects person or team status, access, responsibility, compliance posture, or release decision, the A.10 result should name the disputed claim, carrier/source role, verifier or status source, freshness/revocation source, privacy-minimized evidence ref, safe interim disposition, and review route. A disputed display remains contested until the source-order or currentness question is resolved.

Positive repaired path. When the source path is complete, return the smallest source-backed support statement: named claim/use, carrier and source role, method/work trace, time/window/currentness, evidence relation, and the exact use it supports. This lets the relying pattern proceed inside that scope without treating evidence support as approval, permission, gate passage, work occurrence, or assurance.

What this does not authorize: A.10 does not approve, authorize action, pass a gate, release, create permission, create a commitment, assign a role, record a work occurrence, or raise assurance. It supplies the evidence path and support posture that A.15, A.6, B.3, A.21 gate-decision sources, A.20 constraint-validity sources, A.2.9 speech-act sources, A.2.8 commitment sources, A.15.1 work-occurrence sources, or another exact governing source may consume.

#Causal evidence support basis in evidence paths

Evidence graph paths that support causal-use claims must carry the C.28-governed CausalEvidenceSupportBasis without redefining causal estimands or causal support authority.

The C.28 values that A.10 may carry in an evidence path are:

observationalAssociationSupportBasis
interventionalActionSupportBasis
realizedCounterfactualSampleSupportBasis
identifiedCounterfactualEstimateSupportBasis
simulationOnlyCounterfactualOutputBasis

A.10 consumes this value set from C.28; it does not add causalAssumptionOnlySupport or noCausalEvidenceSupport as evidence-basis values. Assumption-only and no-support postures are represented by causal assumptions, support verdict, supported use, unsupported use, or abstain in C.28/B.3, not by a second evidence-basis vocabulary.

No unsupported causality-ladder climb:

observational-association evidence -> interventional-action claim requires CausalIdentificationProfile.
interventional-action evidence -> counterfactual-comparison claim requires CausalIdentificationProfile for
  identifiedCounterfactualEstimateSupportBasis, CounterfactualSamplingRealizabilityProfile for
  realizedCounterfactualSampleSupportBasis, or bounded-use treatment.
Simulation-only counterfactual output may support bounded model-supported use when model assumptions, validation, supported use, and unsupported use are declared. It does not become interventional evidence or realized counterfactual sample evidence by vocabulary, validation, or evidence-role relabeling alone.

Evidence-path micro-examples:

What changes in practice: an evidence path can show that a carrier supports a causal-use claim, but it must also show the causal evidence support basis and the relevant C.28 support references when the claim climbs from observation to intervention or from intervention to counterfactual comparison.

What this does not authorize: A.10 does not identify causal effects, create an estimand, certify target-trial emulation, or decide counterfactual sampling realizability; it stores and makes recoverable the evidence graph path and causal support-basis refs needed by C.28 and B.3.

#Archetypal Grounding

#Conformance Checklist

Practitioner’s audit (non‑normative, quick): For any claim, ask What carriers? Which system? Which method? When? If any answer is missing, A.10 is not satisfied.

#Consequences

#Rationale (SoTA alignment, reader‑friendly)

• Metrology & assurance. The requirement to name quantities, units, uncertainty, calibration carriers reflects long‑standing metrology practice and modern assurance cases: numbers are only comparable when their measurement models are stated.
• Knowledge provenance. The EPV‑DAG and SCR/RSCR embody post‑2015 best practices in provenance for knowledge artefacts: keep a complete, machine‑checkable trail from claims to carriers; separate provenance from part‑whole.
• Temporal reasoning. Monotone coverage (no unexplained gaps/overlaps) aligns with temporal knowledge graph practice and avoids “impossible histories.”
• Holonic parsimony. By drawing a firewall between mereology (A.14) and provenance, A.10 prevents semantic leakage and keeps the holarchy well‑typed.
• Role–Method–Work clarity. Anchoring explicitly rides on A.15: roles act via methods specified at design‑time and produce work observed at run‑time. This keeps agency, policy, and execution disentangled yet connected.
• Credential, provenance, attestation, and generated-source currentness. Verifiable credentials / digital identity practice separates issuer or trust anchor, holder binding, proof/status result, revocation, validity window, audience, and relying context. C2PA content provenance and SLSA / in-toto attestations separate bounded origin/history/build/process claims from truth, approval, release, safety, gate passage, permission, or assurance; their consumer-side verifier or policy acceptance rule is part of the relying context, not implied by artifact presence. LLM citation and generated-explanation practice requires claim-level attribution alignment before operative claims are relied on. A.10 adopts issuer/holder/verifier/status/currentness and claim-level attribution as evidence-path invariants, adapts credential, provenance, attestation, model/data documentation, and generated-explanation practice as FPF source-role and carrier-support inputs, and rejects visual display, copied text, generated text, provenance mark, credential display, or attestation form as evidence of a stronger action, gate, role/status, work-occurrence, assurance, or admissible-action effect without exact source support.

#Relations

• Builds on: A.1 Holonic Foundation; A.4 Temporal Duality; A.12 Transformer Externalization; A.14 Advanced Mereology; A.15 Role–Method–Work Alignment.
• Constrains / used by: B.1 (all Γ‑flavours: Γ_sys, Γ_epist, Γ_method, Γ\_time, Γ_work); B.1.1 (Dependency Graph & Proofs).
• Enables: B.3 Trust Calculus (R/CL inputs, auditability); B.4 Canonical Evolution Loop (clean design/run bridges).
• Coordinates with: C.28 when an evidence path is used as causal-use support; A.10 carries the evidence/provenance path, while C.28 governs causal-use question, support basis, identification, realizability, and supported/unsupported use.
• Coordinates with: A.15 for first-use action/reliance disposition, A.6 for mixed boundary wording, B.3 for assurance strength, A.21 for OperationalGate(profile), GateDecision, and DecisionLogRef, A.20 for ConstraintValidity status/witness, A.2.9 for speech-act refs, A.2.8 for commitments, and A.15.1 for work occurrences. A.10 supplies evidence paths for those sources; it does not create their gate decision, commitment, role/status, work-occurrence, assurance, or admissible-action effect.

#Migration (practical and brief)

Apply these text edits:

1. Terminology

   • manifest → “Symbol Carrier Register (SCR)”; release manifest → “Release SCR (RSCR)”.
   • creator / observer (as internal evidencer) → TransformerRole (external).
   • “symbol register” (ambiguous) → “Symbol Carrier Register (SCR)”.
   • Keep resource rosters in Γ_work separate from SCR/RSCR.

2. Boilerplate inserts

   • In A.10 (this pattern): retain definitions of EPV‑DAG, SCR/RSCR, and the flavour‑specific anchors.
   • In B.1.3 (Γ_epist): add the Obligations — SCR/RSCR block (“Γ_epist^synth SHALL output SCR… Γ_epist^compile SHALL output RSCR…”).
   • In B.1.5 (Γ_method): ensure MIC is referenced (Precedes/Choice/Join, guards, exceptions) and run‑time traces reference the MethodDescription they instantiate.
   • In B.1.6 (Γ_work): say “resource rosters are not SCR/RSCR; anchor meter/log readings via EPV‑DAG.”

#Evidence carriers for quantum-like readings

Use A.10 when a quantum-like statement needs evidence rather than only a local modeling note. The practical question is not "is this quantum-like source impressive?" but "which carrier supports which weak claim, under which time window and method?"

Action path:

1. State the weakest state/probe/export/viability reading being supported.
2. Pin the concrete carriers: source, trace, dashboard export, report, observation, metric, work result, model output, interview, survey, or incident record.
3. State the evidence-producing role and method: who or what produced the carrier, by which method, probe, measurement, or work act.
4. State the time window and decay/reopen condition.
5. State what the carrier does not show, including the strongest rival explanation still live.
6. Choose the next pattern: stay in A.10 for carrier anchoring, route to B.3 for assurance strength, route to C.16 for measurement legality, route to F.9 for bridge/export loss, or route to a C.26.* pattern for the remaining probe/state/envelope question.

For probe-coupled, distributed-state, bridge-loss, measurement-frame, or viability-envelope readings, include at least:

Useful outputs:

• a local evidence note when the claim only guides discussion;
• an EPV-DAG / SCR / RSCR entry when the claim enters a published assertion;
• a B.3 assurance tuple when the claim will support readiness, audit, release, compliance, or comparative strength;
• a reroute note when the carrier shows only ordinary measurement, bridge loss, or work enactment.

Do not let the label quantum-like carry evidence weight by itself. The evidence graph carries the claim; the math lens only explains what representational mistake the evidence is being used to avoid.

#A.10:End