#Evidence Graph & Provenance Ledger

G.6 · Stable · Evidence and provenance pattern · Normative where conformance rows say so; examples and SoTA rows are informative guidance. · Part G - Discipline SoTA Patterns Kit

#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: Evidence and provenance pattern Status: Stable Normativity: Normative where conformance rows say so; examples and SoTA rows are informative guidance.

Use this pattern when a claim, admission result, assurance result, selector result, maturity transition, benchmark result, or refresh decision needs a citable evidence-provenance path rather than a local evidence-use statement.

#Keywords

• EvidenceGraph
• provenance
• PathId
• PathSliceId
• lane tags (TA/VA/LA)
• SCR/RSCR
• GateCrossing
• CrossingBundle
• UTS PathCard
• TriggerAliasMap
• Γ-fold pinning.

#Relations

#Content

#Problem Frame

Use this pattern when a claim, admission result, assurance result, selector result, maturity transition, benchmark result, or refresh decision needs a citable evidence-provenance path rather than a local evidence-use statement.

Use it when the working question is:

• which evidence-use relations, source records, work occurrences, method descriptions, proof checks, measurements, status-use relations, or causal-use references make the claim traceable;
• that the evidence relation is a graph path in a declared provenance graph, while actual work and transformation-flow claims remain governed by A.15.1 and E.18;
• which time window, bounded context, reference plane, bridge, edition, policy, or source-currentness relation changes the admissible use;
• which downstream selector record, assurance record, release package, benchmark record, audit record, or refresh record may cite the evidence path without copying the whole evidence table;
• what stronger downstream use is not carried by the evidence path and which direct pattern governs that use.

Primary EntityOfConcern. The primary EntityOfConcern is addressable evidence provenance: an EvidenceGraph, its graph-path addresses PathId and PathSliceId, and the provenance ledger entries that make those paths replayable. The pattern governs addressable provenance. It does not create U.EvidenceRole, does not make an episteme hold a work-facing role, and does not replace A.10, A.2.4, B.3, C.28, or F.10.

First useful move. Write the smallest PathCitationRecord: claim or use, EvidenceGraphRef, graph path, bounded context, downstream citation use or evidence-use relation, time window, source or provenance constraints, bridge or edition refs when current, and NotCarried.

What goes wrong if missed. Evidence is summarized as a story, badge, confidence phrase, benchmark score, proof label, or dashboard tile; downstream users cannot find which sources and checks carried the claim; context crossings are hidden; refresh becomes a global rerun instead of a local path update.

What this buys. A selector, auditor, assurance user, benchmark consumer, or refresh process can cite one stable path and later replay exactly the sources, relations, windows, and constraints that made the claim admissible.

Not this pattern when. If only one episteme is being used as evidence or status before a full path is needed, use A.2.4. If the current question is ordinary evidence relation and source-currentness without Part-G path addressing, use A.10. If the claim is assurance, use B.3. If the claim is causal use, use C.28. If the question is status-family mapping, use F.10. If the question is publication, view, source-use, explanation-use, or specification-use, use E.17, E.17.0, E.17.2, E.17.EFP, or E.10.D2. If the question is performed work, use A.15.1.

#Problem

Large projects need to rely on evidence that is distributed across proofs, measurements, work traces, source publications, credentials, model cards, benchmarks, bridge records, and status sources. A compact evidence-use statement is often enough for a local claim, but it is not enough when downstream work must cite, replay, compare, refresh, or audit the whole provenance line.

The common failures are:

1. Narrative provenance. A report says "because the evidence carries the claim" but does not expose the graph path from claim to evidence relations, sources, checks, and work occurrences.
2. Hidden crossing. Evidence accepted in one bounded context, reference plane, edition, or status window is reused in another as if no bridge or currentness relation were needed.
3. Role drift. A proof, dataset, status cell, report, or benchmark result is treated as if it held an evidence role, instead of being a value in an evidence-use, status-use, source-use, or provenance relation.
4. Path metaphor drift. A graph path is read as an action route or workflow. The pattern then starts teaching how work flows, rather than how a provenance graph is addressed.
5. Ledger process drift. A provenance ledger is confused with work-progress, review-comment, or process evidence. The pattern then records development status instead of citable evidence-provenance facts.
6. Refresh fanout. A source edit, edition change, decay event, bridge change, or policy change forces a broad "rerun everything" because the affected evidence paths were never addressable.

#Forces

#Solution

Create a citable EvidenceGraph and PathCitationRecord set when a local evidence-use statement is too small for the reliance being claimed. Keep the graph declarative and typed: nodes and edges carry provenance relations; PathId and PathSliceId cite graph paths; a provenance ledger records replayable path entries.

#Boundary to Neighboring Patterns

G.6 is a path-addressing pattern over evidence provenance. It consumes or cites the following values without redefining them:

Do not add a local EvidenceRole value set. Older labels such as "proof role", "measurement role", "benchmark role", or "status role" are repair prompts. Recover the direct evidence-use, status-use, source-use, causal-use, assurance, work, or publication-use relation first.

#EvidenceGraph

An EvidenceGraph is a typed directed acyclic graph used for evidence-provenance citation. It is a graph because path identity, path slicing, and path-local refresh depend on graph structure. The graph is not a holarchy, not a transformation-flow structure, not a work plan, and not a method.

Minimal graph fields:

EvidenceGraph:
  EvidenceGraphId:
  BoundedContext:
  ClaimFamilyOrUse:
  ReferencePlane:
  GraphNodeSet:
  GraphEdgeSet:
  TimePolicyOrWindow:
  SourceCurrentnessPolicy:
  BridgeOrTransferRefs:
  EditionOrPolicyRefs:
  GraphPathAddressingRule:

Minimal node kinds:

Minimal edge kinds:

Extra graph annotations may exist for diagrams or tools, but conformance depends only on typed nodes, typed edges, path addresses, windows, constraints, and governing-pattern refs.

#PathId and PathSliceId

A PathId is a stable identifier for one claim-local graph path inside an EvidenceGraph. A PathSliceId is a stable identifier for the same path under a declared slice: time window, reference plane, bounded context, edition, bridge, policy, or selected evidence subset.

Here path means a path in the evidence-provenance graph. It is not an imperative route, work sequence, workflow, or transformation-flow path.

Use this compact record:

PathCitationRecord:
  ClaimOrUseRef:
  EvidenceGraphRef:
  PathId:
  PathSliceId:
  BoundedContext:
  ReferencePlane:
  EvidenceUseRefs:
  PathNodeRefs:
  PathEdgeRefs:
  TimeWindowOrFreshnessPolicy:
  SourceCurrentnessRefs:
  BridgeOrLossRefs:
  EditionOrPolicyRefs:
  DownstreamCitationUse:
  NotCarried:
  ReopenTrigger:

NotCarried names the stronger claim not carried by this graph path: approval, permission, gate passage, release, performed work, assurance, causal identification, status assertion, compliance, benchmark superiority, or truth outside the declared claim and scope.

#Provenance Ledger

A ProvenanceLedger is a citable record over PathCitationRecord entries. It is not a work-progress log, review-comment log, or process-status log.

Minimal fields:

ProvenanceLedger:
  LedgerId:
  EvidenceGraphRef:
  PathCitationRecords:
  SourceOrderPolicy:
  CurrentnessPolicy:
  PrivacyOrDisclosureBoundary:
  RefreshScopeRule:

Use a provenance ledger when several downstream records need the same path family: selector records, benchmark harnesses, assurance cases, release packages, maturity transitions, refresh records, or safety reviews. Do not create a ledger merely because one local evidence-use statement is easy to write in prose.

#Refresh and Source Return

Reopen the smallest affected path when one of these changes:

• evidence carrier identity, integrity, access, or hash;
• source publication, source order, supersession, or currentness window;
• work occurrence, measurement run, method description, proof check, or observation record;
• bridge, congruence level, loss statement, reference plane, or bounded context;
• causal-use profile, status-use statement, assurance-use requirement, or gate relation consumed downstream;
• edition, policy, threshold, verifier rule, relying-party context, or minimum disclosure boundary.

The reopen result is local to PathId, PathSliceId, or the smallest graph subpath that carries the changed relation. It does not rewrite the whole project and does not certify a new downstream decision by itself.

#Declarative Representation Discipline

EvidenceGraph, PathId, and PathSliceId are declarative representation values. They tell a reader what provenance relation is being cited. They do not tell a worker what to do next.

When a source phrase says "evidence path", "provenance route", "audit trail", "lineage flow", "data pipeline", or "workflow", recover the kind before copying the word:

#Extension Wiring Without Core Drift

Method-family, benchmark, selector, parity, or telemetry patterns may add required pins to a PathCitationRecord. They do not add new core node kinds unless the governing pattern explicitly changes G.6.

Examples:

• G.5 may cite a PathId for selector explainability or admissibility.
• G.9 may cite a PathSliceId for benchmark parity or replication lineage.
• G.11 may consume reopen triggers and affected path slices for refresh.
• A causal-use pattern may add C.28 refs to a path, but the causal-use relation remains governed by C.28.
• An assurance pattern may consume a path, but the assurance tuple remains governed by B.3.

#Archetypal Grounding

#Brake Envelope Claim

A braking-system claim says the vehicle stops within a declared distance under declared conditions. A.10 identifies telemetry files, calibration certificates, test runs, and external lab work. G.6 mints a PathId that cites the graph path from the claim to proof checks, instrumented tests, calibration records, work occurrences, and time windows. NotCarried names stronger downstream uses; B.3 and gate patterns govern assurance and release uses.

#Benchmark Parity Claim

A model-family report says a method reaches parity on a benchmark. G.6 cites the path through dataset version, evaluation protocol, result record, source publication, method description, and replication work. If the dataset edition, metric policy, or source-currentness relation changes, the affected PathSliceId reopens without rerunning unrelated evidence paths.

#Dashboard Status Cue

A dashboard cell shows Ready. F.10 governs status-family mapping and status-use. A.10 governs the evidence relation to the governing register or source. G.6 is used only when a downstream release package, selector, assurance record, or audit needs a stable path from the visible cue to source, status-use relation, query time, window, issuer, and currentness policy.

#Causal Policy Result

A policy report says an intervention caused improvement. C.28 governs causal-use support basis, identification, and realizability. A.10 records evidence relation. G.6 only gives a citable path from the policy claim to the causal-use refs, data sources, assumptions, work occurrences, time window, and bridge refs needed for later audit.

#Bias Annotation

Biases guarded here:

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits:

• downstream records cite evidence paths without copying evidence tables;
• source, bridge, policy, edition, and time changes reopen the smallest path slice;
• evidence, assurance, causal use, status, gate, work, and publication claims stay in their governing patterns;
• provenance becomes replayable and privacy-minimizable through scoped refs.

Costs:

• path identity, node typing, and source-currentness refs add overhead;
• graph paths can look like routes unless declarative representation discipline is kept visible;
• users must resist treating one complete path as a complete downstream decision.

#Rationale

A.10 already gives the evidence-provenance graph relation for claims. G.6 adds the Part-G need that local A.10 records do not fully satisfy: stable citation and path-local refresh for selectors, benchmarks, maturity transitions, assurance records, and release packages.

The pattern uses a graph mathematical lens because the useful mathematical object is a path through typed nodes and edges. It does not use graph language to claim that work "flows" through the path. When actual transformation structure matters, E.18 governs it. When actual work matters, A.15.1 governs it.

The pattern uses ledger language only for a provenance record. It does not invite process logs into pattern prose.

#SoTA-Echoing

Refresh the source use behind this pattern when current provenance, credential, attestation, benchmark, lineage, assurance-case, or source-currentness practice changes the separation between provenance presence, evidence use, assurance, status use, and role assignment.

#Relations

• Builds on: A.10 for evidence-provenance graph relation and evidence paths; A.2.4 for compact evidence-use and status-use relation slots; A.6.5 and A.6.RSIR for relation-slot discipline; C.2.1 for episteme slot relation; E.24 for ontic and slot-relation concept discipline.
• Coordinates with: B.3 for assurance; C.28 for causal-use evidence content; F.10 for status-family mapping; F.9 for bridge and loss; E.17, E.17.0, E.17.2, E.17.EFP, and E.10.D2 for publication, view, explanation, and specification-use; A.15.1 for work occurrences; E.18 and E.18.2 for transformation-flow structures and their mathematical descriptions; A.21 for gate decisions when those are the downstream use.
• Used by: selector, benchmark, parity, refresh, assurance, maturity, and release patterns that need stable evidence-provenance path citation, including G.5, G.9, and G.11.
• Does not govern: stronger downstream uses named in NotCarried, work occurrence, source publication identity, or transformation-flow structure; those remain with their direct governing patterns.

#G.6:End

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