#Function and Functional Precision Restoration (RPR-FUNCTION)

A.6.F · Stable · Architectural pattern · Normative unless explicitly marked informative · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative

Use this pattern when function, functional, functionality, effect, or a similar function-like phrase carries an FPF claim beyond ordinary prose. The reading to inspect may concern architecture, work, method, capability, a system-role kind or assignment, participation, actual functioning, responsibility, quality, mathematics, module allocation, an interface, or another claim named by value. These are recognition and dispatch possibilities, not one semantic kind.

#Keywords

• function wording
• functional architecture
• FunctionalStructure
• required behavior or effect
• actual transformation
• method-description membership
• capability
• work
• module allocation
• mathematical function
• episteme/publication boundary.

#Relations

#Content

#Problem frame

Use this pattern when function, functional, functionality, effect, or a similar function-like phrase carries an FPF claim beyond ordinary prose. The reading to inspect may concern architecture, work, method, capability, a system-role kind or assignment, participation, actual functioning, responsibility, quality, mathematics, module allocation, an interface, or another claim named by value. These are recognition and dispatch possibilities, not one semantic kind.

The first useful move is to recover the exact object or claim and its subject pattern. Return the repaired wording, next admissible use, and needed stop or subject-pattern return. Use the following FunctionUseRepair note only when a receiving use needs the repair to remain inspectable:

FunctionUseRepair:
phrase:
sourceCueText?:
functionLikeReadingUnderRepair:
exactGovernedObjectOrClaim:
directRelationPredicateUse?:
relationalAssertionUse?:
obtainingRelationOccurrenceUse?:
reusableDeclarationUse?:
selectedClaimBearingEpistemeUse?:
representationUse?:
subjectPatternApplicationRefs?:
blockedLocalOverreadRefs?:
nextAdmissibleUse:
stopCondition:

Stop when the source cue, exact entity, value, claim, or claim-bearing episteme, subject pattern, and the next admissible use are clear. If the next step must test whether named participants stand in a relation, add its admitted direct predicate. If it must preserve an affirmative, negative, or modal claim about that predicate, identify the exact [C.2.1](/generated/patterns/C.2.1) relational-assertion episteme and its claim. If it must track one particular obtaining instance, apply the subject pattern's identity rule and add the separately individuated occurrence. Otherwise leave those three branches empty. Add reusable declaration, other selected assertion, specification, or view episteme, or representation correspondence only when the next step needs it.

What goes wrong if A.6.F is missed: a function becomes a root kind; functional architecture becomes a peer ontology beside architecture; a capability becomes a function; a method or work occurrence becomes a function; a mathematical function becomes design ontology; a module allocation becomes functional truth; or a quality claim hides behind "functionality".

What A.6.F buys in practice: the practitioner can keep useful engineering language while naming the exact object or claim and going straight to its subject pattern. Direct participation, reusable declaration, claim-bearing description, and representation remain separate instead of becoming one generic function record.

Not this pattern when the phrase is ordinary prose and carries no FPF claim being made. If the issue under repair is a general relation word, evaluative language, grounded architecture adequacy, or an architecture structural view, use [A.6.P](/generated/patterns/A.6.P), [C.16.Q](/generated/patterns/C.16.Q), [C.30](/generated/patterns/C.30), or [C.30.ASV](/generated/patterns/C.30.ASV) respectively.

E.10.ARCH subject-pattern relation. When [E.10](/generated/patterns/E.10) encounters function-like wording whose exact entity, value, claim, claim-bearing episteme, direct relation, or subject pattern is hidden, [E.10.ARCH](/generated/patterns/E.10.ARCH) may apply [A.6.F](/generated/patterns/A.6.F) until that object and the remaining action are clear or the wording is lowered to ordinary prose, quote-only wording, reduced-use cue, blocked use, or incomplete rewrite. A direct relation names its actual participants; a reusable RelationSignature and declaration-local SlotSpecs, selected assertion, specification, or view episteme, and C.29 representation correspondence are added only for a current receiving use. After recovery, apply the subject pattern; [A.6.F](/generated/patterns/A.6.F) alone establishes no architecture, mathematics, quality, work, evidence, assurance, gate, decision, or release claim.

#Problem

FPF texts repeatedly use function-like wording for different FPF kinds and relations:

• required transformation or effect in an architecture view;
• capability of a holon;
• method wording;
• work occurrence or work result;
• a system-role kind or assignment, participation, actual functioning, or responsibility;
• mathematical function or relation;
• quality, fitness, or characteristic wording;
• module allocation or interface relation;
• functional architecture shorthand.

These uses are all legitimate in ordinary engineering speech. They are not the same FPF object or claim. If the text does not name the exact entity, value, claim, or claim-bearing episteme and its subject pattern, subsequent reasoning cannot tell whether the sentence is about architecture, behavior, work, a system-role kind or assignment, participation, actual functioning, responsibility, mathematics, module structure, quality, evidence, or decision. When a separate direct relation, reusable declaration, assertion or specification, selected view, or representation is current, identify it as that separate object.

#Forces

#Solution

A.6.F is an A.6.P RPR specialization for function-like wording. It does not mint U.Function. It assigns the use under repair to an exact entity, value, claim, or claim-bearing episteme and its subject pattern, then stops unless another claim remains current. It does not package direct relations, declaration-local SlotSpecs, assertions, specifications, views, and representation elements as peer records.

#Trigger rule

A.6.F applies when function-like wording may carry one or more of these independently established readings. The list is a recognition and dispatch palette, not a U.* kind, claim kind, relation kind, or admission result:

The familiar estimate of roughly seven meanings is only a recall cue, not a fixed count. Several entries below unfold into different objects, claims, and relations, function wording often transfers metonymically among them, and one occurrence may carry more than one reading. Recover what the sentence actually says rather than assigning it to a numbered meaning.

• architecture or functional architecture;
• capability, effect, externally promised behavior, or user-visible functionality;
• method wording, work occurrence, or work result;
• a system-role kind or assignment, participation, actual functioning, or responsibility;
• mathematical function, mapping, relation, loss, objective, or value functional;
• quality, fitness, characteristic, score, or proxy wording;
• module allocation, interface, signature, port, API, protocol, flow, or mechanism relation;
• another independently established claim named by value, such as evidence, assurance, gate, decision, or release.

If none of those readings carries a current FPF claim, the wording may remain ordinary Plain prose.

#FunctionUseRepair

FunctionUseRepair is an optional pattern-local repair note for a receiving use that needs inspectable detail. Its functionLikeReadingUnderRepair value only helps a reader recognize and dispatch a possible reading; neither that value nor the three scan groups below is a U.* kind, claim kind, relation kind, or admission result. The recovered result belongs in exactGovernedObjectOrClaim under its subject pattern. The note carries no project-publication, evidence, decision, or U.Function authority. FunctionalStructure is an ArchitectureStructureKindRef value under C.30.ASV, not a kernel Function kind.

FunctionUseRepair ::= {

  phrase,
  functionLikeReadingUnderRepair: {
    directObjectOrValueReading?:
      holonCapability |
      methodDescription |
      mechanismRealization |
      workPlan |
      workOccurrence |
      workResult |
      mathematicalFunction,

    claimOrConditionReading?:
      requiredTransformation |
      requiredEffect |
      inputCondition |
      outputCondition |
      systemRoleKindOrAssignmentCue |
      participationOrFunctioningCue |
      responsibilityCue |
      qualityExpression |
      characteristicExpression |
      functionalArchitecture |
      evidenceClaim |
      assuranceClaim |
      gateClaim |
      decisionClaim |
      publicationClaim,

    relationParticipantOrLocusReading?:
      functionalElementLocus |
      transformerSideFiller |
      candidateBearer |
      functionalPort |
      methodPosition |
      mathematicalRelation |
      moduleAllocation |
      interfaceRelation |
      signatureRelation,

    otherDeclared?
  },
  exactGovernedObjectOrClaim: oneOrMoreOf {
    exactEntityOrValueRef?,
    exactClaimOrClaimContent?,
    exactClaimBearingEpistemeRef?
  },

  directRelationPredicateUse?: {
    admittedDirectRelationKindRef,
    relationKindToken?,
    semanticPredicate,
    actualParticipantRefs,
    directRelationPatternRef
  },

  relationalAssertionUse?: {
    relationalAssertionEpistemeRef,
    assertedClaimContent,
    assertedSemanticPredicate,
    polarityOrModality,
    actualParticipantRefs,
    directRelationPatternRef
  },

  obtainingRelationOccurrenceUse?: {
    individuatedRelationOccurrenceRef,
    obtainingSemanticPredicate,
    actualParticipantRefs,
    occurrenceIdentityRuleRef,
    directRelationPatternRef
  },

  reusableDeclarationUse?: {
    relationSignatureRef,
    declarationLocalSlotSpecRefs
  },

  selectedClaimBearingEpistemeUse?: {
    assertionSpecificationOrViewEpistemeRef,
    selectedClaimOrDesignation
  },

  representationUse?: {
    representationElementRefs,
    explicitC29Correspondence,
    representedObjectOrClaimRef
  },

  sourceCueText?,
  subjectPatternApplicationRefs?,
  blockedLocalOverreadRefs?,
  admissibleUse,
  nonAdmissibleUse?,
  nextAdmissibleUse,
  stopCondition
}

The repair is complete when a practitioner can name the exact object or claim, apply its subject pattern, and state the remaining action. When a note is needed, at least one exact entity or value, claim or claim content, or claim-bearing episteme is required in exactGovernedObjectOrClaim. A source cue stays in sourceCueText; it is not a recovered value. When a direct relation is current, first name its admitted kind, semantic predicate, and actual participants in directRelationPredicateUse. Add relationalAssertionUse only when one exact [C.2.1](/generated/patterns/C.2.1) episteme affirms, denies, or otherwise modalizes that predicate. Add obtainingRelationOccurrenceUse only when the receiving use needs one separately individuated obtaining occurrence under the subject pattern's identity rule, applied through [A.6.REL](/generated/patterns/A.6.REL); a predicate or assertion never supplies occurrence identity. Add a reusable RelationSignature and declaration-local SlotSpecs only for reusable typed use; add another selected assertion, specification, or view episteme only when it is a separate claim-bearing object; add a C.29 representation element and explicit correspondence only when representation matters. If the text still hides a function, capability, work, method, system-role kind or assignment, participation, functioning, responsibility, module, evidence, gate, or mathematical-function collapse, the repair is incomplete.

Preserve the subject's necessary applicability and stop conditions in the repaired claim. Add blockedLocalOverreadRefs or nonAdmissibleUse as an explanatory guard only under F.19:4's full independent-ground, plausible-reader, contribution, and smallest-clear-correction test. An unused guard may be omitted without an absence entry.

#Repair assignments

When a function-like phrase is claim-bearing, recover the exact object or claim under concern before lowering or rewriting the phrase. C.30.ASV does not define a world-side or view-local FunctionalElement individual. Its FunctionalStructureView is the same ArchitectureStructuralView episteme about one selected functional U.Structure; a FunctionalStructureViewUse may cite exact FunctionalElementClaim epistemes and other values needed by the use. Required or desired effects, actual transformations, candidate bearers, capabilities, ports, allocations, and correspondences remain separately established claims or values. If a distinct functional-element individual is genuinely needed, first define its predicate and identity in a subject pattern; otherwise stop at the smaller exact requirement, behavior or effect claim, capability, participant, condition, port declaration, or other directly defined object. A field name or source cue is not a substitute for that object.

Method-description guard. A procedure, code file, solver model, recipe, protocol, or algorithm is only a clue. First identify the knowledge object and the exact method it is about. Then point to at least one claim that says how that method is done, such as its transformation or enactment concern, applicability, precondition, intended effect or preserved condition, bound, generic participant meaning, or internal method composition. Only then classify that already identified U.Episteme as U.MethodDescription under A.3.2. A title, author, citation, approval, file form, or runnable artifact alone is a near-miss. If no admitted U.Method is its exact EntityOfConcern, or no way-of-doing claim is present, do not use U.MethodDescription: keep the actual plan, work, result, formal substrate, mechanism declaration, representation, publication occurrence or form, or carrier with its subject pattern. A different code, text, diagram, or publication form does not decide membership. If claim content, exact method, or effective reference scheme changes, C.2.1 first identifies the resulting episteme; then apply A.3.2 to that individual.

Required-versus-actual check. “The cooling loop shall reduce outlet temperature by 8 °C within 60 seconds” remains a requirement or functional-view claim; by itself it identifies no U.Transformation. If a later run actually changes the loop state, identify that cooling occurrence separately under A.3.4 from the changed loop, exact boundary and conditions, actual before/during/after facts, and continuity or reidentification rule. Requirement-only material is the countercase and stop: it cannot admit an actual transformation, observed functioning, or evidence of success.

#Functional architecture boundary

Functional architecture is the FunctionalStructure case of ArchitectureOf@Context: the declared organization used to relate one selected functional structure to independently established claims about required behavior or effects, capabilities, functional dependencies, and constraints that a holon is to realize, before or alongside allocation to modules, local system-role kinds or assignments, work, evidence, control relations, selected transformation-flow structures, or mathematical descriptions of those structures. Under C.30.ASV, the view is an ArchitectureStructuralView episteme whose EntityOfConcern is that selected structure; it does not define a functional-element individual. A FunctionalStructureViewUse may cite exact FunctionalElementClaim epistemes and other separately established values needed by the use.

Functional architecture shorthand:
  open the `ArchitectureOf@Context` form in the current C.30 edition;
  name the exact described holon and select one functional `U.Structure`;
  use the `ArchitectureStructuralView` episteme whose `EntityOfConcern` is that structure and whose exact viewpoint conformance obtains;
  add `FunctionalStructureViewUse` only when exact `FunctionalElementClaim` epistemes or other separately established values change action;
  require an independent A.3.4 basis for every actual-transformation reference;
  fill every other C.30 field required by this architecture use.

The view keeps requirement, required-behavior/effect, capability, dependency, and constraint claims with their subject patterns; their wording does not turn them into U.StructureRef values or actual transformations. An actual-transformation reference is admissible only after A.3.4 independently grounds the occurrence. A selected TransformationFlowStructure, path slice, crossing, flow valuation, or mathematical description may be related to functional structure through C.30.TFS-REL, [E.18](/generated/patterns/E.18), or [E.18.2](/generated/patterns/E.18.2), but it is neither the required effect nor the functional architecture itself unless the positive selected-structure co-reference check succeeds.

#Function-flow-module alignment note

Recover the local alignment when functional wording touches flow or module allocation but does not yet require a full structural view or A.6.M module-relation repair. Use this note only when the receiving use needs an inspectable alignment record; otherwise state the recovered alignment and boundary in the repaired wording.

FunctionFlowModuleAlignmentNote:
required function or effect:
flow path or dependency:
proposed module allocation:
separateNeighborClaims:
known mismatch:
subjectPatternApplicationRefs:
admissible use:
non-admissible use?:

The note records only the local function-flow-module alignment and boundary. Its explanatory non-admissible-use guard is optional under the full F.19:4 test and needs no absence entry when unused. Functional architecture, module relation, implemented-interface, evidence-sufficiency, and architecture-decision claims remain with their subject patterns.

#Common kind and relation separations

#Composability and compositionality

Composability and quality compositionality are separate claims. If the text says parts can be assembled, keep that as a structure or use claim. If it says a quality of the whole follows from parts, assign the quality-composition claim to C.25 and C.16-backed measurement or quality claim:

Composability:
  exactGovernedObjectOrClaim: the A.6.M `ModuleInterfaceClaim` content for "A and B can be assembled under interface X"
  selectedClaimBearingEpistemeUse: the exact C.2.1 episteme carrying that claim content
  directRelationPredicateUse?: only an exact domain predicate independently admitted for a direct module-allocation or module-interface relation, with its actual participants
  relationalAssertionUse?: the exact C.2.1 episteme that affirms, denies, or modalizes that admitted predicate, only when such a predicate is current
  obtainingRelationOccurrenceUse?: only when that admitted relation has a same-versus-new-occurrence rule and the receiving use must distinguish one obtaining occurrence through A.6.REL
  reusableDeclarationUse?: one compatible RelationSignature and its declaration-local SlotSpecs, only when repeated typed use needs them
  subjectPatternApplicationRefs: A.6.M for `ModuleInterfaceClaim`; C.2.1 for its claim-bearing episteme; A.6.RCD when a reusable direct relation is needed but absent; A.6.REL only after the direct relation is admitted and one obtaining occurrence must be distinguished; A.6.0 and A.6.5 only for the reusable declaration
Quality compositionality:
  exactGovernedObjectOrClaim: the affected Q-Bundle and the exact structural-characteristic, causal-hypothesis, or evidence-relation claim that this use relies on
  directRelationPredicateUse?: the exact predicate defined or tested through C.16, C.16.Q, or A.10 and its actual participants, only when that relation is current
  relationalAssertionUse?: the exact C.2.1 episteme and its affirmative, negative, or modal quality or evidence claim when that assertion is current
  subjectPatternApplicationRefs: C.25; C.16 or C.16.Q; A.10 only when evidence provenance is the claim being made
Non-admissible:
  successful assembly is not quality propagation

Compositional formalisms may express explicit composition structures and view or model relations. They do not make safety, latency, reliability, or another quality propagate automatically.

A.6.F defines no separate quality-composition record. Use the claim form supplied by the applicable subject pattern. A composite family uses the exact C.25 Q-Bundle, including its bearer, scope, measures, qualification window, mechanisms or status, and evidence. A single characteristic or measurement follows C.16, with C.16.Q used only when quality wording still needs repair; name its bearer, scope, measure, and claim identity. Keep a causal inference with its causal pattern, and use A.10 only when evidence provenance is the claim being made. If those values cannot be named, keep the quality-composition claim unresolved rather than filling an A.6.F-only schema.

#Worked slices

Function-like module claim; no direct relation. A release note says, “The brake-control functional package is in the vehicle-control system.” The head noun is package; do not turn the modifier functional into U.Function. For this use, recover this concrete result:

• exactGovernedObjectOrClaim: A.6.M ModuleInterfaceClaim content naming BrakeControllerPackage, VehicleControlSystem, Release-2026Q2, VP.ModuleInterface, BrakeControlBoundary, and an interfaceSpecificationRef that resolves BrakeControlInterfaceSpec-v5; its direct-relation disposition is noDirectRelationClaimed;
• selectedClaimBearingEpistemeUse: BrakeArchitectureNote_v3 : U.Episteme under C.2.1 carries that content and has BrakeControllerPackage as its exact EntityOfConcern;
• directRelationPredicateUse, relationalAssertionUse, and obtainingRelationOccurrenceUse: not used, because no domain rule has admitted a direct module relation predicate or an obtaining occurrence for this case;
• remaining action: apply A.6.M to the declared interface and admissibility conditions; do not infer a function allocation, direct relation, or implemented compatibility from the source phrase.

Interrupted assignment; occurrence identity needed. A maintenance log says, “Robot-7 resumed its inspection function after a documented period with no inspection assignment.” Treat function as a cue. Recover InspectorSystemRole and one declared direct species CellInspectorAssignment <: U.SystemRoleAssignment; then test its direct predicate for Robot-7 : U.System and the species-specific cell and interval participants. Keep Robot7AssignmentLog_42 as the separate C.2.1 episteme that states the interval facts. A.2.1 says that the demonstrated non-assignment period ends the first assignment occurrence and the later resumption begins another. When the maintenance history must distinguish them, apply A.6.REL with that identity rule to keep InspectorAssignment_PreGap and InspectorAssignment_PostGap distinct. A taxonomy or scheme is not an assignment participant, and neither assignment implies inspection Work.

Neighbor claims that need their own relation.

• TestArticle-7 participates passively in TestWork-9 during TestInterval-9 is not established by TestArticleSystemRole or TestArticleAssignment-7. Until a direct passive-test-participation predicate supplies participant order and identity, return A.6.RCD missing-governor[direct passive-test-participation relation]; the tester's Work and F.6 attribution remain usable.
• Motor-M1 drives PumpAssembly-A during PumpRun-17 needs a direct motor-drive-functioning predicate. Assignment, torque capability, and pumping Work remain separate; without that predicate return A.6.RCD missing-governor[direct motor-drive-functioning relation].
• Hammer-3 supports PaperStack-9 during Interval-P needs a direct artifact-support predicate. Do not replace that exact claim with an interchangeable list of use, load, support, or function kinds; without the predicate return A.6.RCD missing-governor[direct artifact-support relation].

Functional architecture phrase. A team says, "the functional architecture is the user journey." A.6.F does not let the phrase create a separate architecture kind. For a receiving use that needs inspectable detail, the repair can be recorded as:

FunctionUseRepair:
phrase: "functional architecture"
functionLikeReadingUnderRepair: functionalArchitecture
exactGovernedObjectOrClaim: the `ArchitectureOf@Context` claim record and its one selected functional `U.Structure`
selectedClaimBearingEpistemeUse: the exact `ArchitectureStructuralView` episteme whose `EntityOfConcern` is that structure, plus any exact C.2.1 `FunctionalElementClaim` epistemes cited by the use
subjectPatternApplicationRefs: C.30; C.30.ASV
blockedLocalOverreadRefs: the source claim "the functional architecture is the user journey"
nextAdmissibleUse: when the view changes action, use `FunctionalStructureViewUse` to cite the view, exact claim epistemes, and only separately established bearer, capability, port, allocation, or correspondence values
stopCondition: ordinary phrasing remains Plain when no architecture claim is made; requirement-only material remains a claim; an actual transformation appears only on an independent A.3.4 basis

Functionality as quality. A product note says, "new functionality improves adequacy." The repair separates the exact added-capability or required-effect claim from the quality claim. Capability or effect wording may stay as recognition, but the adequacy claim goes to [C.25](/generated/patterns/C.25), [C.16](/generated/patterns/C.16), C.16.Q, or the admitted characteristic or measurement pattern that states its bearer and criterion. A.6.F stops once those exact claims and subject patterns are clear; it adds no reusable declaration, view, or representation apparatus unless the receiving use actually needs it.

Mathematical function or loss. A model note says, "the loss function explains the holon purpose." The repair keeps the mathematical function under C.29 lens discipline: domain, codomain or relation domain, preserved and lost structure, lens-use admissibility value, and stop condition. The loss may inform a reasoning move; it does not become holon purpose, evidence sufficiency, causal proof, assurance, or project decision by itself.

Pump-station functional dependency. A maintenance note says, "the backup pump function is degraded." A.6.F first separates the required effect, the exact U.Capability value or capability claim, the physical module allocation, the performed maintenance work, the evidence relation, and the quality claim. The functional wording may open a FunctionalStructure view under C.30.ASV or go to the capability pattern; it does not by itself prove the pump was tested, authorize operation, or make the backup module compatible with the main line.

Product-platform allocation. A hardware team says, "thermal management functionality moved to the chassis." The repair separates required heat-removal effect, module allocation, interface constraints, signature constraints, architecture structural view, and any evidence or gate claim. A.6.F keeps the function-like wording useful for architecture work while sending module-interface and evidence claims to their subject patterns.

#Archetypal Grounding

#Bias-Annotation

Lenses tested: Arch, Ontology and episteme, Prag, Did, Gov. Scope: function-like wording that carries an FPF claim being made across FPF.

This checklist verifies the preceding guidance after the practitioner has chosen the selected repair action; it is not a required project control form and not a substitute for the card, note, view, relation, or repair guidance above.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

Function-like wording is too useful to ban and too overloaded to leave unresolved. The smallest useful repair is not a new ontology or a generic record. Name the exact entity, value, claim, or claim-bearing episteme, apply its subject pattern, and state the remaining use. Add an explanatory rejected reading only under the full F.19:4 test.

This design follows A.6.P: recover the direct relation and actual participants when one obtains; add a reusable RelationSignature and declaration-local SlotSpecs only for typed reuse; keep assertion, specification, or view epistemes separate; and keep representation elements under C.29 with explicit correspondence. It also follows C.30: functional architecture is selected structure for a described holon, not a peer of architecture, not a selected transformation-flow structure by default, and not a mathematical graph description by itself.

The pattern keeps ordinary language usable. A phrase can remain Plain when it carries no FPF claim. When it carries an ontological, evidence, causal, assurance, bridge, gate, work, decision, or admissibility claim, the exact object or claim and subject pattern are recoverable. No generic relation, claim, slot, or view record stands in for that result.

#SoTA-Echoing

#Relations

Builds on: A.6.P, A.6.RSIR, A.6.0, A.6.5, A.6.B, A.6.C, A.6.9, A.7, E.10, E.10.ARCH, C.2.P, F.18, and E.8.

Coordinates with: C.2.1 when the task must preserve an assertion about the direct predicate; A.6.REL only when the task must distinguish one obtaining occurrence; C.30, C.30.ASV, C.30.TFS-REL, E.18, A.15, A.2, C.29, C.25, C.16, C.16.Q, A.17, A.18, A.10, G.6, B.3, A.20, A.21, C.11, A.6.RSIR, and A.6.M when a module or interface claim is being made.

Does not replace: C.30 grounded architecture and selected-structure adequacy, C.30.ASV architecture structural-view adequacy, E.18 selected transformation-flow structure, E.18.2 mathematical descriptions, C.29 mathematical-lens use, C.25 Q-Bundles, C.16 characterization, A.15 work and method discipline, A.10 or G.6 evidence, B.3 assurance, A.20 or A.21 gate or release records, or C.11 decisions.

#A.6.F:End

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