FPF Reference

    Core stress-case rule

    Preface node heading:core-stress-case-rule:21144

    What this page is

    This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

    Methodology

    Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

    Content

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

    encountered item; live work claim or reliance claim; pattern that governs the claim being made or effect; project-side FPF kind and reference named by value 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 work claim or reliance claim named by value is currently carried by a project-side FPF kind and reference named by value, not whether the item is impressive, fluent, or easy to inspect.

    Conditional source-relation 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, generated source relation, or copied source relation is live. These fields are local restoration aids, not a new record kind.

    FieldWorking question
    subject or actorWho or what would perform the work, rely on the item, hold the status, or be affected by the claim?
    roleWhich U.RoleAssignment or role-context claim is live?
    guided action or work itemWhich selected method, method of work, U.WorkPlan, planned work, actual U.Work, work result, release move, reliance move, status, or effect is being guided?
    affected resource or claimWhich resource, claim, gate, credential, status, evidence, approval, or source finding with authority-reference relation is supposedly affected?
    contextWhich bounded context, environment, project slice, interface setting, protocol setting, or relying situation makes the claim live?
    policy or gate versionWhich policy, gate profile, constraint version, method version, or register edition is supposed to govern the claim?
    time windowDuring which window is the claim, effect, source relation, or admissible-use boundary claimed to hold?
    currentness or revocation fieldIs the source relation current, stale, revoked, superseded, expired, contradicted, or unknown?
    issuer or sourceWhich issuer, project-side FPF kind and reference named by value, register source, status source, speech act, gate decision, evidence path, or work-occurrence record carries the claim, effect, source relation, or admissible-use boundary?
    verifier or relying contextWho is checking or relying on the claim, and in which context?
    evidence or attestation pathWhich A.10 evidence, provenance, or attestation path, if any, justifies the claim without itself becoming approval, gate passage, assurance, or work occurrence?
    sourceRelationClassWhich E.17:5.1b source-relation class or claim-admissibility class applies to the encountered item and required claim or use?
    unsupported effectWhich requested work claim, reliance claim, or downstream effect remains unsupported and must be narrowed, repaired, reopened, probed, or blocked?

    Start with the A.15.4 working action path above when the encountered item is about to guide a work move, reliance move, or work-relevant claim. If the issue under repair is only evidence, currentness, gate validity, constraint validity, engineering justification, commitment, speech act, boundary wording, admissibility wording, credential proof, status proof, explanation, comparison, or carrier and front-end behavior, apply the pattern that governs that issue under repair and project-side FPF kind and reference named by value directly; use A.15.4 only when that source must be restored before role, 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, execution-evidence source, approval-claim source, approval-effect source, role-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 question under repair is still the live work claim, reliance claim, work-relevant P2W claim, or P2W chain position plus the pattern that governs the claim being made or effect and project-side FPF kind and reference named by value that carry that claim or effect being inferred 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 primary EntityOfConcern of A.15; it guides only the source-restoration step before the encountered case can guide work or reliance.

    Here "authority-looking case" is only a recognition phrase for the encountered situation; it is not a U.* kind, not an assurance tuple, not a measured value, and not a new source kind or project record. The source-backed project-side kind or record that permits, forbids, records, or carries the work-relevant claim may instead be a GateDecision, SpeechAct, U.Commitment, 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 may belong to another pattern that governs the claim being made or effect with its project-side FPF kind and reference named by value.

    The central behaviour is: name the live work claim, reliance claim, work-relevant P2W claim, or P2W chain position; name the pattern that governs the claim being made or effect and project-side FPF kind and reference named by value that carry that claim or effect; 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-side FPF kind and reference named by value needed for that move; and do not raise the claim beyond that recovered relation, source, or admissible-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 path. An encountered U.Episteme publication, publication form, MVPK face, carrier, rendering, or source-finding cue may guide work or reliance only to the claim or effect carried by the recovered project-side FPF kind and reference named by value, actor or role, live work claim, reliance claim, work-relevant P2W claim, or P2W chain position, affected work item, context, window, and source-recoverable claim or effect. The repaired outcome is the smallest admissible work or reliance statement plus the unsupported work claim or reliance claim still blocked.

    Reliance disposition by pattern that governs the claim being made or effect and project-side FPF kind and reference named by value:

    Work or reliance dispositionUse whenMinimum useful record
    Orientation or source-finding noteThe encountered item is only a publication face, carrier, rendering, cue, search handle, learning aid, or reversible local probe trigger.encountered item; required claim or effect not yet carried by a recovered source; source to reopen; stop condition.
    Routine reliance noteThe team needs ordinary bounded reliance without release, safety, compliance, delegated role or status claim, contested source, or cross-context reuse.Live work claim, reliance claim, work-relevant P2W claim, or P2W chain position; required claim or effect; actor or role; affected work item, context, and window; visible source ref; and reopen condition.
    High-impact reliance pathThe required claim or effect is external-impact, irreversible, release-bearing, gate-bearing, compliance-bearing, safety-bearing, delegated, revoked, status-claim-bearing, generated-source-mediated, copied-source-mediated, provenance-mediated, contested, or cross-context.Exact project-side FPF kind and reference with the live A.10, A.6, B.3, A.2.9, A.2.8, A.21, A.20, or A.15.1 fields needed for that claim or effect.

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

    FieldValue
    live work claim, reliance claim, work-relevant P2W claim, or P2W chain positionName the live work claim, reliance claim, work-relevant P2W claim, or P2W chain position exactly: method-family selection, selected method, method of work, work plan, planned work, actual U.Work, work result, result-measurement, release reliance decision, or non-work reliance claim. A planned baseline remains a U.WorkPlan or U.WorkPlanning plan record; actual execution becomes U.Work only after it occurs and is recorded under A.15.1; work-result measurement belongs with the evidence or result-measurement source. This row is a local restoration label unless it cites an existing FPF kind or governing FPF relation.
    pattern that governs the claim being made or effect and project-side FPF kind and reference named by valueApproval, permission, gate passage, role or status currentness, work occurrence, evidence relation, assurance claim, boundary claim, or other claim named by value or effect needed before that work claim, reliance claim, or P2W chain-position claim can be treated as carried by a recovered source. The governing relation must be carried by the named FPF pattern and recovered project-side reference, not by a new A.15.4 kind.
    actor or roleWho would act or rely.
    affected work item, context, and windowRelease, service, person, role holder, work item, claim, tenant, environment, physical batch, construction element, machine state, or validity window affected by that class or claim.
    claim-bearing episteme or episteme publicationThe claim-bearing FPF kind is U.Episteme or a species such as U.EpistemePublication; if the encountered item is only a publication form, MVPK face, carrier, rendering, PublicationUnit, dashboard tile, copied text, credential view, generated explanation, API wording, or cue, name that kind named by value separately.
    project-side FPF kind and reference named by value needed or safe next moveSource U.Episteme, source U.EpistemePublication, register entry, or project-side FPF kind and reference named by value to reopen; status to refresh; reversible probe; role assignment accountable for exposing or repairing the missing source; or narrower admissible use.
    stop or reopen conditionWhat blocks the work claim or reliance claim and what would reopen it.

    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, carriers, renderings, PublicationUnit instances, and source-finding cues are separate kinds or roles 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, execution evidence remains evidence, and actual work occurrences remain A.15.1 or U.Work matters.

    When the required project-side FPF kind and reference named by value is incomplete, choose one admissible degraded-operation move after naming the live work claim, reliance claim, work-relevant P2W claim, or P2W chain position and the pattern that governs the claim being made or effect and project-side FPF kind and reference named by value that carry that claim or effect; 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 U.Episteme, source U.EpistemePublication, register entry, or project-side FPF kind and reference named by value, or refresh status or currentness.
    3. Narrow actor or role, requested operation or work class, affected work item, affected resource, affected claim, 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 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.

    Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)