#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 being made beyond ordinary prose. The claim kind may be architecture, work, method, capability, role, quality, mathematical, module-allocation, interface, or another FPF claim named by value.

#Keywords

• function wording
• functional architecture
• FunctionalStructure
• function-use repair
• capability/effect
• work/method boundary
• module allocation
• mathematical function.

#Relations

#Content

#Problem frame

Use this pattern when function, functional, functionality, effect, or a similar function-like phrase carries an FPF claim being made beyond ordinary prose. The claim kind may be architecture, work, method, capability, role, quality, mathematical, module-allocation, interface, or another FPF claim named by value.

The first useful move is small:

FunctionUseRepair:
phrase:
sourceCueText?:
claimKindUnderRepair:
recoveredValueKindRefs?:
recoveredRelationRecordRefs?:
recoveredSlotRefs?:
recoveredViewRecordRefs?:
recoveredFpFReferenceRefs?:
directGoverningPatternApplicationRefs?:
blockedLocalOverreadRefs:
nextAdmissibleMove:
stopCondition:

Stop when the source cue, recovered value-kind refs, relation-record refs, slot refs, view-record refs, needed FPF reference refs, direct governing-pattern applications, the one local overread that would change this repair, and the next admissible move are clear.

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 recovering the FPF value kind, relation record, slot reference, view record, or governing pattern named by value for any remaining claim kind.

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 required transformation, capability, method, work, role, mathematical-function use, quality use, module allocation, interface relation, architecture use, FPF kind named by value, relation, claim record, governing pattern, or stop condition is hidden, [E.10.ARCH](/generated/patterns/E.10.ARCH) may apply [A.6.F](/generated/patterns/A.6.F) until those fields are recovered or the wording is lowered to ordinary prose, quote-only wording, reduced-use cue, blocked use, or incomplete rewrite. After recovery, the next application is the governing pattern named by the recovered relation; [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 kind. If the text does not recover the FPF value kind, relation record, slot reference, view record, or governing pattern named by value, subsequent reasoning cannot tell whether the sentence is about architecture, behavior, work, role, mathematics, module structure, quality, evidence, or decision claim.

#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 existing FPF kind, relation, claim record, view, or governing-pattern application and stops there unless another claim kind remains current.

#Trigger rule

A.6.F applies when a sentence uses function-like wording to carry one or more current FPF claim kinds:

• 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 FPF claim named by value, such as evidence, assurance, gate, decision, or release.

If none of those claim kinds is current, the wording may remain ordinary Plain prose.

#FunctionUseRepair

FunctionUseRepair is a pattern-local repair note. It 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,
  claimKindUnderRepair:
    requiredTransformation |
    requiredEffect |
    functionalElementLocus |
    transformerSideFiller |
    candidateBearer |
    inputCondition |
    outputCondition |
    functionalPort |
    holonCapability |
    methodPosition |
    methodDescription |
    mechanismRealization |
    workPlan |
    procedureWording |
    workOccurrence |
    workResult |
    roleExpectation |
    mathematicalFunction |
    mathematicalRelation |
    qualityExpression |
    characteristicExpression |
    moduleAllocation |
    interfaceRelation |
    signatureRelation |
    functionalArchitecture |
    evidenceClaim |
    assuranceClaim |
    gateClaim |
    decisionClaim |
    publicationClaim |
    otherDeclared,
  recoveredValueKindRefs?:
    U.Transformation |
    TransformationFlowStructure |
    U.Capability |
    U.Method |
    U.MethodDescription |
    U.Mechanism |
    U.WorkPlan |
    U.Work |
    MathematicalFunctionUnderC29 |
    otherDeclared,
  recoveredRelationRecordRefs?:
    FunctionalElement@Context |
    ModuleAllocationRelation |
    InterfaceSpecification |
    RoleExpectation |
    otherDeclared,
  recoveredSlotRefs?:
    TransformerRef? |
    CandidateBearerRef? |
    InputConditionRefs? |
    OutputConditionRefs? |
    FunctionalPortRefs? |
    FunctioningRef? |
    QBundleSlot |
    otherDeclared,
  recoveredViewRecordRefs?:
    FunctionalStructureView@Context |
    otherDeclared,
  recoveredFpFReferenceRefs?,

  sourceCueText?,
  directGoverningPatternApplicationRefs?,
  bearerRef?,
  candidateBearerRef?,
  functionalBehaviorRef?,
  blockedLocalOverreadRefs,
  admissibleUse,
  nonAdmissibleUse,
  nextAdmissibleMove,
  stopCondition
}

The repair is complete when a practitioner can say which FPF value kind named by value, relation record, slot reference, view record, or direct governing-pattern application the function-like wording uses. A source cue stays in sourceCueText; it is not a recovered value. 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 positive object under concern before lowering or rewriting the phrase. FPF treats FunctionalElement@Context as a view-local functional-structure record under C.30.ASV when stable identity, bearer, behavior, ports, capability, and allocation obligations are all current; otherwise A.6.F may stop at the smaller recovered value kind, relation record, slot reference, or source cue.

#Functional architecture boundary

Functional architecture is the FunctionalStructure case of ArchitectureOf@Context: the declared organization of required transformations, capabilities, effects, 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.

FunctionalArchitecture@Context shorthand expands to:
  ArchitectureOf@Context(
    describedHolonRef,
    boundedContextRef,
    structureKindRefs includes FunctionalStructure,
    structureRefs includes `U.StructureRef` values for required transformations,
      effects, capabilities, dependencies, and constraints,
    admissibleUse,
    nonAdmissibleUse
  )

This shorthand is admissible only when the expanded C.30 or C.30.ASV interpretation is recoverable. 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 not 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:
  "A and B can be assembled under interface X."
  recoveredRelationRecordRefs: ModuleAllocationRelation; InterfaceSpecification
  directGoverningPatternApplicationRefs: A.6.M when a module-interface claim remains; A.6.5 when a signature claim remains
Quality compositionality:
  "The assembled whole preserves safety, latency, or reliability."
  recoveredSlotRefs: QBundleSlot; structuralCharacteristicQBundleInputSlot; structuralCharacteristicCausalHypothesisForQBundleSlot; structuralCharacteristicEvidenceRelationForQBundleSlot
  directGoverningPatternApplicationRefs: C.25; C.16 or C.16.Q; A.10 only when the evidence-provenance path 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

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"
claimKindUnderRepair: functionalArchitecture
recoveredSlotRefs: ArchitectureOf@Context.structureKindRef = FunctionalStructure
recoveredViewRecordRefs: FunctionalStructureView@Context when selected functional structure changes action
recoveredFpFReferenceRefs: ArchitectureOf@Context with structureKindRef = FunctionalStructure
directGoverningPatternApplicationRefs: C.30; C.30.ASV
blockedLocalOverreadRefs: user journey publication, work log, selected transformation-flow structure, mathematical graph description, module diagram
nextAdmissibleMove: 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 added capability or effect from quality claim. Capability or effect wording may stay as recognition, but adequacy claim goes to [C.25](/generated/patterns/C.25), [C.16](/generated/patterns/C.16), C.16.Q, or an admitted characteristic or measurement governing pattern when the claim is being made. A.6.F stops after value-kind, relation-record, slot-reference, view-record, or governing-pattern recovery when no quality claim remains.

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 holon capability, 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 a capability record; 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 move; it is not a required project control form and not a substitute for the card, note, view, relation, or repair move 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. It is recovery of the value kind, relation record, slot reference, claim record, view record, or governing-pattern application: say what the phrase is about, what it is not about, and what move remains admissible.

This design follows A.6.P: trigger phrase, value-kind recovery, relation-record recovery, slot-reference recovery, explicit relation fields, governingPatternRef fields, and lexical guardrails. 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 being made. When it carries ontological, evidence, causal, assurance, bridge, gate, work, decision, or admissibility claim kind, the FPF kind named by value, relation, claim record, view, or governing-pattern application is recoverable.

#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.8, A.6.9, A.7, E.10, E.10.ARCH, C.2.P, F.18, and E.8.

Coordinates with: 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-05-31 — this section last modified in upstream FPF commit 16cd3138 (github.com/ailev/FPF)