FPF Reference

    Core stress-case rule

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

    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 note. Use the opening sentence or six-line note and stop after the first missing prerequisite. Do not build a full evidence, currentness, or provenance dossier for that case.

    For several prerequisites, a high-impact use, audit, handoff, or later reliance, expand that note with RequiredPositionEntries, AllowedUseNow, AppearanceOverreadBlocked, and 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 A.15.4 check asks whether every direct object required by the attempted use resolves and meets the posture and currentness predicates defined for that object, not merely whether a project-side reference is named or the reliance appearance is impressive, fluent, easy to inspect, or visually salient.

    Conditional structured field set. Use the fuller fields below only for several independent prerequisites, later handoff or audit, or release-, safety-, compliance-, gate-, or other high-impact reliance. Also use them when an exact prerequisite's own rule requires assignment identity, assignment state, credential status, assurance, currentness, revocation, or cross-context detail. Select the depth from the attempted use and those direct prerequisites. The fields are worksheet aids or C.2.1 ClaimGraph content when persisted, not a record kind.

    FieldWorking question
    acting or affected systemWhich admitted System would perform the Work, rely on the appearance, or be affected by the claim? A system-role kind, system-role assignment, credential status, and assignment-state relation are not the acting system.
    system-role-assignment claimWhich assignment occurrence is being claimed, and which U.SystemRoleAssignment species declares it? A context field ending in ...SystemRoleAssignmentRef is typed by U.RelationRef constrained to U.SystemRoleAssignment and resolves the occurrence. Keep capability, authority, responsibility, and Work attribution in their own rows.
    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 its required relation or result before the reliance appearance guides it.
    affected resource or claimWhich resource, claim, gate, credential, credential-status, system-role-assignment-state relation or assertion, evidence, approval, or source-finding pointer with an authority 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 applies to 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 required referenceWhich issuer, project reference, register entry, source-currentness or credential-status record, speech act, gate decision, evidence relation, or work-occurrence record is required for the current use, and where is its criterion defined?
    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, required 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 test its exact predicate and subject assertion; permission or authority uses the single branch there. Use A.15.4 only when SubjectPatternLocator and the project-side reference must still be recovered before a system-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 relation or result would make that use admissible, and which project-side reference and test are required?

    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 supports 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 FPF rule or result.

    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 each required relation or result and its project-side reference; keep the selected U.Episteme, exact EpistemePublicationRelation occurrence when availability is material, publication form, MVPK face, publication carrier, rendering, and source-finding cue distinct; 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 required relation or result, follow its typed ref and apply the criterion defined for it, including obtaining, result posture, currentness, scope, and evidence for this attempted use. Cite the exact defining or constraining ClaimGraph only when rule identity or edition changes the use or reliance; 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 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 after prerequisite recovery:

    Work or reliance dispositionUse whenMinimum useful result
    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.Use the opening ordinary sentence or six-line note. Name the first missing direct object in plain language; add no RequiredPositionEntries row unless a structured-use condition applies.
    Routine reliance noteThe team needs ordinary bounded reliance without release, safety, compliance, delegated system-role-assignment claim, assignment-state claim, credential-status claim, contested source relation, or cross-context reuse.For one prerequisite, use the opening ordinary result. If several prerequisites are independently required, add one typed row for each. Name the acting or affected System, target, situation, window, assignment occurrence, capability, authority, or responsibility only when this attempted use relies on that value; each stronger relation must obtain independently or return its exact missing governor.
    High-impact reliance dispositionThe attempted use is external-impact, irreversible, release-bearing, gate-bearing, compliance-bearing, safety-bearing, delegated, revoked, system-role-assignment-state-claim-bearing, credential-status-claim-bearing, generated-source-mediated, copied-source-mediated, provenance-mediated, contested, or cross-context; or one typed prerequisite row triggers high-impact conditions defined for that prerequisite.Use the additional 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 the whole catalogue here.

    For a structured use, add only the rows and fields that the attempted use actually needs:

    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 encountered object or relation kind without granting authority by appearance: selected U.Episteme, exact EpistemePublicationRelation occurrence or reference, 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 claim content in one exact U.WorkPlan; performed work becomes U.Work only after its exact actual performer is recovered through A.13 and the dated occurrence is independently admitted through 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, result with a pattern-defined criterion, gate decision, assignment, evidence/currentness relation, plan, or other prerequisite. Each row names its SubjectPatternLocator, exact DirectObjectKind, native typed ProjectSideObjectRef, RequiredPostureOrCurrentness, and DependencyOnAttemptedUse. The locator must identify the pattern whose content defines, constrains, or tests that direct object; 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 criterion defined for it, is current, covers the attempted use, and has any evidence-use, source-currentness, or other source relation required by 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 E.24.PUB distinctions rather than minting a new generic U.* kind. The claim-bearing FPF kind here is U.Episteme. When availability of its selected edition matters, name the exact EpistemePublicationRelation occurrence or reference. Publication forms, MVPK faces, publication carriers, renderings, PublicationUnit instances, and source-finding cues are separate kinds or relation positions in the case; no publication-kind shortcut replaces them. A planned baseline remains one exact U.WorkPlan episteme; any A.15.3 planned-filling rows remain declaration-local ClaimGraph content inside it. 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 matters.

    When a required relation or result, its project-side reference, or its test is incomplete, choose one 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 selected source U.Episteme for the current claim, the exact EpistemePublicationRelation occurrence when availability is the issue, the source-bearing relation, register entry, direct record, or direct relation; or refresh source-currentness, credential-status, system-role-assignment-state, context-state, or another currentness relation.
    3. Narrow the acting or affected System, an exact context field ending in ...SystemRoleAssignmentRef when assignment identity is 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. Check capability through A.2.2, Work attribution through F.6, and authority or responsibility through its separately admitted direct predicate or exact missing governor.
    4. Run a bounded reversible probe under an explicit U.WorkPlan when no external-impact reliance is being made.
    5. Separate finding or exposing the missing source from assigning its repair. For source finding, ask an identified issuer, maintainer, verifier, holder, publisher, source contact, or acting user to expose the source or record on the strength of the direct source, publication, register, communication, access, or contact fact already available; this request neither assigns Work nor implies responsibility. Assign prospective repair Work, or say who must repair, only when an applicable allocation, responsibility, commitment, permission, or authority relation selects the System. Without that stronger relation, return the exact A.6.RCD missing governor for the repair assignment while keeping the cheap information request available. Keep every 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-09-03 — upstream FPF commit b999972c (github.com/ailev/FPF)