#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:
liveUse:
recoveredFpFKind:
recoveredFpFReference?:
falseFpFKindRefs:
nextAdmissibleMove:
stopCondition:

Stop when the recovered FPF kind, any needed FPF reference, false FPF kind references, 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 kind or relation named by value and the 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 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) sends the case to [A.6.F](/generated/patterns/A.6.F) only until those fields are recovered or the wording is lowered to ordinary prose, quote-only wording, reduced-use cue, blocked use, or incomplete rewrite. [A.6.F](/generated/patterns/A.6.F) then exits to the governing pattern; it 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 kind or relation 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 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;
• another FPF claim named by value, such as evidence, assurance, gate, decision, or release.

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,
  recoveredFpFKind:
    FunctionalStructure |
    U.Capability |
    U.Method |
    U.MethodDescription |
    U.Work |
    MathematicalFunctionUnderC29 |
    QBundleSlot |
    ModuleAllocationRelation |
    InterfaceSpecification |
    RoleExpectation |
    EvidenceOrGateCue |
    otherDeclared,
  recoveredFpFReference?,
  falseFpFKindRefs,
  recordGoverningPatternRef,
  governingPatternApplicationRefs?,
  admissibleUse,
  nonAdmissibleUse,
  nextAdmissibleMove,
  stopCondition
}

The repair is complete when a practitioner can say which FPF kind named by value, relation, claim record, view, or governing-pattern application the function-like wording uses, which false FPF kinds or relations it does not use, and what the next admissible architecture or governing-pattern application is. If the text still hides a function, capability, work, method, role, module, or mathematical-function collapse, the repair is incomplete.

#Repair assignments

#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, or flow or transduction descriptions.

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 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 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 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 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."
  recoveredFpFKind: ModuleAllocationRelation | InterfaceSpecification
Quality compositionality:
  "The assembled whole preserves safety, latency, or reliability."
  recoveredFpFKind: QBundleSlot | structuralCharacteristicQBundleInputSlot | structuralCharacteristicCausalHypothesisForQBundleSlot | structuralCharacteristicEvidencePathForQBundleSlot
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"
liveUse: functionalArchitecture
recoveredFpFKind: FunctionalStructure
recoveredFpFReference: ArchitectureOf@Context with structureKindRef = FunctionalStructure
falseFpFKindRefs: 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 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 kind or relation 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.

#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 kind or relation assignment: say what FPF kind, relation, claim record, view, or governing-pattern application the phrase is about, what it is not about, and what move remains admissible.

This design follows A.6.P: trigger phrase, kind or relation recovery, explicit relation fields and governingPatternRef 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 FPF kind named by value, relation, claim record, view, or governing-pattern application and 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, E.10.ARCH, 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 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.TGA graph, path, and crossing discipline, 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)