E.10:0.2b.1 - requirement and required recovery
Treat requirement and required as cues, not as a shared engineering kind or durable suffix. Read the complete span through F.19; when an ordinary sentence can state the condition or action directly, repair it and stop.
When the wording still carries an FPF-governed claim, recover the bearer, the exact claim or relation kind, the governing pattern when its identity changes use, and the practical consequence. Write that construction directly and reread the changed sentence. The result is the repaired text or a blocker, not a separate record.
| Current claim behind the wording | Exact recovery and practical consequence |
|---|---|
| An accountable subject undertakes a duty, accepts a recommendation-as-duty, or is prohibited under an issuing or authority relation. | A.2.8 -> U.Commitment; the commitment changes the accountable subject’s declared duty, recommendation-as-duty, or prohibition stance for the stated scope and validity window. |
| A valid grant permits a beneficiary, no prohibition is found in a current sufficiently complete frame, dated work exercises a grant, actual dated work is found not to violate any applicable prohibition in a current sufficiently complete frame, or a same-scope permission conflict is found. | A.2.8.PER -> the exact GrantedPermissionRelation@Context, NonProhibitionFinding@Context, PermissionExerciseRelation@Context, NonViolationFinding@Context, or PermissionNormConflictFinding@Context; do not route it through U.Commitment. |
| A subject structure, value, or use must remain inside a stated engineering boundary. | The constraint claim under the pattern that defines it; the constraint blocks or admits the named use and does not create a commitment without an accountable subject and authority relation. |
| A public pattern-use template says which candidate-basis positions must have current fillers. | E.11 CandidatePatternUseBasisCompletenessCondition@FPFReadme; it describes positive completeness and does not order a participant to fill a form. |
| One candidate pattern use can precede another only because the first candidate’s result is its basis. | E.11.PUR precedence with prerequisiteResult and the prerequisite candidate’s exact PatternUseResultExpectation@Context; no duplicate result-kind field is created. |
| One transformation-flow position depends on another. | E.18.3 basisDependency with its exact supporting relation; dependency is not obligation. |
| An improvement loop cannot continue until missing information positions become sufficient. | E.23 holdUntilInformationBasisSufficient with non-empty unfilled-position descriptions and one sufficiency condition. |
| A framework-authoring dependency is absent or not current for the next use. | E.4.DPF separates availability from relevance; only a missing dependency carries an acquisition-condition description, and only missing + currentForNextAuthoringUse blocks the next authoring use. |
| A candidate framework organization must cover declared relation families for a stated use. | One E.4.DPF constraint claim node with covered family ref-kind pairs, admitted-use description, and coverage-criterion description; any WorkPlan acceptance target remains separate basis. |
Name admission precedes slot verification. CandidatePatternUseBasisRelation@Context is admissible because the head exposes the basis relation and its two sides; CandidatePatternUseBinding is not repaired by kind-correct fields because Binding hides that subject relation. Likewise, BoundaryConditionKindSlot names a slot whose values classify boundary conditions; BoundaryRoleSlot would falsely suggest a role value. Apply F.18 only when a durable name is actually being minted.