Prerequisite lookup table

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 question	Pattern and required object	What 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.	Identify the System that actually performed the communication and independently recover its A.13 core basis, 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.	Identify who actually performed the Work, independently recover that System’s A.13 core basis, and use 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, identify the actual performer, independently recover that System’s A.13 core basis, and use 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, identify its actual performer, independently recover that System’s A.13 core basis, and use 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. If neither an applicable precedence rule nor an authorized decision resolves the conflict, 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 GateDecisionResult. 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 GateDecisionResult (the result referenced by the local GateDecisionRef used below), its gateRef, profileApplicationRef, rationale, DecisionLogRef, gate profile, gate version, complete check set and check-application results, scope, window, and replay or freshness pins.
Flow constraint-validity witness: cite A.20 ConstraintValidityResult, its evaluation state, outcome when present, and witnessOrReason, the GateCheckRef that resolves to the GateCheckApplicationResult citing this result through sourceResultRef, 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 direct evidence or provenance relation recovered through A.10 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: recover each independently established direct relation under its defining pattern. Use A.10 for the descriptive claim-bound account, currentness and bounded RelianceDisposition; the account cites the relations and their basis rather than creating them.
an actual named assurance claim: apply B.3 to that claim and its limitations and reopen condition. A safety, compliance, trust, release, or characteristic claim first uses the direct pattern that defines or tests it; use B.3 only when that use separately requires assurance. Work-entry readiness uses A.15.5 and gate decisions use A.21.
generated explanation: use E.17.EFP for explanation faithfulness or source-finding relation, then require the independently established source relation recovered through A.10 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 used	Recovered output for this A.15.4 repair	A.15.4-local use
`A.6` or `A.6.B`	Typed 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.10`	A descriptive claim-bound evidence-provenance account, the direct relations and currentness facts it cites, and its RelianceDisposition for the attempted use.	Use for evidence, provenance, authenticity, credential-currentness, copied-source, or generated-source recovery.
`B.3`	Typed 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.21`	`GateDecisionResult`, `gateRef`, `profileApplicationRef`, `DecisionLogRef`, gate profile, gate version, scope, window, and replay or freshness pins.	Use for gate-passage reliance in the named scope and window.
`A.20`	`ConstraintValidityResult` with its evaluation state, outcome when present, and `witnessOrReason`, `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 current	Use 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 matters	Identify the actual performer from the performance facts and independently recover its A.13 core basis; 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 direct evidence or provenance relation recovered through `A.10` when the reliance uses it.	Use for reliance on performed Work without turning the assignment check into a Work premise.
`E.17.EFP`	Explanation 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 case	First `A.15.4` disposition
Release dashboard tile exposing a source relation	If the tile is a current dashboard view of `A.21` `GateDecisionResult` with `decisionValue=pass` (recovered directly or through a `DecisionLogRef` that cites it) plus release scope or work target, environment, scope, window, gate profile, gate version, and direct support relation recovered through `A.10`, it may carry gate-passage reliance for that release and environment.
Release dashboard tile without current gate or evidence relation	Use the tile only for display or source-finding until the current `A.21` `GateDecisionResult` (recovered directly or through a `DecisionLogRef` that cites it), release scope or work target, environment or scope, time window, gate profile, gate version, and direct support relation recovered through `A.10` are recoverable. Open `B.3` only when an assurance claim is being made.
Copied review summary or copied approval	Treat 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 and that performer’s A.13 core basis independently recovered 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 direct evidence/currentness relation recovered through `A.10`.
Delegation chain with forwarded approval	Each 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 display	Resolve 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 relations	Do 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 view	Treat 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 and the performer’s A.13 core basis independently recovered 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 cue	Treat 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 claim	Return 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 relation	Treat 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.