#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
• status register
• register excerpt
• generated-explanation source support
• exact authority reference
• 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 traces, 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 or result record), 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 records).
• 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 substantively 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 effect for a named work move or reliance move, not "authority" in general. This subsection does not change the governed object of A.10; it applies the same evidence and provenance path to source-sensitive cases where displays, credentials, copied text, generated text, dashboards, provenance labels, or attestations are being overread. If the live work occurrence, gate decision, speech act, commitment, or evidence path is already clear, recover and cite that exact FPF 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 follows consequence severity, reuse, contestability, cross-context movement, and the support required for the attempted claim. 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 or currentness. Treat each as a rival explanation to test against issuer or source-maintenance role assignment, method trace or 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 payloads, 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, or attestation label | Show the bounded origin, history, build, or process claim; source episteme, source episteme publication, or source carrier; method trace or work trace; source-specific proof; carrier integrity; verifier or relying policy that accepts it for this claim or effect; and rival explanation. Provenance does not show truth, safety, approval, release, gate passage, permission, or assurance unless another exact source carries that additional claim or effect. | | 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 work target or claim target, scope/window, and whether the cue is only an A.6.A action invitation. A command cue is not execution evidence. | | Rollback execution result | Show A.15.1 U.Work occurrence, method trace or work trace, logs, 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-bound attribution alignment: every operative claim relied on maps to a source passage, carrier, or exact governingPatternRef or authoritySourceRef 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 admissible-use statement or external intended-use field, 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 or release claim | Name the source reference, 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 admissible inference move after the step, the exact governingPatternRef or authoritySourceRef that carries the live claim, the source reopen trigger, and the gate claim or release claim blocked until those supports are recoverable. | | Conflicting sources | When display, source carrier, decision log, recency signal, 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; the work claim or reliance claim 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 traces/data, privileged logs, tenant identifiers, or unnecessary identities. Redaction does not create source support; it must preserve enough recoverability for the relying context. | | Pointer or proof-status evidence path | Use a hash, proof verification result, status verification result, source ref, scoped pointer, disclosure receipt, or role-mediated view instead of copying raw sensitive carriers or payloads when that pointer preserves enough recoverability for the relied-on claim or effect. 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-path posture and source-currentness posture, not work or reliance support for the attempted claim or effect. Valid dispositions include source-finding only, reopen original carrier, request issuer or status verification, refresh dashboard query or API query, mark stale or contested, narrow the live P2W class or reliance claim, proceed only with a reversible local probe under an explicit work plan when work is live, or block the unsupported work claim or reliance claim.

Broken-source repair assignment. If the relying actor cannot recover or verify the source path, assign the repair to the accountable project-side responsibility assignment: issuer or performer, verifier or status service, evidence-producing work role assignment or system, gate-decision source, role or 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 or currentness use:

Repeated missing-source indicator. 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 checks and status checks, preserve claim-bound source links for generated or copied outputs, require credential views to show status windows and currentness windows, require model documentation and data documentation to expose intended-use and evaluation-condition fields, or require provenance labels and attestation labels to name their bounded claim type. Repetition is an indicator 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 and currentness: an evidence or status display should show the claim or effect, carrier, source-maintenance role assignment, exact ref or link, time window, freshness, relying context, and unsupported action, claim, or effect. 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 and currentness overread: visible carrier or publication face, intended claim or effect, missing source-path field, exact carrier, source-maintenance role assignment, method trace, work trace, and time relation needed, rival explanation that made the overread plausible, current safe disposition, and upstream repair item for instrumentation, source refs, status, currentness, claim-bound source links, credential view, model documentation, data documentation, or provenance and attestation label.

Contestability and redress path: when an evidence path or currentness path affects person or team status, access, responsibility, a compliance relation, or a release decision, the A.10 result should name the disputed claim, carrier, source-maintenance role assignment, verifier or status source, freshness or revocation source, privacy-minimized evidence ref, safe interim disposition, and review or redress path. 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 or effect, carrier and source-maintenance role assignment, method trace or work trace, time window, currentness, evidence relation, and the exact action or reliance it supports. The downstream use is admissible only 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 governingPatternRef or authoritySourceRef may consume.

#Local evidence-use classifier and RelianceDisposition for support-looking sources

Use this subsection when a visible source is being treated as evidence for a claim, act, work move, gate, release, review claim, assurance use, or problem-side P2W use. The first A.10 move is to recover the evidence kind and the bounded use it can actually support. Broad source words such as source, metric, confidence, conformant, safe, ready, certified, approval, or permission are only recovery prompts; they do not name the evidence relation by themselves.

This subsection uses a local reliance-use classifier, not a Core evidence-kind ontology. Its practical gain is a smaller next move: recover the evidence relation, name the supported and unsupported use, then stop or exit to the exact receiving pattern. It is not a required project review step and does not ask the practitioner to inspect every source-looking item.

Support role: the first table is an A.10 recognition aid, the RelianceDisposition table is a minimum local record aid, and the worked source-overread slices are regression/review slices. They are not project checklists, a required sequence, a new evidence ontology, or a general source classifier. Use only the row that answers the live attempted evidence use, then stop when the bounded evidence relation, supported use, unsupported use, and reopen condition are clear. This local section returns the attempted use to A.10 evidence relation; it does not create an extra SEMIO authority or shared relation family.

Affordability card: orientation or source-finding remains a cue and stops here; bounded reliance states one supported use, unsupported use, window, and reopen condition; threshold reliance exits to the minimum receiving pattern only when the B.3 material-reliance threshold is live: behavior, safety, release, compliance, public or protocol behavior, access, resource allocation, people/team status, operational action, or controlled-object regulation would materially change. Plain wording remains ordinary unless it changes admissible use, support, evidence, gate, assurance, work, decision, or neighboring-pattern exit.

Cheap stop: if a bounded claim, current carrier, evidence path, window, supported use, unsupported use, and reopen trigger are present, and no assurance, gate, work, control-bearing relation, release relation, or B.3 material-reliance threshold is live, stay in A.10. Do not open B.3, A.21, B.2.5, or a broad evidence pack merely because the source looks official, quantitative, generated, credentialed, or safety-related.

Common wrong first reading: a visible source is approval, permission, safety, or readiness. First honest entry: recover the A.10 evidence path for one bounded claim or use; approval, permission, safety, readiness, gate passage, and work authority stay with their receiving patterns when live.

Plain move palette: RelianceDisposition=pass means proceed only inside the bounded use; RelianceDisposition=degrade means use only a narrower or reversible version; RelianceDisposition=abstain means do not decide yet; RelianceDisposition=reopen means changed or contested support defeated the previous reading; RelianceDisposition=evidence-needed means ask for the named missing evidence at the named decision point; RelianceDisposition=safety-case-required means return to B.3 because the B.3 material-reliance threshold is live; RelianceDisposition=no-supported-current-use means block the current attempted use until a receiving source changes.

For A.10 use, RelianceDisposition is a local disposition over the evidence path and the bounded reliance use. Outside a table column already headed RelianceDisposition, write the qualified form RelianceDisposition=... and bind it to the named attempted use, currentness/window when live, supported use, unsupported use, and reopen or stop condition; it is not CV.Status, GateDecision, selector result, or ProblemCard@Context state.

Observed-effect or consequence evidence may be used only for what happened or is credibly recorded. If the attempted use says the source caused, prevented, would have changed, or is responsible for that effect, leave ordinary A.10 reliance and open C.28 plus any live evidence, work, or assurance relation.

If a proxy marker, benchmark, confidence value, dashboard metric, or score becomes the primary driver for action, release, resource allocation, people/team status, or P2W priority, check whether the live claim also raises an E.13 proxy-to-objective question. Do not open E.13 for every metric; open it only when the proxy is being used as the target or decision driver.

If publication or observation of a cue changes the situation or source condition being read, recover the probe-coupled boundary before treating the cue as passive evidence. This sentence does not import quantum-like vocabulary; it only prevents passive-evidence overread for dashboards, warnings, labels, and public status displays.

Minimum real contest/redress: a contest path exists only when the affected party or accountable reviewer can identify the disputed claim or source, affected use or harm, accountable review role, evidence or argument allowed in challenge, possible disposition change, outcome record, and reopen trigger. A feedback channel, complaint form, or appeal label without those recoverable items is not enough to change the disposition.

Affected-party contestable minimum: even when raw evidence stays reviewer-only, the contesting party must be able to see enough of the claim, source class, disposition, affected use, accountable role, and allowed challenge evidence to challenge the result. Privacy, security, or privilege can narrow disclosure; they cannot erase the challengeable minimum while still claiming contest or redress.

False-negative reliance guard: a blocked, abstained, or evidence-needed use is not final if admissible challenge evidence, missing affected-party evidence, changed source, changed representation, or redress can materially change the disposition. If refusal is based on missing evidence, name the missing evidence kind and decision point rather than closing the dispute by vagueness.

Sensitive evidence boundary: use scoped, hashed, redacted, or role-mediated evidence refs when raw carriers would expose personal data, secrets, tokens, privileged logs, tenant identifiers, incident details, security-sensitive traces, or unnecessary identities. A redacted path must still preserve enough recoverability for the relied-on claim, disposition, and contest path.

Worked source-overread slices:

#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](/generated/patterns/A.10) consumes this value set from [C.28](/generated/patterns/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](/generated/patterns/C.28)/[B.3](/generated/patterns/B.3), not by a second evidence-basis vocabulary.

No unsupported CausalityLadderRung 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](/generated/patterns/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](/generated/patterns/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](/generated/patterns/C.28) and [B.3](/generated/patterns/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 epistemes and their carriers: 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, status-register, and generated-source currentness. Verifiable-credential and digital-identity practice separates issuer or trust anchor, holder binding, proof result, status result, revocation, validity window, audience, and relying context. Some bounded contexts also treat a register entry or status-source entry as the source that creates or changes role assignment, status assertion, permission, duty, or gate state; a credential view, pass, badge, dashboard cell, API response, screenshot, or certificate excerpt is then a publication of that source, not automatically the source itself. C2PA content provenance plus SLSA and in-toto attestations separate bounded origin, history, build, and 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 source-carrier presence. LLM citation and generated-explanation practice requires claim-bound attribution alignment before operative claims are relied on. A.10 adopts issuer, holder, verifier, status, and currentness recoverability, status-source recoverability, and claim-bound attribution as evidence-path invariants, adapts credential practice, provenance practice, attestation practice, model documentation, data documentation, register-backed status display, and generated-explanation practice as FPF source-role and carrier-support inputs, and rejects visual display, copied text, generated text, provenance mark, credential display, register excerpt, or attestation form as evidence of an operative action invitation, gate, role assignment, status assertion, work-occurrence, assurance, or admissible-work effect without exact source support.

Action result from that cited practice basis: provenance, attestation, credential, status-register, and generated-source practice rejects the shortcut that provenance means truth, safety, release, permission, or assurance. The local A.10 result is bounded origin, history, build, holder or status currentness, generated-claim source mapping, supported use, unsupported use, and reopen when the verifier, trust model, status or currentness rule, source mapping, or source-order relation changes.

#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 DesignRunTag 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 use and unsupported use.
• Coordinates with: A.15 for work or reliance disposition, A.6 for mixed boundary wording, B.3 for assurance, A.21 for OperationalGate(profile), GateDecision, and DecisionLogRef, A.20 for ConstraintValidity status or 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 effect, status effect, work-occurrence, assurance, admissible work effect, or admissible reliance 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 minimal claim, under which time window and method?"

Action path:

1. State the minimal state, probe, export, or 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, decay condition, and reopen condition.
5. State what the carrier does not show, including the most relevant rival explanation still live.
6. Choose the next pattern: stay in A.10 for carrier anchoring, apply B.3 for assurance claims, apply C.16 for measurement legality, apply F.9 for bridge or export loss, or apply a C.26.* pattern for the remaining probe, state, or 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 assurance;
• a neighboring-pattern 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.

#C.29 MLA relation

If a mathematical lens needs evidence support, write the evidence path, source currentness, provenance, and any model-card or datasheet evidence use in A.10. A C.29 output may state only LensSupportPosture for the mathematical-lens adequacy claim; it is not an evidence path, currentness proof, provenance record, or evidence-carrier substitute. Assurance or release confidence goes to B.3; measurement construction or comparability goes to C.16.

#A.10:End

Last Updated: 2026-01-22 — this section last modified in upstream FPF commit 6e439584 (github.com/ailev/FPF)