#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-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.

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative

At a glance. This A.15 cluster member tells an engineer-manager which exact project source must be recovered before an encountered episteme/publication item, display, credential view, generated explanation, copied statement, provenance mark, dashboard tile, schema/API wording, or composed source chain may support a work/reliance claim/effect.

Use this when. Use this pattern when a visible item is about to guide a work/reliance move or a work-relevant P2W claim/effect by appearance, and the acting user must recover the exact project source record before proceeding.

First output. One compact restoration note: encountered item, live work/reliance claim or P2W load/position, exact source needed, admissible next project move now, and blocked overread.

What goes wrong if missed. Teams treat a visible dashboard, credential view, copied approval, generated explanation, provenance mark, schema/API wording, or other publication/display/cue as if it already carried approval, permission, gate passage, evidence, engineering justification, performed work, release permission, or role/status support. Work then proceeds or stops on appearance while the project source that actually governs the claim/effect is missing, stale, revoked, or contradicted.

Governed object in plain terms. One source-restoration relation for one live work/reliance claim or P2W load/position: encountered item, exact project claim/effect governing locus, project source record needed, admissible next project move now, and blocked overread. It is not a new authority source, evidence source, gate record, engineering justification object, work occurrence, or generic publication kind.

Governing move in plain terms. Recover or name the exact FPF/project source relation before allowing the encountered item to guide work or reliance. When that source is absent or insufficient, narrow the move, reopen or refresh the source, run only a bounded reversible probe under a work plan, or block the unsupported claim/effect.

Recognition block vs assurance block. Read At a glance, Use this when, First output, What goes wrong if missed, Governed object, Governing move, Working action path, Not this pattern when, and What this buys as the primary recognition block. Read the field tables, lookup table, lint cues, stress cases, conformance checklist, SoTA alignment, and relations below as assurance/support blocks that tighten the same source-restoration claim; they do not widen this pattern into an evidence, gate, engineering-justification, speech-act, commitment, boundary, or work-occurrence pattern.

Working action path.

1. Name the encountered item locus without treating its appearance as source support.
2. Name the live work/reliance claim or P2W load/position and the exact project claim/effect governing locus.
3. Recover the exact project source record or neighboring FPF locus that carries that claim/effect.
4. Choose the lightest admissible project move now: proceed inside recovered support, narrow the move, run a bounded reversible probe under U.WorkPlan, reopen/refresh the source, ask the accountable role assignment to expose or repair the missing source, or block only the unsupported claim/effect.
5. Return to A.15 only when the remaining live question is role/method/plan/work separation.

Not this pattern when. Stay in A.15 when the live problem is only role/method/plan/work separation. Stay in E.17 when the live problem 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/constraint validity, commitment/speech act, boundary claim, or work occurrence already governs the live claim/effect directly.

What this buys. The acting engineer-manager can keep work moving at the lightest admissible level: proceed inside recovered support, narrow the move, run a bounded reversible probe under a work plan, reopen the needed project source, ask the role assignment accountable for that source to expose or repair it, or block only the unsupported claim/effect while preserving weaker admissible use.

Dashboards, credential views, generated explanations, copied approvals, provenance labels, green tiles, schema/API wording, and composed source chains often look ready for action before the project source that makes the action or reliance admissible has been recovered. The practical problem is not to classify the item in FPF; the problem is to decide what an engineer-manager may do in the project now without turning appearance into approval, gate passage, evidence, assurance, performed work, or release permission.

#Keywords

• work-relevant source restoration
• dashboard display
• credential view
• generated explanation
• copied statement
• provenance mark
• required project source
• 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/API wording, and composed source chains often look ready for action before the project source that makes the action or reliance admissible has been recovered. The practical problem is not to classify the item in FPF; the problem is to decide what an engineer-manager may do in the project now without turning appearance into approval, gate passage, evidence, assurance, performed work, or release permission.

#Cluster Boundary

A.15 remains the kernel for separating U.Role, holder/context, U.Method, U.MethodDescription, U.WorkPlan, and actual U.Work. A.15.4 starts only when an encountered item begins to support a work/reliance claim/effect and the team must recover the exact project source record that carries that support. If the exact source is already known, use that source pattern 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:

encountered item / live work-or-reliance claim / exact source needed / admissible next project move now / blocked overread

The encountered item 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 exact work/reliance claim is currently supported, not whether the item is impressive, fluent, or easy to read.

Conditional source-support field set. Use the fuller fields below only when release, safety, compliance, role/status, gate, assurance, contested source, external reliance, cross-context reuse, currentness/revocation, or generated/copied source support is live. These fields are local restoration aids, not a new record kind.

Start with the A.15.4 working action path above when the encountered item is about to guide a work/reliance move or a work-relevant claim/effect. If the live issue is only evidence/currentness, gate/constraint, engineering justification, commitment/speech act, boundary/admissibility wording, credential/status proof, explanation, comparison, or carrier/front-end behavior, apply that exact governing pattern or project source relation directly; use A.15.4 only when that source must be restored before role, method, plan, work, work result, result measurement, or another work/reliance move can proceed.

Authority-looking source-backed work/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 basis, release/reliance basis, execution-evidence basis, approval claim/effect basis, role/status claim/effect basis, 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 governed question is still the live work/reliance claim or P2W load/position plus the exact project claim/effect governing locus being read from, or through, the wording, display, publication face, carrier, or source-finding cue. It is not the wording alone. A.15.4 does not change the governed object of A.15; it governs only the source-restoration step before the encountered case can support work or reliance.

Here "authority-looking case" is only a recognition phrase for the encountered situation; it is not a U.* kind, not a profile, not a score, and not a new evidence source, governing pattern, or authority source. The source-backed object that permits, forbids, records, or supports the work may instead be a GateDecision, SpeechAct, Commitment, RoleAssignment, credential/status record, A.6.B-governed claim, A.10 evidence path, or B.3 assurance claim. Use E.17:5.1c for the shared meanings of orientation use, reliance use, work/reliance claim/effect, operative claim, unsupported downstream use, and reopen trigger; use E.17:5.1d when the primary live question may belong to another governing pattern or project source relation.

The central behaviour is: name the live work/reliance claim or P2W load/position, name the exact project claim/effect governing locus, keep the U.Episteme or U.EpistemePublication distinct from publication form, MVPK face, carrier, rendering, and source-finding cue, choose the minimum sufficient next move, recover only the project source record needed for that move, and do not raise the claim beyond that recovered support. If the project record already states the governing source relation, use that recorded relation directly rather than inferring support from wording.

Positive repaired path. An encountered U.Episteme publication, publication form, MVPK face, carrier, rendering, or source-finding cue may guide work or reliance only to the support carried by the recovered project source record, actor/role, live work/reliance claim or P2W load/position, affected work target/context/window, and source-supported claim/effect. The repaired outcome is the smallest admissible work/reliance statement plus the unsupported work/reliance claim/effect still blocked.

Load posture by exact project claim/effect governing locus:

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

Borrowed episteme/publication discipline. A.15.4 borrows the C.2.1 / E.17 / 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, carriers/renderings, authored units, and source-finding cues are separate kinds/roles in the case. A planned baseline remains a U.WorkPlan / U.WorkPlanning plan record such as SlotFillingsPlanItem; launch values and finalization values remain their own project records, decision logs remain gate/decision records, execution evidence remains evidence, and actual work occurrences remain A.15.1 / U.Work matters.

When required project source support is incomplete, choose one admissible degraded-operation move after naming the live work/reliance claim or P2W load/position and the exact project claim/effect governing locus; pick the lightest move that preserves practical work and source recoverability:

1. Use the encountered item only for orientation or source-finding.
2. Reopen the required source record or refresh status/currentness.
3. Narrow actor or role, requested operation or work class, affected target, context, and 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/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/window.
8. Block only the work/reliance claim/effect that lacks source support.

#Repair assignment rule

Broken-source repair assignment. If the required project source record is unavailable to the acting user, assign only prospective repair/request/decision/work-plan/source-gap work to the role assignment accountable for the issuer record, gate decision, evidence path, role/status record, or boundary claim set. The acting user records the blocked work/reliance claim/effect and the missing source relation to expose or repair, then proceeds only with the safe narrowed move available under recovered support. The repair record is not past evidence, approval, gate passage, performed U.Work, release permission, or assurance.

An encountered item may be a U.Episteme, a U.EpistemePublication, a publication form, an MVPK face, a carrier/rendering, an authored unit, or only a source-finding cue. Name that kind before using it. Do not treat a file, display, dashboard tile, model card, credential view, generated text, authored unit, publication face, or carrier as the source claim/effect, work occurrence, gate decision, role/status, evidence relation, or assurance claim by presentation alone. If the encountered item exposes a typed project source record, use the exposed GateDecision, SpeechAct, evidence path, credential/status source, work-occurrence record, or other exact FPF source record directly; do not infer that support from the display face itself.

Adversarial misuse guard. Do not let release pressure, delegated pressure, compliance pressure, unsourced green-dashboard pressure, or copied/generated wording convert a cue into work/reliance support. A properly designed dashboard tile may guide release when it is a current view of the relevant GateDecision plus evidence/currentness path; pressure or color alone does not replace that source.

#Project source record lookup table

Project source records by required claim/effect kind:

• cue-only orientation: use only for attention or source-finding; stay with A.16 / A.16.1 for pre-articulation cues or A.6.A for A.6.A-governed invitation. Cue-only orientation is not work guidance, work plan, gate passage, approval, work occurrence evidence, or assurance.

• issuing, approval, authorization, delegation, or revocation act: cite A.2.9 U.SpeechAct / SpeechActRef, including act type, actor/role, affected work target or claim target, judgement context, window, carrier/evidence refs when currentness matters, and instituted effects if claimed; because U.SpeechAct <: U.Work, the same act can satisfy dated work-occurrence evidence only for that communicative act itself. It does not evidence the deployment, release, repair, inspection, or other operational work that the act approved, ordered, or described;

• role or status reliance: cite A.2.1 / U.RoleAssignment, a status-changing U.SpeechAct, a governing context-state record, a credential proof/status result under A.10, or an A.21 GateDecision when the status is gate-governed; do not infer a status kind from a label;

• deontic permission, obligation, prohibition, or recommendation-as-duty: cite U.Commitment / A.2.8 and the instituting SpeechActRef when provenance matters; if "permission" means admissibility predicate, gate passage, authorization act, role/status effect, credential status, cue, or advice, use A.6.B, A.21, A.2.9, A.2.1, A.10, A.16, or A.6.A according to the actual claim/effect kind instead;

• boundary, policy, API, schema, "allowed", "authorized", "approved", "recommended", or "guaranteed" wording: split the statement through A.6 / 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/reliance;

• gate decision or gate passage: cite A.21 OperationalGate(profile), GateDecision, GateDecisionRationale, DecisionLogRef, gate profile/version, check set, scope/window, and replay/freshness pins;

• constraint or flow-validity witness: cite A.20 ConstraintValidity status/witness, GateCheckRef.aspect = ConstraintValidity, path/window/sentinel/pins as applicable; this is not the same thing as a gate decision;

• release/deployment/rollback work occurred: cite A.15.1 dated U.Work occurrence and the A.10 evidence carrier path; a gate decision or command-like cue is not execution evidence;

• evidence, provenance, authenticity, currentness, copied-source, or generated-source support: exit to A.10; evidence support does not approve, permit, execute, pass a gate, or raise assurance by itself;

• assurance, readiness, safety, compliance, trust, release confidence, R, F, G, or CL increase: exit to B.3;

• generated explanation: use E.17.EFP for explanation faithfulness or source-finding relation, then require A.10 claim-bound source support for every operative claim that will be relied on.

• approval claim/effect split: if approval means someone approved something, cite A.2.9 U.SpeechAct / SpeechActRef; if the approval institutes a deontic binding, cite A.2.8 U.Commitment and the instituting act; if it means a gate passed, cite A.21 GateDecision / DecisionLogRef; if it is being used as evidence that release or other work occurred, cite A.15.1 dated U.Work plus A.10; if it is only approval wording in boundary, API, policy, or schema prose, split through A.6 / A.6.B; if it is evidence of approval, exit to A.10; if it is confidence because something was approved, use B.3 only when a typed assurance claim is live.

• permission claim/effect split: if permission is a deontic relation, cite A.2.8 U.Commitment and the instituting source; if it is an admissibility predicate, cite the A.6.B A-* claim; if it means gate passage, cite A.21; if it means an authorization act, cite A.2.9; if it changes or depends on role/status, cite A.2.1 or status-changing support; if it means credential status, use A.10; if it is only a UI label, badge, dashboard display, or permission-looking wording, treat it as orientation/source-finding until the required project source record is recovered.

• authorization claim/effect split: if authorization means a speech act authorizing, cite A.2.9; if it means a policy/admissibility predicate over subject, requested policy operation or work class, affected resource or work target, context, and policy version, split through A.6.B; if it means gate decision or gate passage, cite A.21; if it means access proof, credential proof, status proof, or currentness, use A.10; if it means role assignment or role/status effect, cite A.2.1 or status-changing support; if it is being used to say execution happened, do not use authorization as evidence of execution, cite A.15.1 dated U.Work plus A.10 instead.

Return products for loop closure:

Load-bearing work or reliance - especially external-impact, irreversible, release-bearing, role/status-bearing, gate-bearing, compliance/safety-bearing, delegated, contested, or assurance-bearing claim/effect - is admissible only for the actor/role, live work/reliance claim or P2W load/position, affected work target or claim target, audience, scope, environment, version, policy context, operational mode, and time/window for which required FPF-governed project support is recoverable. Cue-only, source-finding, learning, and bounded reversible probes stay lightweight and do not require a full source dossier.

Quick dispositions:

| Rollback command-like cue | Treat as cue or A.6.A-governed invitation unless exact command/authorization, work occurrence, execution result, or gate support is recoverable. | | Generated explanation says "authorized" | Explanation may help find sources; it does not issue, approve, revoke, commit, authorize, pass a gate, evidence execution, or raise assurance. A citation or source mention inside the explanation supports work/reliance only when the cited carrier supports that exact relied-on claim in the relying context under A.10. |

| Extracted-source -> rewrite -> representation shift -> explanation -> gate/release claim/effect | Reopen the strongest available project source record at the first lossy or non-commutative transform step; the gate/release claim/effect waits for required transform, evidence, explanation, gate, or assurance support. | | Repeated green-tile/no-source failures | Treat recurrence as upstream source-system repair work: expose decision refs, fix dashboard semantics, add source links/currentness, revise boundary wording, or add review/lint cues so the acting user is not repeatedly forced to reconstruct missing source support. |

#Worked dashboard/approval examples

Worked dashboard/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/currentness path, it may support bounded gate-passage reliance for that release target and window. Execution or deployment still requires an A.15.1 work-occurrence source if the claim is that deployment happened. If the gate source is missing or stale, treat the tile as orientation and source-finding until the team can name the live release-work load/position, exact project claim/effect governing locus, and project source record that carries the gate decision and evidence/currentness path.

Approval memo green path:

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

Credential/status green path:

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

Role prompts:

Work/reliance disposition map for authority-looking cases:

Display guidance for bounded status: a visible status meant to guide work should expose source type, exact ref or link, freshness/window, scope, and unsupported work/reliance/claim/effect. For example, prefer Gate check passed / GateDecisionRef / release target / 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/publication item, live work/reliance claim or P2W load/position, exact project claim/effect governing locus, actor/role, affected work target or claim target, context/window, missing or stale source record, governing source relation or role assignment accountable for the missing source record, plausible overread, safe disposition used now, and upstream repair item for the source, dashboard, explanation, credential view, boundary wording, publication face, or carrier.

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

Lintable overread cues:

Stress cases for practice:

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

• Authority-looking case as source / work/role-status overread. Do not treat a dashboard tile, credential display, copied approval, generated explanation, provenance label, command-like cue, or composed source chain as approval, permission, gate passage, role/status currentness, work occurrence, evidence, or assurance by appearance. First name the live work/reliance claim or P2W load/position and exact project claim/effect governing locus, then recover the project source record that actually carries the requested approval, permission, status, evidence, gate, assurance, or work-occurrence support, or block only that unsupported reliance.

#SoTA Alignment

SoTA alignment rule. Read the 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/provenance boundary. The W3C Verifiable Credentials, C2PA, SLSA/in-toto, Cedar/Zanzibar-style, NIST, and ITIL sources are used for currentness, status, provenance, authorization-support fields, and change-practice fields. They do not turn a visible credential, provenance label, attestation, policy response, register excerpt, or dashboard state into work occurrence, gate passage, permission, assurance, release, or project claim support without the exact project source record required by A.15.4, A.15, A.10, B.3, A.20, or A.21.

The nearest recovery anchors are the worked dashboard/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/work kernel.
• Uses: E.17:5.1b / E.17:5.1c source-support and use vocabulary, E.17.EFP for generated-explanation faithfulness/source-finding, A.6 / A.6.B / A.6.C for boundary/policy/API/schema wording, A.10 for evidence/currentness/provenance/credential status, B.3 for engineering justification claims, A.20 for constraint validity, A.21 for gate decisions, A.2.8 for commitments, A.2.9 for speech acts, and A.15.1 for dated U.Work occurrences.
• Returns to: A.15 when the remaining live question is role/method/plan/work alignment rather than source restoration.

#A.15.4:End

---

Last Updated: 2026-05-12 — this section last modified in upstream FPF commit f73766dd (github.com/ailev/FPF)