FPF Reference

    Prerequisite lookup table

    Preface node heading:prerequisite-lookup-table:26351

    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

    Patterns and checks by required direct-object 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.

    Permission and authority branch — use only when that is the live claim. Do not route from approved, authorized, allowed, may, or the look of a permit. Ask what is true now and choose one row.

    Plain questionPattern and required objectWhat closes or blocks this branch
    Did an admitted system perform an approval, authorization, delegation, grant, or revocation communication?A.2.9; one SA : U.SpeechAct occurrence.Use A.13 to identify the System that actually performed the communication, then let A.15.1 admit the speech-act Work independently. If the reliance claim must also identify the assignment that covered the communication, or the policy makes that assignment material, name the assignment already used in the A.13 account and use F.6 to compare its holder with the performer. Add the context, time, act type, and evidence needed for reliance. The assignment supplies neither performerhood nor authority. A SpeechActRecord, message, or carrier is not the act, and the act alone does not make an institutional effect obtain.
    Does a policy-valid strong grant currently obtain for this beneficiary and action?A.2.8.PER; one GrantedPermissionRelation@Context occurrence.Match beneficiary, action specification, policy/context, scope/window, and instituting SpeechActRef. A valid revocation, supersession, or policy failure may prevent or end the grant. An unresolved same-case conflict can block this attempted use without making the grant cease to obtain; keep those results separate. This is the permission-side instituted effect.
    Before action, did a current frame complete enough for this use contain no applicable prohibition?A.2.8.PER; one NonProhibitionFinding@Context.Name the frame, use, beneficiary/action, scope/window, and evaluation. A stale or incomplete frame returns unresolved, not permission.
    Did dated Work actually exercise one obtaining grant?A.2.8.PER; one PermissionExerciseRelation@Context occurrence.Use A.13 to identify who actually performed the Work and A.15.1 to admit that dated occurrence before matching its action and performer to the grant's beneficiary branch. If the exercise result must also identify the assignment under which the Work was performed, check that separately through F.6 against the assignment used by A.13. No dated Work means no exercise; non-exercise is not violation.
    After Work, did a current sufficiently complete frame find no applicable violation?A.2.8.PER; one NonViolationFinding@Context.For both the acted-on Work and the evaluation Work, use A.13 to identify the actual performer and A.15.1 to admit the dated occurrence independently. If the finding must also identify an assignment for either occurrence, check that assignment separately through F.6. Then name the frame, scope/window, and result. Exercise or non-exercise alone settles nothing; a stale or incomplete frame returns unresolved.
    Do an obtaining grant and a current norm reach incompatible conclusions for the same beneficiary/action and overlapping scope/window?A.2.8.PER; one PermissionNormConflictFinding@Context.Cite the applicable precedence rule or an authorized decision. If the decision is asserted as dated Work, use A.13 to identify its actual performer and A.15.1 to admit it independently. Add F.6 only if the conflict record must also identify the assignment under which that decision Work was performed. Otherwise keep the conflict unresolved and block the affected use.
    Is an actual system or separately governed party obliged, prohibited, or given a recommendation-as-duty?A.2.8; one U.Commitment.Name the actual duty bearer, direct predicate, modality, exact referents, scope and window, applicable constitutive policy and rule, and actual instituting basis. A system-role kind or assignment may satisfy a rule antecedent but is not the duty bearer or commitment. The utterance, record, and carrier are not the commitment.

    A gate or readiness result remains an additional A.21 or A.15.5 prerequisite; it creates none of these objects. If the issue is only wording, classify it through A.6 or the single permission-word branch in A.6.B. If only a permit, badge, message, record, or tile is visible, stay at orientation or source finding until one row above passes its stated test.

    • system-role-assignment reliance: use A.2.1 and name the assignment occurrence and its declared species. Assignment-state reliance instead uses the A.2.5 SystemRoleAssignmentStateRelation; credential-status reliance uses the exact proof or status result under A.10; context-state reliance uses its applicable direct state pattern and record; and a state established by a gate decision keeps its separate A.21 GateDecision. Keep every required object in its own row.
    • boundary, policy, API, schema, "allowed", "authorized", "approved", "recommended", or "guaranteed" wording: split the statement through A.6 or A.6.B. When its live job is permission or authority, return to the branch above; the displayed word does not choose the object.
    • 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.
    • Flow constraint-validity 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 the actual performer's A.13 basis, one dated U.Work occurrence independently admitted under A.15.1, and the A.10 evidence or provenance relation when reliance on the occurrence is needed. If the reliance claim must also identify the assignment under which the Work was performed, check that relation separately through F.6.
    • evidence, provenance, authenticity, currentness, copied-source, or generated-source relation: apply A.10 and name the claim-bound evidence relation, currentness relation, and the use allowed or blocked by that relation.
    • assurance, 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. If the word ready names full-kit or work-entry readiness, use A.15.5; if it names a gate decision, use A.21.
    • 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: use the permission and authority branch above and choose by the plain question it answers now, never by the displayed word.

    Recovered prerequisites for A.15.4 closure:

    Pattern or relation usedRecovered output for this A.15.4 repairA.15.4-local use
    A.6 or A.6.BTyped claim IDs (L-*, A-*, D-*, and E-*) plus the pattern that defines or constrains the current boundary claim or the current effect-bearing claim.Use for wording, boundary, API, schema, or use-boundary recovery before intended work or reliance.
    A.10Claim-bound evidence relation, freshness field, currentness field, and the use allowed or blocked by that relation for the attempted claim.Use for evidence, provenance, authenticity, credential-currentness, copied-source, or generated-source recovery.
    B.3Typed assurance claim, no-assurance-use disposition, or rejected or downgraded assurance claim.Use only when the work or reliance claim under repair relies on a typed assurance claim.
    A.21OperationalGate(profile), GateDecision, DecisionLogRef, gate profile, gate version, scope, window, and replay or freshness pins.Use for gate-passage reliance in the named scope and window.
    A.20ConstraintValidity status, witness, PathId or PathSliceId when applicable, window, sentinel, and pins when those fields are needed for the claim.Use for flow constraint-validity reliance.
    Permission or authority is currentUse the single branch above and carry the native object named by the selected row with its own closing conditions.Do not mint or cite a generic permission-result object.
    A.13 and A.15.1; F.6 when the assignment mattersA.13 identifies the actual performer, and A.15.1 independently admits the dated U.Work occurrence. If this reliance must also state under which assignment the Work was performed, F.6 checks that separate relation. Add the A.10 evidence or provenance relation when the reliance uses it.Use for reliance on performed Work without turning the assignment check into a Work premise.
    E.17.EFPExplanation class, source-finding relation, and faithfulness relation over the selected source U.Episteme, with the exact EpistemePublicationRelation occurrence named separately when availability is material.Use for generated-explanation faithfulness and source-finding before operative reliance.

    High-impact work or reliance - especially external-impact, irreversible, release-bearing, system-role-assignment-bearing, assignment-state-claim-bearing, credential-status-claim-bearing, gate-bearing, compliance-bearing, safety-bearing, delegated, contested, or assurance-bearing claim or effect - may guide work only for the acting or affected System, any exact ...SystemRoleAssignmentRef whose assignment identity is current, the 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 project-side source relation, evidence relation, gate decision, or assurance claim is recoverable. Capability, authority, responsibility, assignment, Work attribution, and permission remain separate prerequisite rows. Cue-only, source-finding, learning, and bounded reversible probes stay lightweight and do not require a full evidence, currentness, or provenance dossier. Quick dispositions:

    Encountered caseFirst A.15.4 disposition
    Release dashboard tile exposing a source relationIf the tile is a current dashboard view of A.21 GateDecision or DecisionLogRef plus release scope or work target, environment, scope, window, gate profile, gate version, and A.10 evidence relation, it may carry gate-passage reliance for that release and environment.
    Release dashboard tile without current gate or evidence relationUse the tile only for display or source-finding until the current A.21 GateDecision or DecisionLogRef, release scope or work target, environment or scope, time window, gate profile, gate version, and A.10 evidence relation are recoverable. Open B.3 only when an assurance claim is being made.
    Copied review summary or copied approvalTreat it as copied wording and a currentness cue. If the intended use relies on permission or authority, use the single branch above and follow only the selected row. Gate passage still needs the A.21 decision. Performed Work still needs its actual performer identified through A.13 and the dated occurrence independently admitted through A.15.1; if the relied-on account must also identify the assignment, check it separately through F.6. Reliance still needs the applicable A.10 evidence/currentness relation.
    Delegation chain with forwarded approvalEach link names delegator, delegatee, delegated operation or work class, affected work target, affected resource, affected claim, scope, window, the delegation record or relation permitting delegation, subdelegation allowance if any, revocation relation, currentness relation, and evidence relation. A forwarded approval is not delegated authority by copy alone.
    System-role-assignment, revocation, assignment-state, or credential-status displayResolve an assignment claim to both its occurrence and declared U.SystemRoleAssignment species. Resolve the other claims to the assignment-state relation, state-changing speech act, context-state record, credential proof or credential-status result, or gate decision with freshness field, revocation relation, or revocation record; visual display cannot defeat a higher-priority revocation or supersession relation.
    Conflicting source relationsDo not resolve by color, visual salience, copied wording, or apparent recency. Name source-relation order, the decision or rule establishing that order, freshness policy, and supersession rule; the work claim, reliance claim, or effect is contested until resolved, while source-finding and bounded reversible probes remain available.
    Credential badge or register-backed credential-status viewTreat the display as a publication of a register-entry episteme. Before relying, recover separately: the register entry and its publication relation; the constitutive policy or rule; the admitted System and any assignment needed by the authorization claim; each matching exercise or evaluation Work, with its performer identified through A.13 and the dated occurrence admitted independently through A.15.1; a separate F.6 check if the result must also identify the assignment under which that Work was performed; the relation or finding required by the selected §3 row; and the evidence, currentness, and revocation relations. Assignment does not supply performerhood, authority, or responsibility. The entry is authoritative source only under the named rule for the claim or effect covered by that rule. Inscription alone performs no Work, institutes no effect, and creates neither exercise nor non-violation.
    Rollback command-like cueTreat it as a cue, or use A.6.A when it is an action invitation, unless the command record, authorization, work occurrence, performed-work result, or gate decision is recoverable.
    Generated explanation says "authorized"Use the explanation only to find source publications, claim-bound source relations, or required relations and results. If permission or authority is the live claim, route through the single branch above. The explanation itself supplies none of that branch's objects and proves neither gate passage nor performed work.
    Extracted source publication, rewrite, representation shift, explanation, then gate or release claimReturn to the selected source U.Episteme and, where the break concerns availability, its exact EpistemePublicationRelation occurrence, form, or carrier; otherwise return to the source-bearing relation, transform record, evidence relation, explanation relation, or required relation or result at the first lossy or non-commutative transformation operation. The gate claim or release claim waits for the required transform record, evidence relation, explanation relation, gate decision, or assurance claim.
    Repeated green-tile failures without recoverable source relationTreat recurrence as upstream source-relation repair work: expose decision refs, fix dashboard semantics, add claim-bound source relations and currentness, revise boundary wording, or add review cues so the acting user is not repeatedly forced to reconstruct missing source relation.

    Last Updated: 2026-09-03 — upstream FPF commit b999972c (github.com/ailev/FPF)