#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 a live FPF claim beyond ordinary prose. The claim kind may be architecture, work, method, capability, role, quality, mathematical, module-allocation, interface, decision, evidence, or gate.

#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 a live FPF claim beyond ordinary prose. The claim kind may be architecture, work, method, capability, role, quality, mathematical, module-allocation, interface, decision, evidence, or gate.

The first useful move is small:

FunctionUseRepair:
phrase:
liveUse:
recoveredCarrierKind:
recoveredCarrierRef?:
falseCarrierKindRefs:
nextAdmissibleMove:
stopCondition:

Stop when the recovered carrier kind, any needed carrier ref, false carrier kinds, 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 exact carrier and the exact governing pattern that carries any remaining claim kind.

Not this pattern when the phrase is ordinary prose and carries no live FPF claim. If the live issue is a general relation word rather than function-like wording, use A.6.P. If the live issue is evaluative language, use C.16.Q. If the live issue is architecture-description adequacy, use C.30. If the live issue is an architecture structural view, use C.30.ASV.

#Problem

FPF texts repeatedly use function-like wording for different carriers:

• 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 carrier, 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 live use to an existing carrier and stops there unless another claim kind remains live.

#Trigger rule

A.6.F applies when a sentence uses function-like wording to carry one or more live 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;
• evidence, assurance, gate, decision, or release claim.

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

#FunctionUseRepair

FunctionUseRepair is a pattern-local repair note, not a project publication, not evidence, not a decision, and not U.Function. FunctionalStructure is an ArchitectureStructureKindRef value under C.30.ASV, not a kernel Function kind.

FunctionUseRepair ::= {
  phrase,
  liveUse:
    requiredTransformationOrEffect |
    holonCapability |
    methodOrProcedure |
    workOccurrenceOrResult |
    roleExpectation |
    mathematicalFunctionOrRelation |
    qualityOrCharacteristic |
    moduleAllocation |
    interfaceOrSignatureRelation |
    functionalArchitecture |
    evidenceAssuranceGateDecisionClaim |
    otherDeclared,
  recoveredCarrierKind:
    FunctionalStructure |
    U.Capability |
    U.Method |
    U.MethodDescription |
    U.Work |
    MathematicalFunctionUnderC29 |
    QBundleSlot |
    ModuleAllocationRelation |
    InterfaceSpecification |
    RoleExpectation |
    EvidenceOrGateCue |
    otherDeclared,
  recoveredCarrierRef?,
  falseCarrierKindRefs,
  recordGoverningPatternRef,
  governingPatternApplicationRefs?,
  admissibleUse,
  nonAdmissibleUse,
  nextAdmissibleMove,
  stopCondition
}

The repair is complete when a practitioner can say which carrier kind the function wording uses, which carrier kinds it does not use, and what the next admissible architecture or exact governing pattern application is. If the text still hides a function/capability/work/method/role/module/mathematical-function collapse, the repair is incomplete.

#Repair assignments

#Functional architecture boundary

Functional architecture is the FunctionalStructure case of ArchitectureOf@Context: the intensional 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, or flow/transduction descriptions.

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

This shorthand is admissible only when the expanded C.30/C.30.ASV reading is recoverable. A TGA graph, path slice, crossing, or flow valuation may be related to functional structure through C.30.TGA-FLOW-REL, but it is not the functional architecture itself.

#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 module/interface 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 is a boundary and source-finding aid. It is not the functional architecture, not a module relation, not an implemented interface, not evidence sufficiency, and not an architecture decision.

#Common carrier separations

#Composability and compositionality

Composability and quality compositionality are separate claims. If the text says parts can be assembled, keep that as a structure/use claim. If it says a whole-system quality 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."
  recoveredCarrierKind: ModuleAllocationRelation | InterfaceSpecification
Quality compositionality:
  "The assembled whole preserves safety, latency, or reliability."
  recoveredCarrierKind: QBundleSlot | structuralCharacteristicSupportsQBundleSlot | structuralCharacteristicCausalHypothesisForQBundleSlot | structuralCharacteristicEvidenceSupportForQBundleSlot
Non-admissible:
  successful assembly is not quality propagation

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

CompositionalityClaim@Quality ::= {
  affectedQBundleRef,
  partStructureRefs,
  wholeStructureRef,
  compositionRelation,
  lensUsePosture,
  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"
liveUse: functionalArchitecture
recoveredCarrierKind: FunctionalStructure
recoveredCarrierRef: ArchitectureOf@Context with structureKindRef = FunctionalStructure
falseCarrierKindRefs: user journey publication, work log, TGA graph, 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 live

Functionality as quality. A product note says, "new functionality improves adequacy." The repair separates added capability or effect from quality claim. Capability/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/measurement receiving pattern when the claim is live. A.6.F stops after carrier recovery when no quality claim remains.

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

#Archetypal Grounding

#Bias-Annotation

Lenses tested: Arch, Onto/Epist, Prag, Did, Gov. Scope: function-like wording that carries a live FPF claim across FPF.

This checklist verifies the preceding guidance after the practitioner has chosen the live 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 carrier assignment: say what kind of thing the phrase is about, what it is not about, and what move remains admissible.

This design follows A.6.P: trigger phrase, carrier recovery, explicit relation fields and exact governing pattern fields, and lexical guardrails. It also follows C.30: functional architecture is selected structure for a described holon, not a peer of architecture and not a TGA graph by itself.

The pattern keeps ordinary language alive. A phrase can remain Plain when it carries no live FPF claim. When it carries ontological, evidence, causal, assurance, bridge, gate, work, decision, or admissibility claim kind, the carrier and exact governing pattern application are recoverable.

#SoTA-Echoing

#Relations

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

Coordinates with: C.30, C.30.ASV, C.30.TGA-FLOW-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, and the exact module/interface repair pattern when module or interface claim kind is live.

Does not replace: C.30 architecture-description adequacy, C.30.ASV architecture structural-view adequacy, E.TGA graph/path/crossing discipline, C.29 mathematical-lens adequacy, C.25 Q-Bundles, C.16 characterization, A.15 work/method discipline, A.10/G.6 evidence, B.3 assurance, A.20/A.21 gate/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)