FPF Reference

    Core stress-case rule

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

    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 local repair record. In ordinary use, do not build a full evidence, currentness, or provenance dossier. The first useful record is:

    RelianceAppearanceRef; RelianceAppearanceKind; WorkOrRelianceUseKind; WorkOrRelianceUseRef; RequiredPositionEntries; AllowedUseNow; AppearanceOverreadBlocked; RecoveryOrStopCondition

    The reliance appearance may be a tile, credential view, approval-looking memo, generated explanation, copied review, provenance mark, API wording, functional-description publication, or composed source-relation chain. The pattern asks whether every direct object required by the attempted use resolves and meets its owner-defined posture and currentness conditions, not merely whether a project-side reference is named or the reliance appearance is impressive, fluent, easy to inspect, or visually salient.

    Conditional governing pattern and position field set. Use the fuller fields below only when the attempted use is release-, safety-, compliance-, gate-, or other high-impact reliance, or when any RequiredPositionEntries row identifies role assignment, credential status, role state, assurance, contested/external/cross-context reliance, currentness, revocation, generated or copied source relation, or another prerequisite whose owner requires those details. Select the depth from the attempted use and typed rows, not from a parallel claim/effect field. These fields are local repair aids, not a new record kind.

    FieldWorking question
    subject or actorWho or what would perform the work, rely on the appearance, hold the credential-status or role-state, or be affected by the claim?
    role-assignment claimWhich U.RoleAssignment or role-context claim is being made?
    intended work or work targetIs the user planning intended work, relying on a dated U.Work occurrence or result, or making another reliance claim? Name that branch and the governing pattern before the reliance appearance guides it.
    affected resource or claimWhich resource, claim, gate, credential, credential-status, role-state, evidence, approval, or source-finding pointer with authority-reference relation is supposedly affected?
    contextWhich bounded context, environment, project slice, API setting, connector setting, protocol setting, or relying situation makes the claim applicable?
    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 recovered-use boundary claimed to hold?
    currentness or revocation fieldIs the source relation current, stale, revoked, superseded, expired, contradicted, or unknown?
    issuer or governing referenceWhich issuer, project reference, register entry, source-currentness or credential-status record, speech act, gate decision, evidence relation, or work-occurrence record is required by the governing pattern for the current use?
    verifier or relying contextWho is checking or relying on the claim, and in which context?
    evidence or attestation relationWhich A.10 evidence, provenance, or attestation relation, 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-use class applies to the reliance appearance and required claim or use?
    unsupported effectWhich requested work claim, reliance claim, governing value, or downstream effect remains unsupported and needs narrowing, repair, reopening, probing, or blocking?

    Start with the A.15.4 first repair checks above when the reliance appearance is being used as a reason for intended work, reliance, or a work-relevant claim. If the direct question is already known, use the §3 lookup and go straight to its owner; permission or authority uses the single branch there. Use A.15.4 only when the governing pattern position and project-side reference must still be recovered before role assignment, method, plan, work, work result, result measurement, or another work or reliance claim can proceed.

    When a reliance appearance seems to authorize work or reliance. Use A.15.4 when a publication, display, credential view, wording, or explanation looks like permission, prohibition, readiness, or evidence for intended work or reliance. This is a recognition moment, not a new kind. The repair question remains: what does the user intend to do next, what claim or effect would make that intended work or reliance admissible, and which governing pattern position and project-side reference are required for it?

    Here "authority-looking case" is only a recognition phrase for the encountered situation. The record, relation, slot filler, or project-side reference that authorizes, forbids, records, or carries the required relation is named by value under its FPF pattern. Use E.17:5.1c for the shared meanings of orientation use, reliance use, 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 governing pattern position and project-side reference that carry the required claim, effect, work occurrence, or currentness value; keep the U.Episteme or U.EpistemePublication distinct from publication form, MVPK face, publication carrier, rendering, and source-finding cue; choose the minimum sufficient recovered use; and do not raise the claim beyond the recovered relation, source relation, or recovered use boundary. If a project record names a governing relation, follow its typed ref to the direct owner and test obtaining, required result posture, currentness, scope, and evidence for this attempted use; the record's statement does not make the relation obtain.

    Positive repaired disposition. First name the attempted use and open each prerequisite through its typed ref. The appearance may guide that use beyond orientation only after every referenced relation actually obtains or result passes its owner-defined criterion, is current, covers this beneficiary/action/target/scope/window, and has the evidence or source relation required for this reliance. When a relevant permission/norm conflict exists, its separate finding row must be current and settled for this use; an unresolved or norm-selecting disposition blocks the use without rewriting grant currentness. Then write what may happen next. The first failed row keeps only that unsupported work or reliance use blocked.

    Reliance dispositions by recovered governing pattern relation:

    Work or reliance dispositionUse whenMinimum useful record
    Orientation or source-finding noteThe reliance appearance is only a publication face, publication carrier, rendering, cue, retrieval cue, learning aid, or reversible local probe trigger.Name the appearance and exact attempted use, then add one RequiredPositionEntries row for the first missing direct object. Keep AllowedUseNow, the blocked overread, and the recovery or stop condition explicit.
    Routine reliance noteThe team needs ordinary bounded reliance without release, safety, compliance, delegated role-assignment claim, role-state claim, credential-status claim, contested source relation, or cross-context reuse.Name the work or reliance use and only the RequiredPositionEntries rows it actually depends on, plus acting holder, work-performing system, or agent when current; RoleAssignmentRef when role-conditioned authority or work attribution is current; affected target, context, effective window; AllowedUseNow; and reopen trigger.
    High-impact reliance dispositionThe attempted use is external-impact, irreversible, release-bearing, gate-bearing, compliance-bearing, safety-bearing, delegated, revoked, role-state-claim-bearing, credential-status-claim-bearing, generated-source-mediated, copied-source-mediated, provenance-mediated, contested, or cross-context; or one typed prerequisite row has that owner's high-impact conditions.Use the governing fields required by the attempted use and those exact RequiredPositionEntries rows. When permission or authority is current, choose exactly one row in the §3 branch rather than copying its owner catalogue here.

    A small A.15.4 local repair record is enough for the first disposition:

    FieldValue
    RelianceAppearanceRefName the appearance being relied on by value, such as the dashboard tile, credential view, copied text, generated explanation, publication face, publication carrier, rendering, or source-finding cue.
    RelianceAppearanceKindName the kind without granting authority by appearance: 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.
    WorkOrRelianceUseKind and WorkOrRelianceUseRefName the use being justified by value: intended work, reliance on a claim, reliance on a dated U.Work occurrence, method-family selection, selected method, method of work, work plan, planned work, work result, result measurement, release reliance decision, non-work reliance claim, work-relevant P2W claim, or P2W chain position. A planned baseline remains a U.WorkPlan or U.WorkPlanning plan record; performed work becomes U.Work only after it occurs and is recorded under A.15.1; work-result measurement belongs with the evidence relation or result-measurement record that carries it.
    RequiredPositionEntriesThis is the sole prerequisite set. Add one row per independent direct object, whether it is a claim, instituted effect, relation occurrence, owner-defined result, gate decision, assignment, evidence/currentness relation, plan, or other prerequisite. Each row names its DirectOwnerPatternRef, exact DirectObjectKind, native typed ProjectSideObjectRef, RequiredPostureOrCurrentness, and DependencyOnAttemptedUse. Never store several patterns, kinds, or refs as comma-separated prose, and never coerce the refs into one generic U.EntityRef list.
    AllowedUseNowState the safe current use. proceed-inside-recovered-relation is allowed only after every required entry passes its RequiredPostureOrCurrentness and exact-use match; otherwise retain orientation, source-finding, bounded probe, repair request, narrowed reliance, or blocked unsupported use.
    AppearanceOverreadBlockedState the overread being blocked, such as treating display color as gate passage, copied approval as a current speech act, a credential screenshot as permission, or a generated explanation as evidence.
    RecoveryOrStopConditionWrite the first row that fails and the observation that would make it pass. Reopen only after following every typed ref and verifying that its relation obtains or its result passes the owner-defined criterion, is current, covers the attempted use, and has the evidence/source support required for this reliance. Include separately required current conflict-finding, gate, and work-entry-readiness rows; an unresolved conflict row blocks the affected use without changing grant currentness.

    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 governing pattern position is incomplete, choose one relation-governed A.15.4 disposition after naming the work or reliance use and the exact direct objects it requires in RequiredPositionEntries; pick the lightest disposition that preserves practical work and recoverability:

    1. Use the reliance appearance only for orientation or source-finding.
    2. Reopen the source U.Episteme for the current claim, the U.EpistemePublication that exposes the claim-bound source relation, register entry, governing record, or governing relation, or refresh source-currentness, credential-status, role-state, context-state, or another currentness relation.
    3. Narrow the acting holder, work-performing system, agent, RoleAssignmentRef when current, requested operation or work class, affected work target, affected resource, affected claim, context, and effective window until the recovered record or relation really covers the recovered use.
    4. Run a bounded reversible probe under an explicit U.WorkPlan when no external-impact reliance is being made.
    5. Ask the holder, work-performing system, maintainer, verifier, issuer, or project role holder identified by the relevant RoleAssignmentRef or governing relation to expose or repair the missing direct object named in that RequiredPositionEntries row. Keep any additional missing gate, evidence, assignment, state, currentness, or boundary object in its own row.
    6. Repair the U.WorkPlan, U.MethodDescription, dashboard label, source-relation 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 the required relation.

    Last Updated: 2026-07-28 — upstream FPF commit 17edd955 (github.com/ailev/FPF)