#Work-Relevant Source Restoration

A.15.4 · Stable · Architectural (A) · Normative unless marked informative · 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: Architectural (A) Status: Stable Normativity: Normative unless marked informative

At a glance. Use A.15.4 when an encountered source candidate is about to guide work or reliance before the claim-carrying source has been recovered. The source candidate may be a dashboard tile, credential view, copied approval, generated explanation, provenance mark, schema wording, API wording, publication face, or composed source chain.

Use this when. Use this pattern when the acting user is ready to proceed because something looks approved, current, safe, evidenced, delegated, released, or ready, but the work claim or reliance claim still needs its governing project source named by value.

First output. One compact source-restoration note:

SourceRestorationNote:
  EncounteredSourceCandidate:
  WorkOrRelianceClaimUnderRepair:
  ClaimOrEffectNeeded:
  GoverningSourceNeeded:
  RelationGovernedMoveNow:
  BlockedOverread:
  StopOrReopenCondition:

First move in practice. Name what the encountered source candidate may safely do now: orient the user, help find a source, allow a bounded reversible probe under U.WorkPlan, proceed inside a recovered relation, or block only the unsupported work or reliance claim.

What goes wrong if missed. A dashboard, credential view, copied approval, generated explanation, provenance mark, schema wording, API wording, publication, display, or cue starts acting as the work or reliance source relation. Work then proceeds or stops while the gate decision, evidence path, speech act, commitment, role assignment, status record, work occurrence, source episteme, or source publication that would carry the claim is missing, stale, revoked, or contradicted.

Primary EntityOfConcern in plain terms. One source-restoration relation for one work or reliance claim under repair, work-relevant P2W claim under repair, or P2W chain position under repair. The relation connects the encountered source candidate, the needed claim or effect, the source required for that claim, the next relation-governed move, and the blocked overread.

First restoration checks.

1. Name the encountered source-candidate kind and publication position without treating its appearance as the source relation itself.
2. Name the work or reliance claim under repair, work-relevant P2W claim under repair, or P2W chain position under repair.
3. Name the claim or effect that would be carried: gate passage, release reliance, evidence relation, assurance claim, speech act, commitment, role-assignment relation, status currentness, work occurrence, source currentness, boundary claim, or another claim named by value.
4. Recover the source required for that claim: the governing FPF pattern plus the reference named by value.
5. Choose the lightest relation-governed disposition now: proceed inside the recovered relation, narrow the move, run a bounded reversible probe under U.WorkPlan, reopen or refresh the source, ask the accountable role assignment to expose or repair it, or block only the unsupported claim or effect.

Not this pattern when. Stay in A.15 when the question under repair is only U.Role, U.Method, U.MethodDescription, U.WorkPlan, and U.Work separation. Stay in E.17 when the question under repair is only publication-face exposure or multi-view publication. Stay in A.10, B.3, A.20, A.21, A.2.8, A.2.9, A.6, or A.15.1 when evidence, currentness, engineering justification, gate-passage claim, ConstraintValidity status, commitment, speech act, boundary claim, or work occurrence already governs the claim or effect directly.

What this buys. The acting engineer-manager can keep work moving without trusting appearances: use the source candidate for orientation or source-finding when that is all it can carry, proceed only inside the recovered relation when that relation exists, and turn repeated ambiguity into source-relation repair work rather than repeated manual reconstruction.

Dashboards, credential views, generated explanations, copied approvals, provenance labels, green tiles, schema wording, API wording, and composed source chains often look ready for action before the source that carries the claim is visible. The practical problem is to decide what an engineer-manager may do now without turning appearance into approval, gate passage, evidence, assurance, performed work, role-assignment currentness, status currentness, or release permission.

#Keywords

• work-relevant source restoration
• dashboard display
• credential view
• generated explanation
• copied statement
• provenance mark
• required project-side FPF kind and reference
• admissible next project move
• blocked overread
• P2W load and position
• approval-looking display.

#Relations

#Content

#Problem Frame

Dashboards, credential views, generated explanations, copied approvals, provenance labels, green tiles, schema wording, API wording, and composed source chains often look ready for action before the source that carries the claim is visible. The practical problem is to decide what an engineer-manager may do now without turning appearance into approval, gate passage, evidence, assurance, performed work, role-assignment currentness, status currentness, or release permission.

Plain recognition line. Let the visible cue point to a relation named by value, source episteme, source publication, evidence path, gate decision, role-assignment record, status record, work occurrence, or assurance claim. Do not let the cue become the relation that permits work or reliance.

Source wording discipline. In this pattern, source is not a generic kind. Governing source means the project-side value, named by FPF kind and reference, that carries the claim or effect under repair: source U.Episteme, source U.EpistemePublication, evidence path, gate decision, speech act, commitment, credential record, status record, role assignment, work-occurrence record, register entry, source relation, or another named project-side value. Source-finding cues, publication faces, publication carriers, renderings, dashboards, copied wording, and generated explanations remain source candidates unless they expose that governing source. If no governing source can be named, keep the encountered source candidate at cue-only orientation or source-finding use.

#Cluster Boundary

A.15 remains the kernel for separating U.Role, holder and context, U.Method, U.MethodDescription, U.WorkPlan, and dated U.Work. A.15.4 starts only when an encountered source candidate begins to justify a work claim or reliance claim and the team needs to recover the source that carries that claim, effect, or relation. If the governing pattern and project-side reference are already known, use them directly and keep A.15.4 as the bounded restoration step.

#Work-Relevant Source Restoration

#Core stress-case rule

Ordinary source-restoration note. In ordinary use, do not build a source dossier. The first useful note is:

encounteredSourceCandidate; work or reliance claim under repair; claim or effect needed; governing source needed; relation-governed move now; blocked overread; stop or reopen condition

The encountered source candidate may be a tile, credential view, approval-looking memo, generated explanation, copied review, provenance mark, API wording, functional-description publication, or composed source chain. The pattern asks whether the requested claim is currently carried by a project-side source named by value, not whether the source candidate is impressive, fluent, easy to inspect, or visually salient.

Conditional source-relation field set. Use the fuller fields below only when release, safety, compliance, role assignment, status, gate, assurance, contested source, external reliance, cross-context reuse, currentness, revocation, generated source relation, or copied source relation is being relied on for the claim under repair. These fields are local restoration aids, not a new record kind.

Start with the A.15.4 first restoration checks above when the encountered source candidate is about to guide a work move, reliance move, or work-relevant claim. If the issue under repair is only evidence, currentness, gate-passage claim, ConstraintValidity status, engineering justification, commitment, speech act, boundary wording, use-boundary wording, credential proof, source-status proof, explanation, comparison, or publication-carrier or front-end behavior, use the pattern governing that issue directly. Use A.15.4 only when source restoration is needed before role assignment, method, plan, work, work result, result measurement, or another work move or reliance move can proceed.

Authority-looking source-backed work or reliance case. Use A.15.4 when an approval-, permission-, gate-, command-, credential-, delegation-, revocation-, status-, provenance-, dashboard-, copied-review-, generated-explanation-, schema-, API-, or composed-chain case is about to be used as a work cue, reliance claim source, release-reliance claim source, performed-work evidence source, approval-claim source, approval-effect source, role-assignment-claim source, status-claim source, or next work-relevant move. The recognition moment is that an encountered publication, display, credential view, wording, or explanation looks like permission, prohibition, readiness, or evidence for starting work. The repair question remains: which work or reliance claim is being made, and which source is required for it?

Here "authority-looking case" is only a recognition phrase for the encountered situation. The governing source that permits, forbids, records, or carries the work-relevant claim may instead be a GateDecision, SpeechAct, U.Commitment, U.RoleAssignment, credential record, status record, A.6.B-claim being made, A.10 evidence path, or B.3 assurance claim. Use E.17:5.1c for the shared meanings of orientation use, reliance use, work claim, reliance claim, operative claim, unsupported downstream use, and reopen trigger; use E.17:5.1d when the primary question under repair belongs to another governing pattern.

The central behaviour is: name the work or reliance claim under repair, work-relevant P2W claim under repair, or P2W chain position under repair; name the source that carries the needed claim or effect; keep the U.Episteme or U.EpistemePublication distinct from publication form, MVPK face, publication carrier, rendering, and source-finding cue; choose the minimum sufficient next move; and do not raise the claim beyond the recovered relation, source relation, or recovered use boundary. If the named project record states the governing FPF relation, use that recorded relation directly rather than inferring it from wording.

Positive repaired disposition. An encountered U.Episteme publication, publication form, MVPK face, publication carrier, rendering, or source-finding cue may guide work or reliance only to the claim or effect carried by the recovered source, actor or role assignment, work or reliance claim under repair, work-relevant P2W claim under repair, or P2W chain position under repair, affected work target, context, window, and source-recoverable claim or effect. The repaired outcome is the smallest relation-governed work or reliance statement plus the unsupported work claim or reliance claim still blocked.

Reliance dispositions by recovered source relation:

A small A.15.4 restoration note is enough for the first disposition:

Borrowed episteme and publication discipline. A.15.4 borrows the C.2.1, E.17, and A.16.0 distinction rather than minting a new generic U.* kind. The claim-bearing FPF kind here is U.Episteme; U.EpistemePublication is used only when that episteme is available as a published episteme with MVPK-face references. Publication forms, MVPK faces, publication carriers, renderings, PublicationUnit instances, and source-finding cues are separate kinds or relation positions in the case. A planned baseline remains a U.WorkPlan or U.WorkPlanning plan record such as SlotFillingsPlanItem; launch values and finalization values remain their own project records, decision logs remain gate or decision records, performed-work evidence remains evidence, and dated work occurrences remain A.15.1 or U.Work matters.

When the required source is incomplete, choose one relation-governed source-restoration disposition after naming the work or reliance claim under repair, work-relevant P2W claim under repair, or P2W chain position under repair and the source required for that claim or effect; pick the lightest move that preserves practical work and source recoverability:

1. Use the encountered source candidate only for orientation or source-finding.
2. Reopen the required source U.Episteme, source U.EpistemePublication, register entry, or governing source, or refresh status or currentness.
3. Narrow actor and role assignment, requested operation or work class, affected work target, affected resource, affected claim, context, and effective window until the recovered source really covers the move.
4. Run a bounded reversible probe under an explicit U.WorkPlan when no external-impact reliance is being made.
5. Ask the role assignment accountable for the issuer, gate decision, evidence path, role-assignment record, status record, or boundary claim set to expose or repair the missing source.
6. Repair the U.WorkPlan, U.MethodDescription, dashboard label, source link, or boundary wording that made the overread plausible.
7. Proceed only inside the recovered scope and window.
8. Block only the work claim or reliance claim that lacks source relation.

#Repair assignment rule

Broken-source repair assignment. If the required governing source is unavailable to the acting user, assign only prospective repair work, request work, decision work, work-plan work, or source-gap work to the role assignment accountable for the missing source relation. The acting user records the blocked work claim or reliance claim, the missing source relation, and the safe narrowed move now.

Source-candidate kind check. First name the kind of the encountered source candidate: actual U.Episteme, actual U.EpistemePublication, publication form, MVPK face, publication carrier, rendering, PublicationUnit, dashboard tile, credential view, generated wording, copied wording, or source-finding cue. If the source candidate exposes the governing source, use that exposed source directly. If only the display face, publication carrier, wording, or cue is named, the A.15.4 disposition is orientation, source-finding, bounded reversible probe, source-repair request, or blocked unsupported reliance until the source relation named by value is recovered.

Pressure guard. Release pressure, delegated pressure, compliance pressure, color, salience, copied wording, or generated wording does not replace the source relation named by value. A dashboard tile may guide release only as a current view of the relevant GateDecision plus evidence path, currentness path, scope, and window.

#Governing-source lookup table

Governing sources by required claim or effect kind:

• cue-only orientation: use only for attention, learning, source-finding, or a reversible local probe trigger; stay with A.16, A.16.1, or A.6.A when those claims are being made.
• issuing, approval, authorization, delegation, or revocation act: cite A.2.9 U.SpeechAct or SpeechActRef, including act type, actor and role assignment if claimed, affected work target or claim, judgement context, window, publication-carrier reference, evidence reference when currentness matters, and instituted effects if claimed. Because U.SpeechAct <: U.Work, it can evidence only that communicative act.
• deontic permission, obligation, prohibition, or recommendation-as-duty: cite A.2.8 U.Commitment and the instituting SpeechActRef when provenance matters. If the word instead names claimed use boundary, gate passage, authorization act, role-assignment effect, status effect, credential status, cue, or advice, use the pattern that carries that kind named by value.
• role-assignment or status reliance: cite A.2.1, U.RoleAssignment, a status-changing U.SpeechAct, a governing context-state record, a credential proof or status result under A.10, or an A.21 GateDecision when the status is gate-governed.
• boundary, policy, API, schema, "allowed", "authorized", "approved", "recommended", or "guaranteed" wording: split the statement through A.6 or A.6.B; use A.6.C, A.2.3, A.2.8, and A.2.9 for agreement-like guarantee, SLA, or promise wording before work use or reliance use.
• gate decision or gate passage: cite A.21 OperationalGate(profile), GateDecision, GateDecisionRationale, DecisionLogRef, gate profile, gate version, check set, scope, window, and replay or freshness pins.
• U.Flow.ConstraintValidity witness: cite A.20 ConstraintValidity status, witness, GateCheckRef.aspect = ConstraintValidity, PathId or PathSliceId when applicable, window, sentinel, and pins when those fields are needed for the claim.
• release, deployment, repair, inspection, or rollback work occurrence: cite A.15.1 dated U.Work occurrence and the A.10 evidence or provenance relation when reliance on occurrence is needed.
• evidence, provenance, authenticity, currentness, copied-source, or generated-source relation: apply A.10 and name the claim-bound evidence path, currentness path, and relation-governed or blocked use.
• assurance, readiness, safety, compliance, trust, release confidence, or R, F, G, or CL increase: apply B.3 and name the typed assurance claim plus its limitations and reopen condition.
• generated explanation: use E.17.EFP for explanation faithfulness or source-finding relation, then require A.10 claim-bound source relation for every operative claim that will be relied on.
• ambiguous approval, permission, or authorization wording: choose among the rows above named by value by asking what effect is claimed now: speech act, commitment, claimed use boundary, gate passage, role-assignment or status change, credential status, evidence relation, assurance claim, or work occurrence.

Recovered source outputs for A.15.4 closure:

High-impact work or reliance - especially external-impact, irreversible, release-bearing, role-assignment-bearing, status-claim-bearing, gate-bearing, compliance-bearing, safety-bearing, delegated, contested, or assurance-bearing claim or effect - may guide work only for the actor and role assignment, work or reliance claim under repair, work-relevant P2W claim under repair, P2W chain position under repair, affected work target or claim, audience, scope, environment, version, policy context, operational mode, and time window for which the required FPF-governed project source, relation, evidence path, gate decision, or assurance claim is recoverable. Cue-only, source-finding, learning, and bounded reversible probes stay lightweight and do not require a full source dossier. Quick dispositions:

#Worked dashboard and approval examples

Worked dashboard and approval slice:

A release dashboard shows a green approval-looking tile for Release-2026.05.08-prod. If the tile is a current view of the relevant GateDecisionRef plus evidence path and currentness path, it may carry bounded gate-passage reliance for that release scope and window. A claim that deployment happened still requires an A.15.1 work-occurrence source. If the gate source is missing or stale, treat the tile as orientation and source-finding until the team can name the release-work claim under repair, release-work position under repair, governing pattern for the claim or effect, and governing source for the gate decision, evidence path, and currentness path.

Approval memo green-tile case:

An approval memo may carry an approval claim when it exposes the A.2.9 SpeechActRef, actor and role assignment if claimed, affected release scope or work target, judgement context, time, window, publication-carrier refs, evidence refs, and instituted effect being claimed. That carries the bounded approval claim or effect only. It does not prove that release, deployment, rollback, or other work occurred; that performed-work claim still needs the dated A.15.1 work-occurrence source plus any A.10 evidence path required for the relying context.

Credential and status green-tile case:

A credential or status response may carry holder reliance, status reliance, or currentness reliance only inside the issuer or governing status register, holder binding or subject binding, verifier context, relying context, proof result or status result, revocation source or revocation record, freshness field, and effective window that it exposes. It does not by itself carry release, work occurrence, gate passage, engineering justification, evidence for underlying operational facts, or contextual permission; those uses require the governing source for the claim or effect.

Situation viewpoint prompts:

Search cues for A.15.4 include: approval, approval-looking display, authorization, authorization-looking display, permission, permission display, allowed wording, green dashboard, release tile, release readiness, model card, datasheet, data card, provenance, provenance mark, attestation, attestation label, credential, credential badge, generated explanation, copied review, copied approval, review summary, compliance-looking mark, delegation, delegation display, revocation, revocation status, gate passed, gate passage, rollback successful, rollback cue, and assurance label. These are retrieval cues only; decide the governing source and governing pattern or source relation from the work or reliance question under repair, not from the displayed word, publication-carrier name, or source name.

Work and reliance disposition table for authority-looking cases:

Display guidance for bounded status: a visible status meant to guide work should expose source type, reference or link named by value, freshness, window, scope, unsupported work claim, unsupported reliance claim, and unsupported effect. For example, prefer Gate check passed; GateDecisionRef; release scope; environment; window; not compliance proof, rollback success, or assurance increase over a bare approval-looking label.

Incident-learning fields for authority-looking overread: encountered episteme or episteme publication, work or reliance claim under repair, work-relevant P2W claim under repair, or P2W chain position under repair, governing pattern and governing source for the claim or effect, actor and role assignment, affected work target or claim, context, window, missing or stale source U.Episteme, source U.EpistemePublication, register entry, or governing source; governing FPF relation or role assignment accountable for exposing or repairing that missing source, plausible overread, safe disposition used now, and upstream repair work for the source, dashboard, explanation, credential view, boundary wording, publication face, or publication carrier.

Contestability and redress relation: when an authority-looking case affects person or team status, access, assignment, responsibility, release blockage, compliance claim, or safety-impacting work, name the review relation or redress relation before the work claim or reliance claim hardens. The relation should name the disputed source or claim, the role assignment accountable for refreshing or correcting that source, the evidence relation or status-currentness relation to reopen, the safe interim disposition, and the time and window for review.

Lintable overread cues:

Stress cases for practice:

#High-impact source-restoration slice

A lab manager sees a green tile for CRISPR-guide-G42 ready and a copied message saying the edit is approved. A.15.4 does not ask the manager to decide whether the tile is a good UI. It asks what work or reliance claim is about to be made.

SourceRestorationNote:
  EncounteredSourceCandidate: green guide-readiness tile plus copied approval-looking message
  WorkOrRelianceClaimUnderRepair: proceed with the planned gene-editing work for sample batch B-17
  ClaimOrEffectNeeded: authorization for intervention, current protocol, role-assignment source, evidence path, and lab work plan
  GoverningSourceNeeded: current protocol publication; approval record or gate record when required; role assignment; A.10 evidence relation and currentness relation; A.15.2 work plan
  RelationGovernedMoveNow: source-finding and source refresh; no intervention until the needed sources are named
  BlockedOverread: tile color and copied message do not authorize biological work or prove safety
  StopOrReopenCondition: reopen when the protocol, approval source or gate source, evidence path, role assignment, and work plan are current for batch B-17

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

• Appearance as source relation. A dashboard tile, credential display, copied approval, generated explanation, provenance label, command-like cue, or composed source chain is used as if presentation itself carried the work-relevant source relation. First name the work or reliance claim under repair, work-relevant P2W claim under repair, or P2W chain position under repair, then recover the governing pattern and governing source for the requested claim or effect. If that source is missing, lower only the unsupported reliance.

#Consequences

#Rationale

A.15.4 exists because work often meets sources through displays, publication faces, generated explanations, copied statements, credential views, dashboard tiles, schema wording, API wording, or composed source chains before the governing source is visible. The pattern protects work momentum and source recoverability together: it lets the practitioner use the encountered source candidate for orientation or bounded source-finding, while preventing the source candidate from becoming approval, evidence, assurance, gate passage, performed work, release permission, role-assignment currentness, or status currentness by appearance.

The pattern is deliberately a restoration relation, not a new authority source. Once the evidence, gate, assurance, speech-act, commitment, role-assignment, status, work-occurrence, publication, or boundary claim named by value is recovered, the pattern that governs that claim carries it directly.

#SoTA Alignment

SoTA alignment rule. Interpret each row here as source idea -> local FPF invariant -> practical local test -> popular shortcut rejected. A source citation governs nothing by reputation; it counts only when the cited idea is translated into the Solution, conformance checks, boundary rules, worked slices, and relations of this pattern.

Digital-identity and provenance boundary. The W3C Verifiable Credentials, C2PA, SLSA, in-toto, Cedar-style, Zanzibar-style, NIST, and ITIL sources are used for currentness, status, provenance, authorization-source fields, and change-practice fields. They do not turn a visible credential, provenance label, attestation, policy response, register excerpt, or dashboard display into work occurrence, gate passage, permission, assurance, release, or project claim relation without the governing source required by A.15.4, A.15, A.10, B.3, A.20, or A.21.

The nearest recovery references are the worked dashboard and approval examples, CC-A15.4-1, CC-A15.4-2, A.10, B.3, A.20, A.21, A.2.8, A.2.9, and A.15.1. If a SoTA row cannot be recovered through those local checks, do not let the source citation stand in for the local A.15.4 rule.

#Relations

• Cluster relation: A.15.4 is a cluster member under A.15 for work-relevant source restoration; it does not replace the A.15 role, method, plan, and work kernel.
• Uses: E.17, E.17:5.1b, E.17:5.1c, and E.17:5.1d for source-relation, use-boundary, and neighboring-pattern publication-use vocabulary, E.17.EFP for generated-explanation faithfulness and source-finding, A.16.0 for source-transfer and publication discipline, A.6, A.6.B, and A.6.C for boundary, policy, API, and schema wording, A.10 for evidence, currentness, provenance, and credential status, B.3 for engineering justification claims, A.20 for U.Flow.ConstraintValidity, A.21 for gate decisions, A.2.1 for role-assignment or context-state relations when they carry the source claim, A.2.8 for commitments, A.2.9 for speech acts, and A.15.1 for dated U.Work occurrences.
• E.10.ARCH relation-selection rule: When E.10 encounters source-relation, authority, permission, approval, role, status, green-tile, generated-explanation, copied-review, credential, provenance, or dashboard wording that is about to guide work or reliance, E.10.ARCH selects A.15.4 only after excluding or assigning direct evidence (A.10), assurance (B.3), gate (A.21), constraint (A.20), boundary or use-boundary wording (A.6 and A.6.B), role-assignment or context-state relation (A.2.1), speech act (A.2.9), commitment (A.2.8), work occurrence (A.15.1), and publication-face, publication-use, source-transfer, or explanation questions (E.17, A.16.0, and E.17.EFP). A.15.4 records the work-relevant source-restoration relation named by value; it does not replace those governing patterns.
• A.15 boundary relation: use A.15 directly when the remaining question under repair is role, method, plan, and work alignment rather than source restoration.

#C.29 mathematical-lens use relation

If a mathematical lens appears in work-relevant source restoration, use C.29 only to state why the lens helps expose or bound an encountered source candidate such as generated wording, dashboard cue, copied phrase, publication form, MVPK face, publication carrier, rendering, PublicationUnit, or source-finding cue. A.15.4 still governs the source candidate, source relation named by value, restoration or reopen condition, reliance relation, and whether that candidate can guide work under a recovered source relation. Method choice, plans, and performed work remain governed by A.15 and A.15.1 when those claims are being made; a C.29 lens-use result does not turn a cue, rendering, or diagnostic phrase into source relation.

#P2W Result-Related Source Boundary

When a P2W use under E.18.1 produces result wording, use this pattern only when an encountered source candidate such as publication, dashboard, generated explanation, copied statement, provenance mark, schema wording, API wording, or composed source chain is about to justify a work-result or reliance claim by appearance. No generic WorkResult kind is admitted.

Recover the governing source before relying on any result-related cue: result artifact, resource ledger, launch-values-bound record, substitution record, telemetry, acceptance record, quality-evaluation record, done-state update, feedback pin, result measurement, evidence path, assurance claim, parity relation, refresh relation, or role-assignment enactability claim. If the governing pattern or relation is missing, use the encountered source candidate only for orientation or source-finding and block only the unsupported result or reliance claim.

#Lowering, Repair, and Refresh Conditions

Lower an A.15.4 use when the work or reliance claim under repair, work-relevant P2W claim under repair, P2W chain position under repair, governing pattern, governing source, relying context, time window, source-currentness relation, revocation relation, evidence path, gate decision, assurance claim, speech-act ref, commitment, role assignment, status record, or work-occurrence source cannot be named for the intended use. The lowered use is orientation, source-finding, contested use, bounded reversible probe, source-repair request, or blocked unsupported claim.

Repair the source-restoration note when source currentness, revocation, source order, governing decision source, evidence path, copied-source relation, generated-source relation, dashboard publication, credential view, status register, boundary wording, or work-result cue changes. Repair the governing source through the evidence, assurance, gate, constraint, speech-act, commitment, role-assignment, status, work-occurrence, publication, or boundary-wording pattern governing the recovered claim when that recovered claim belongs outside A.15.4.

Refresh before allowing the encountered source candidate to guide release, safety, compliance, delegated role-assignment or status, contested source, cross-context reuse, work-result reliance, external-impact reliance, or irreversible work. Stop the refresh at the smallest changed source-restoration value: encountered source candidate, source episteme, source publication, governing source, source-currentness relation, status or revocation record, gate relation, evidence relation, assurance relation, copied-source relation, generated-source relation, or work-governed relation.

#A.15.4:End

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