#Capability and Functioning Whole Reidentification

B.2.4 · Stable · Part B holonic construction pattern · Normative unless a section is explicitly informative · Part B - Trans-disciplinary Reasoning 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: Part B holonic construction pattern Status: Stable Normativity: Normative unless a section is explicitly informative

Use this pattern when exact capability, functioning, or transformation-flow facts, already established under their direct owners, make a B.2 whole-reidentification question live.

#Relations

#Content

#Use This When

Use this pattern when exact capability, functioning, or transformation-flow facts, already established under their direct owners, make a B.2 whole-reidentification question live.

The first useful question is whether those facts can still be explained by the existing whole. If they can, keep that whole and use the direct capability, functioning, transformation, method, work, module, characteristic, or architecture owner. If they cannot, return the residual question to B.2. Evidence and measurement separately support, challenge, or leave unresolved the claims about those facts; they create neither the facts nor B.2 selection.

What goes wrong if missed. A genuine new whole is hidden under ordinary capability improvement; or every impressive capability, function, method chain, module allocation, or metric gain is overclaimed as emergence.

What this buys. The pattern keeps capability and functioning facts available to B.2 while preserving the separate evidence relation and preventing B.2.4 from becoming a generic capability, function, method, work, module, or emergence pattern.

Not this pattern when.

• If the claim is ordinary capability, use A.2.2 and C.16.
• If the claim is function-like wording or functioning relation without whole reidentification, use A.6.F.
• If the claim is transformation or transformation-flow structure, use A.3.4, E.18, and C.30.TFS-REL.
• If the claim is method, method relation, method description, work plan, or work occurrence, use A.15, A.3.1, A.3.2, A.15.2, and A.15.1.
• If the claim is module allocation or bearer allocation, use A.6.M and architecture owners.
• If the claim is measurement, threshold, score, robustness, quality, or whole-level characteristic, use C.16, A.19, and evidence owners.
• If the wording is ambiguous emergence, synergy, or title-mnemonic language, use B.2.P before selecting B.2.4.

#Problem Frame

A new capability is not automatically a new whole. A function-like relation is not automatically a part-whole relation. A transformation-flow structure is not automatically MHT.

B.2.4 is the narrow B.2 specialization for cases where exact capability, functioning, or transformation-flow facts defeat the existing-whole explanation and point to a candidate new holon. Evidence bears on claims about those facts; it does not make the explanation fail by itself.

#Problem

Without this specialization:

1. Capability becomes generic emergence. A threshold crossing or new envelope is treated as a new whole without B.2 checks.
2. Function becomes ontology. Function-like wording creates U.Function or a hidden peer kind.
3. Method and work collapse. The way of doing, description of doing, planned work, and performed work are compressed into one vague operational claim.
4. Module allocation becomes functional truth. A module label is treated as evidence for the required behavior or selected structure.
5. Transformation-flow description replaces in-life structure. A graph, diagram, or publication of a flow is treated as the flow structure or whole.
6. Whole reidentification is missed. A real result whole is left as "just a better capability".

#Forces

#Solution

Use B.2.4 as a decision bridge from direct capability and functioning facts to B.2 whole reidentification. Add no generic slice, context placeholder, candidate-bearer list, or second B.2 record.

#Start From Exact Facts, Claims, And Support

1. Name the exact existing whole and its direct identity or reidentification rule.
2. Identify each exact capability envelope, obtaining functioning relation, or selected in-life transformation-flow structure under its direct owner. Keep method, method description, work plan, work occurrence, module allocation, characteristic, and architecture facts separate when they are current.
3. State the exact claim made about those facts. Name evidence or measurement only as a separate relation that supports, challenges, or leaves that claim unresolved.
4. Apply B.2's ExistingWholeExplanationCheck. Better measurement, component improvement, method or work repair, allocation repair, or architecture-view repair can leave the same whole in place.
5. If a residual whole-reidentification question remains, return it to B.2. B.2 then identifies one exact candidate new whole, applies the complete A.1 and kind-specific criteria, and compares that candidate with the existing whole.

B.2.4 adds no result species. If a receiving use needs a durable account, use B.2's optional C.2.1 epistemes; their content neither creates the direct facts nor selects the new whole.

#Direct-Owner Test

Before returning to B.2, test whether the exact facts are already explained under a direct owner:

#Existing-Whole Explanation

Use B.2's ExistingWholeExplanationCheck before claiming whole reidentification.

Direct-owner explanations that often stop B.2.4 include:

• better measurement or benchmark normalization;
• improved component capability;
• corrected function-like wording;
• a clearer method relation or method family selection;
• a new method description without corresponding in-life capability or work facts;
• better work coordination inside the same whole;
• module allocation repair;
• architecture-view or transformation-flow-structure repair;
• better evidence, measurement, or source currentness for an unchanged world-side claim.

If one of these explanations is sufficient, do not use B.2.4. Use the direct owner.

#When B.2.4 Returns To B.2

Return to B.2 when the exact direct facts show that the existing whole cannot carry the current subject claim and an exact candidate new whole must be tested. Examples:

• a production cell has an exact capability envelope, obtaining coordination and functioning relations, a selected in-life transformation-flow structure, and external commitments that cannot be explained by individual machines or the old aggregate;
• a service platform has an obtaining functioning relation and external commitments that cannot be assigned to one service or module;
• a team, toolchain, and method family participate in exact coordination and work facts that make a result-system candidate live; or
• a candidate episteme has exact constitution and explanatory-use facts that leave an episteme whole-reidentification question.

After the return, B.2 owns the existing-whole/new-whole comparison, its one exact candidate, and any optional record. B.2.4 adds no result record or evidence slice. The direct facts keep their owners, and evidence or measurement remains support for the associated claims.

#Archetypal Grounding (Worked Cases)

#Bias-Annotation

#CI/CD Capability

A team may have methods for coding, testing, and releasing. That does not by itself create a new whole. Use method and work owners for the method relations and performed release work.

B.2.4 becomes current only if exact capability, coordination, commitment, and work facts leave a result-holon question that the existing team or platform cannot explain. Evidence may support that claim; an automated delivery label or score does not decide the ontology.

#Theory Explains New Phenomena

A new theory may explain phenomena that the source portfolio did not explain. B.2.4 can route the exact explanatory-capability fact into the existing-whole check, while evidence separately supports or challenges its claim. B.2.3 owns the episteme-result specialization if the exact candidate is U.Episteme; C.2.1 owns its constitution; C.29 owns any mathematical-lens use.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• Exact capability and functioning facts can make real whole reidentification current, while evidence bears only on the associated claims.
• Direct owners remain visible, so local improvements are not overclaimed.
• Method, work, function, module, and architecture distinctions survive high-pressure capability language; each claim remains with its governing pattern.

Costs:

• Teams must do the direct-owner test before using B.2.4.
• Many impressive capability claims will stay outside MHT.
• B.2.4 depends on B.2 for the final whole-reidentification record.

#Rationale

Capabilities and functioning relations are often where a new-whole question first becomes visible. Their direct facts, not the availability of supporting evidence, determine whether the existing-whole explanation still works.

B.2.4 keeps this mixed situation disciplined. It does not rename the capability, functioning, transformation flow, method, work, allocation, measurement, or support as "meta-function". It asks whether the exact direct facts defeat the existing-whole explanation and, only then, returns the residual question to B.2.

#SoTA-Echoing

#Relations

• Specializes: B.2 for cases where exact capability, functioning, or selected in-life transformation-flow facts leave a whole-reidentification question after direct-owner explanations are tested.
• Uses: B.2.P when emergence-family or title-mnemonic wording hides the claim kind.
• Coordinates with: A.2.2, C.16, A.6.F, A.3.4, E.18, C.30.TFS-REL, A.15, A.3.1, A.3.2, A.15.2, A.15.1, A.6.M, C.30, A.22, C.30.ASV, C.29, A.10, and source-use patterns.
• Contrasts with: B.2.2 for system-result MHT and B.2.3 for episteme-result MHT.

#B.2.4:End

---

Last Updated: 2026-08-04 — upstream FPF commit 67092138 (github.com/ailev/FPF)