#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-governed use beyond ordinary prose. The reading to inspect may concern architecture, work, method, capability, role, 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-governed use beyond ordinary prose. The reading to inspect may concern architecture, work, method, capability, role, 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 small:

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

Stop when the source cue, exact governed entity, value, claim, or claim-bearing episteme, direct owner, the one local overread that would change this repair, 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 direct owner'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 governed object or claim and going straight to its direct owner. 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 governing-pattern relation. When [E.10](/generated/patterns/E.10) encounters function-like wording whose exact governed entity, value, claim, claim-bearing episteme, direct relation, or governing 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 direct governing pattern; [A.6.F](/generated/patterns/A.6.F) does not own architecture, mathematics, quality, work, evidence, assurance, gate, decision, or release claims by function wording alone.

#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;
• role expectation 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 governed entity, value, claim, or claim-bearing episteme and its direct owner, subsequent reasoning cannot tell whether the sentence is about architecture, behavior, work, role, 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 governed entity, value, claim, or claim-bearing episteme and its direct governing 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 separately governed readings. The list is a recognition and dispatch palette, not a U.* kind, claim kind, relation kind, or admission result:

• architecture or functional architecture;
• capability, effect, externally promised behavior, or user-visible functionality;
• method wording, work occurrence, or work result;
• role expectation 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 separately governed claim named by value, such as evidence, assurance, gate, decision, or release.

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

#FunctionUseRepair

FunctionUseRepair is a pattern-local repair note. 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 direct owner. 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 |
      roleExpectation |
      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?,
  directGoverningPatternApplicationRefs?,
  blockedLocalOverreadRefs,
  admissibleUse,
  nonAdmissibleUse,
  nextAdmissibleUse,
  stopCondition
}

The repair is complete when a practitioner can name the exact governed object or claim, apply its direct owner, and state the remaining action. 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 direct owner'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, role, module, evidence, gate, or mathematical-function collapse, the repair is incomplete.

#Repair assignments

When a function-like phrase is claim-bearing, recover the exact object or claim under concern before lowering or rewriting the phrase. FPF treats FunctionalElement@Context as a view-local functional-structure object under C.30.ASV when stable identity, bearer, behavior, ports, capability, and allocation obligations are all current; otherwise A.6.F stops at the smaller exact requirement, behavior or effect claim, capability, participant, condition, port specification, or other directly governed 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 direct owner. 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 separately governed claims about required behavior or effects, capabilities, functional dependencies, and constraints that a holon is to realize, before or alongside allocation to modules, roles, work, evidence, control relations, selected transformation-flow structures, or mathematical descriptions of those structures.

Functional architecture shorthand:
  open the `ArchitectureOf@Context` form in the current C.30 edition;
  name the exact described holon;
  require `structureKindRefs` to include `FunctionalStructure`;
  include only independently selected `U.StructureRef` values;
  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 direct owners; 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

Use this note when functional wording touches flow or module allocation but does not yet require a full structural view or A.6.M module-relation repair.

FunctionFlowModuleAlignmentNote:
required function or effect:
flow path or dependency:
proposed module allocation:
role, work, or evidence consequence:
known mismatch:
governingPatternApplicationRefs:
admissible use:
non-admissible use:

The note records only the local function-flow-module alignment and boundary. Functional architecture, module relation, implemented-interface, evidence-sufficiency, and architecture-decision claims remain with their governing 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 claim content "A and B can be assembled under interface X."
  directRelationPredicateUse?: the A.6.M-admitted module-allocation or module-interface predicate, with the actual participants required by that predicate
  relationalAssertionUse?: the exact interface-specification episteme and its affirmative assembly or compatibility claim, including the predicate, polarity, and actual participants, when that assertion is current
  obtainingRelationOccurrenceUse?: not used for the current A.6.M branch; open this field only if a direct module-relation owner supplies a same-versus-new-occurrence rule and the receiving use must distinguish one obtaining episode through A.6.REL
  reusableDeclarationUse?: one compatible RelationSignature and its declaration-local SlotSpecs, only when repeated typed use needs them
  directGoverningPatternApplicationRefs: A.6.M for the module-interface predicate and claim; C.2.1 for the relational-assertion episteme; A.6.REL only after the direct owner supplies an identity rule 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 C.16, C.16.Q, or A.10-governed predicate 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
  directGoverningPatternApplicationRefs: 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.

CompositionalityClaim@Quality ::= {
  affectedQBundleRef,
  partStructureRefs,
  wholeStructureRef,
  compositionRelation,
  lensUseAdmissibilityValue,
  nonAdmissibleUse
}

#Worked slices

Function-like relation; assertion enough. 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:

• directRelationPredicateUse: the A.6.M moduleIn predicate moduleIn(BrakeControllerPackage, VehicleControlSystem) under Release-2026Q2, VP.ModuleInterface, BrakeControlBoundary, and BrakeControlInterfaceSpec-v5; the actual relation participants are BrakeControllerPackage and VehicleControlSystem;
• relationalAssertionUse: BrakeArchitectureNote_v3 : U.Episteme under C.2.1 affirms that exact predicate for those participants;
• obtainingRelationOccurrenceUse: not used, because the release question needs the current assertion but does not distinguish repeated obtaining episodes;
• remaining action: apply A.6.M to the declared interface and admissibility conditions; do not infer a function allocation or implemented compatibility from the source phrase.

Interrupted relation; 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 and test the direct assignment predicate under A.2.1 over the actual participants Robot-7 : U.System, InspectorRole, MaintenanceRoles-2026, and Maintenance-Scheme-A. 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. Do not merge the two occurrences merely because all four participant names match.

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. The repair is:

FunctionUseRepair:
phrase: "functional architecture"
functionLikeReadingUnderRepair: functionalArchitecture
exactGovernedObjectOrClaim: the `ArchitectureOf@Context` claim record whose `structureKindRefs` includes `FunctionalStructure`
selectedClaimBearingEpistemeUse: the exact `FunctionalStructureView@Context` episteme when that selected view changes action
directGoverningPatternApplicationRefs: C.30; C.30.ASV
blockedLocalOverreadRefs: user journey publication, work log, selected transformation-flow structure, mathematical graph description, module diagram
nextAdmissibleUse: open C.30.ASV only if the selected functional structure changes action
stopCondition: ordinary phrase remains Plain if no architecture claim is being made

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 owner that states its bearer and criterion. A.6.F stops once those exact claims and direct owners 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 owner; 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 governing 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 ungoverned. The smallest useful repair is not a new ontology or a generic record. Name the exact governed entity, value, claim, or claim-bearing episteme, apply its direct owner, say what the phrase is not about, and state the remaining use.

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 direct owner 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-08-04 — upstream FPF commit 8b727cba (github.com/ailev/FPF)