#Part B — Trans-disciplinary Reasoning Cluster

Preface node heading:part-b-trans-disciplinary-reasoning-cluster:35026

#What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

#Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

#Content

#Holon Aggregation and Part-Whole Construction

Type: Part B holonic construction pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Use This When

Use this pattern when a project needs to say how several admitted objects are considered as a whole, or when a whole-level claim depends on parts, membership, component structure, constructional grounding, or a selected aggregation rule.

Typical moments:

• a product, plant, dataset, paper, model family, organization, fleet, batch, or research program is discussed as a whole;
• a dashboard rolls part measurements into a whole-level characteristic;
• a team says that a method, role, graph, or algebra "decomposes" something and may be smuggling part-whole claims;
• a collection needs whole-level characteristics without becoming an acting collective system;
• an aggregation claim is being used for architecture, assurance, evidence, or MHT reasoning.

First useful move. Recover the claim kind before choosing notation: part-whole construction, membership, collection-as-whole grounding, role relation structure, method relation structure, work occurrence holarchy, selected architecture structure, or mathematical description.

What goes wrong if missed. Γ, graph, algebra, decomposition, factor, component, step, phase, and collection wording become one universal composition language. Roles and methods become parts; work occurrence evidence is inferred from method structure; a graph is mistaken for the structure; a collection becomes an acting whole by label.

What this buys. B.1 gives one doorway into part-whole construction while keeping its neighbors clean: A.14 owns relation vocabulary, C.13 owns constructional grounding, B.3.5 owns Working-Model assurance grounding, A.15.1 owns work-occurrence holarchy, and C.29 owns mathematical-lens use.

Not this pattern when.

• If the question is the local relation word, use A.14.
• If the question is constructive part-whole grounding, use C.13.
• If the question is assurance grounding for a working model, use B.3.5.
• If the question is role or method relation structure, use the role or method owner and C.29 when a mathematical lens is relied on for the current claim.
• If the question is performed-work occurrence parts, use A.15.1.
• If the question is whole reidentification or emergence-family wording, use B.2 or B.2.P.

#Problem Frame

B.1 is not a universal algebra pattern. It is the holonic construction doorway for part-whole and collection-as-whole claims.

The older Γ material remains useful only after the ontology-side claim has been recovered. Γ, graph, algebra, tuple, matrix, embedding, and neural representation can express or check a selected structure; they do not decide by spelling that the current object is a holon, that the relation is parthood, or that a role, method, step, or work occurrence is a part of a holon.

#Problem

Without B.1:

1. Mereology and notation collapse. A graph or algebra is treated as the part-whole structure itself.
2. Roles and methods become parts. Role factors, method parameters, guards, steps, and compositions are read as holonic parts because the same word "decomposition" appears.
3. Work occurrence is inferred from plan. A method decomposition or schedule is treated as evidence that performed work had those parts.
4. Collections become acting systems. A set, list, batch, fleet, or community receives agency, responsibility, or capability without A.1 and role-method-work admission.
5. Emergence becomes rhetoric. A whole-level gain is explained by "synergy" or "more than the sum" without checking existing-whole explanations or B.2 whole reidentification.

#Forces

#Solution

Use B.1 as a discriminator and construction frame.

#Holon Aggregation Claim Frame

When part-whole construction is current, recover:

HolonAggregationClaim@Context:
  candidateWholeRef: U.Holon
  candidatePartRefs:
  boundedContextRef:
  identityOrRecognitionRule:
  partRelationRefs:
  constructionBasisRef?
  selectedStructureRef?
  wholeLevelCharacteristicRefs?
  assuranceGroundingRef?
  neighboringNonPartRelationRefs?
  mathLensOrRepresentationRef?

This is a claim frame, not a U-kind and not an acting record. It says what must be named before the aggregation claim is relied on.

Use:

• [A.14](/generated/patterns/A.14) for ComponentOf, ConstituentOf, PortionOf, PhaseOf, MemberOf, aspect, and related vocabulary;
• [C.13](/generated/patterns/C.13) for constructional grounding such as sum, set, slice, or another accepted construction;
• [B.3.5](/generated/patterns/B.3.5) when a working model relies on the part-whole claim for assurance or evidence;
• [C.16](/generated/patterns/C.16) when the current output is a whole-level characteristic;
• [A.1](/generated/patterns/A.1) and [A.15](/generated/patterns/A.15) when the whole is claimed to be an acting collective system.

#Didactic Firewall

#Work Occurrence Holarchy

Performed work is different from structural composition.

A work occurrence can have temporal parts, episode parts, operational parts, concurrent sub-runs, retries, resource roll-ups, and effect composition. That is a work-occurrence holarchy governed by A.15.1, not evidence that the method or role expression is a holonic part-whole structure.

Use A.15.1 when the claim needs occurrence identity, temporal coverage, Gamma_time, Gamma_work, episode policy, overlap policy, resource aggregation, or performed-work evidence.

#Mathematical And Representation Apparatus

Use Γ, graph, algebra, tuple, matrix, embedding, or neural representation only after the object under concern and selected relation are named.

Acceptable uses:

• a mathematical lens for a selected structure;
• a constructional expression for a part-whole claim already admitted by A.14 and C.13;
• a representation of dependency relations;
• a checking apparatus for invariants or conservative bounds.

Blocked uses:

• graph wording as parthood admission;
• algebraic factorization as role, method, or work parthood admission;
• source notation as a new U-kind;
• one fold rule as a universal replacement for the direct owner.

#Existing-Whole Before MHT

Before declaring B.2 whole reidentification, ask whether the whole-level gain can be explained inside the existing whole:

• better parts;
• corrected part relation;
• improved measurement;
• role or method relation repair;
• work occurrence evidence repair;
• functional or architecture selected-structure repair;
• source, publication, or representation correction.

Use B.2 only when the whole itself must be reidentified.

#Archetypal Grounding (Worked Cases)

#Bias-Annotation

#Evidence Corpus

A corpus can be a collection-as-whole under MemberOf and C.13 set construction. Its whole-level characteristics may include coverage, source freshness, bias exposure, or evidential diversity.

The corpus does not become an acting system. A review board, script, or research team may be an acting system in role. The corpus may be an episteme or publication-side object under direct owners.

#Method With Steps

A machining method has ordered steps and parameters. Those steps are method relation or method-description material. They do not prove that a performed machining run occurred, nor that the run had the same parts.

If the current claim is the method structure, use method owners and C.29 when algebra is selected. If the current claim is the actual run, use A.15.1.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• B.1 can still use useful aggregation apparatus without letting apparatus choose the ontology.
• Holonic part-whole claims become reviewable.
• Role, method, work, math-lens, and publication descriptions stop leaking into mereology.
• B.2 has a cleaner entry condition: whole reidentification, not ordinary improvement rhetoric.

Costs:

• Users must identify the claim kind before choosing a notation.
• Some Gamma-heavy examples require a direct owner before the notation is used: work occurrence evidence uses A.15.1, work-resource aggregation uses B.1.6, mathematical-lens reliance uses C.29, and whole reidentification first uses B.2.P and then B.2 when the problem remains current.
• Work occurrence analysis requires evidence and timing, not just a method plan.

#Rationale

The practical force of B.1 is conservative. Whole-level reasoning is useful, but it must be grounded in accepted part-whole relations, constructional discipline, and direct pattern ownership. This lets FPF speak across physical systems, epistemes, work occurrences, bounded contexts, disciplines, and collections without growing a new type for every composed expression.

Mathematical apparatus remains available. It becomes more useful after the governed object is known: graph for dependency representation, algebra for selected composition rules, tuple for slot relation expression, matrix or embedding for analysis, and C.29 when a mathematical lens is relied on for the current claim.

#SoTA-Echoing

#Relations

• Builds on: A.1 for holon admission, A.14 for relation vocabulary, C.13 for constructional grounding, and B.3.5 for Working-Model assurance grounding.
• Coordinates with: A.15 and A.15.1 for method and work, A.22 and C.30 for selected structure and architecture, C.16 for whole-level characteristics, C.29 for mathematical lenses, and B.2 for whole reidentification.
• Refined by: B.1.1, B.1.2, B.1.4, and B.1.6 for selected dependency, system aggregation, contextual-temporal aggregation, and work-resource aggregation cases.

#B.1:End

#Dependency Structure and Relation Grounding

Type: Part B holonic construction pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Use This When

Use this pattern when an aggregation, architecture, assurance, or construction claim depends on how candidate parts, members, phases, portions, or external relations depend on each other.

Typical moments:

• a dependency diagram is used to justify a whole-level claim;
• a graph mixes parthood, mapping, order, time, resource, and boundary-crossing relations;
• a project needs to know whether a relation is part-whole, dependence, representation, influence, source use, publication use, or evidence relation;
• a selected dependency structure will be expressed with a graph, table, matrix, or another mathematical or representation lens.

First useful move. Name the dependency relation under concern before choosing graph notation. Then decide whether the relation is part-whole, boundary crossing, order, temporal phase, resource relation, mapping, evidence, publication use, source use, or another directly governed relation.

What goes wrong if missed. A graph becomes the ontology; an edge named "depends on" carries many relation kinds at once; external influence becomes parthood; order and time are encoded as structure; and mathematical checks look precise while the relation being checked remains unclear.

What this buys. B.1.1 lets dependency material bear on B.1 aggregation without letting graph notation decide relation kinds.

Not this pattern when.

• If the current relation word is a mereology question, use A.14.
• If the current part-whole claim needs constructional grounding, use C.13.
• If the current object is architecture selected structure, use A.22 and C.30.
• If the current expression is mathematical-lens choice, use C.29.
• If the current question is performed work, use A.15.1.

#Problem Frame

B.1.1 separates dependency structure from graph representation.

A dependency structure can be ontology-side when a direct pattern has selected the relation under concern. A dependency graph is a mathematical or representation description of that selected relation structure. The graph may be useful, but it is not the holon, not the part-whole relation, and not the constructional grounding by itself.

#Problem

Without B.1.1:

1. Edge drift spreads. ComponentOf, MemberOf, PhaseOf, SerialStepOf, RepresentationOf, source use, evidence relation, and control relation all become generic graph edges.
2. Boundary crossing becomes parthood. A power grid, supplier, teacher, measuring instrument, model, or source record is drawn as a part because it affects the holon.
3. Design and run objects mix. Planned structure, design description, actual work occurrence, and telemetry are placed in one dependency expression without a DesignRunTag or owner distinction.
4. Acyclic graph discipline overclaims. A graph check says something about the drawing, but the ontology-side relation remains ungrounded.
5. Mappings become parts. A digital twin, dashboard, diagram, or architecture description is treated as a constituent of the object it describes.

#Forces

#Solution

Use dependency structure first; use graph representation second.

#Dependency Structure Frame

DependencyStructure@Context:
  structureUnderConcernRef:
  boundedContextRef:
  candidateNodeRefs:
  dependencyRelationRefs:
  partWholeRelationRefs?
  boundaryCrossingRelationRefs?
  orderRelationRefs?
  temporalRelationRefs?
  resourceRelationRefs?
  representationRelationRefs?
  evidenceRelationRefs?
  publicationOrSourceUseRefs?
  designRunTag?
  directOwnerRefs:

This frame is not a U-kind. It records which relation claims are current and which direct owners govern them.

#Graph Representation

Use graph language only when a graph is the selected mathematical or representation lens:

DependencyGraphRepresentation@Context:
  representedDependencyStructureRef:
  nodeExpression:
  edgeExpression:
  graphPropertyChecks?
  mathLensRef?
  publicationOrViewRef?

The graph may express acyclicity, reachability, cutsets, weak links, flow, or traceability. Those checks apply to the graph expression and bear on the selected relation only when the relation owner admits the mapping.

#Relation Grounding Guide

#Graph Checks Are Conditional

Acyclicity, topological order, cutset, reachability, and flow checks are useful only after the graph is selected as a lens over a selected relation structure.

Do not infer:

• parthood from graph adjacency;
• independence from graph separation without relation-owner admission;
• performed work from a planned step graph;
• whole reidentification from a graph property without B.2;
• architecture from a graph without selected-structure and architecture owners.

#Archetypal Grounding (Worked Cases)

#Bias-Annotation

#Digital Twin

Source graph: DigitalTwin -> Turbine.

If the edge means representation, recover the architecture-description, publication, source-use, evidence, or digital-twin relation. The digital twin is not a turbine component by graph adjacency.

#Work Plan And Work Occurrence

Source graph: Prep -> Weld -> Paint.

If the graph describes a method or process view, use the method and order owners. If the graph describes performed work, use A.15.1 with occurrence identity, timing, evidence, and work-part relation. Do not let the same graph do both jobs.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• Dependency views become useful without becoming hidden ontology.
• External influences can be discussed without corrupting parthood.
• Graph checks keep their value and their limits.
• B.1 aggregation receives cleaner part-whole inputs.

Costs:

• A diagram alone is no longer enough; relation kinds and owners must be named.
• Some compact dependency graphs need multiple relation layers or views.
• Graph-based checks may need C.29 when the mathematical lens is relied on.

#Rationale

Dependency language is useful exactly because it is broad. That breadth is also the danger. FPF keeps the breadth for recognition, then restores precision by separating relation kinds, selected structures, mathematical expressions, and publication forms.

B.1.1 therefore does not abolish dependency graphs. It makes them honest: a graph represents a selected relation structure; relation grounding comes from the direct owners.

#SoTA-Echoing

#Relations

• Builds on: B.1, A.1, A.14, C.13, and A.6.5.
• Coordinates with: A.15.1 for work occurrence, B.1.4 for contextual and temporal aggregation, C.29 for graph as mathematical lens, A.22 and C.30 for selected structure and architecture, C.30.AD and C.30.AD.BA for architecture description and digital-twin cases.
• Can contribute evidence to: B.2 when dependency evidence bears on whole reidentification after existing-whole explanations fail.

#B.1.1:End

#System Aggregation and Holon Delimitation

Type: Part B holonic construction pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Use This When

Use this pattern when a physical, operational, organizational, cyber-physical, or socio-technical system is treated as a whole made from parts, and the aggregation claim depends on how the system is delimited from its environment.

Typical moments:

• a machine, plant, robot, vehicle, building asset, service organization, or operating unit is aggregated from components or subholons;
• a system-level characteristic is rolled up from component characteristics;
• an external signal, supply, measurement, control, source, or publication relation is being mistaken for a part;
• a functional element must be allocated to candidate physical or organizational bearers;
• a boundary-interface-compatibility check is needed for a system aggregate.

First useful move. Name the candidate system whole, the candidate part relations, and the holon delimitation relation. Then decide which crossing relations remain external, which become internal after aggregation, and which are represented in a view or publication.

What goes wrong if missed. System aggregation becomes a drawing exercise. Ports, suppliers, documents, digital twins, dashboards, source records, and measuring instruments become components by placement. Functional parts become physical parts by label. External change or measurement is read as containment.

What this buys. B.1.2 makes system aggregation usable for engineering while keeping part-whole, holon delimitation, boundary crossing, functional structure, module allocation, and mathematical expression distinct.

Not this pattern when.

• If the object is not an admitted U.System or candidate system, use A.1 first.
• If the question is generic part-whole vocabulary, use A.14.
• If the question is constructive grounding, use C.13.
• If the question is functional behavior or functional element, use A.6.F and architecture structural-view owners.
• If the question is module or bearer allocation, use A.6.M and architecture owners.
• If the question is a mathematical aggregation lens, use C.29.

#Problem Frame

B.1.2 specializes B.1 for system holons. It keeps the useful engineering concerns from system-specific aggregation: physical plausibility, system delimitation, external crossing relations, component integration, whole-level characteristics, and boundary-interface compatibility.

It does not make Gamma_sys the pattern head. It does not create generic boundary or interaction U-kinds. It does not say that a system changing another holon becomes the changed holon's super-holon.

#Problem

Without B.1.2:

1. Boundary by drawing. A box in a diagram is accepted as system delimitation.
2. External relations become parts. Suppliers, grids, sensors, controllers, teachers, measuring instruments, or digital twins are placed inside the system because they interact with it.
3. Functional and physical structures collapse. A resistor symbol, control function, chassis function, or service role is treated as a physical component by label.
4. Whole-level characteristics lack grounding. Mass, capacity, reliability, safety, throughput, assurance, or agency-like characteristics are rolled up without saying which part relations and scales are used.
5. Transformation becomes containment. A tool, teacher, actuator, script, or controller changes a holon and is then treated as that holon's containing whole.

#Forces

#Solution

Use B.1.2 to recover a system aggregation relation and its delimitation discipline.

#System Aggregation Relation

SystemAggregationRelation@Context:
  candidateSystemWholeRef: U.System
  boundedContextRef:
  identityOrRecognitionRule:
  componentRelationRefs?
  portionRelationRefs?
  phaseRelationRefs?
  memberRelationRefs?
  holonDelimitationRelationRef:
  externalBoundaryCrossingRelationRefs?
  internalizedBoundaryCrossingRelationRefs?
  functionalElementRefs?
  moduleOrBearerAllocationRefs?
  wholeLevelCharacteristicRefs?
  constructionBasisRef?
  evidenceRelationRefs?
  mathLensOrRepresentationRef?

This relation is not a U-kind and not the system itself. It states which relations must be named before a system aggregation claim is relied on.

#Delimitation And Boundary-Crossing

Use HolonDelimitationRelation@Context for the current system delimitation: identity rule, included parts, excluded environment, selected structure, and context boundary conditions.

Use HolonBoundaryCrossingRelation@Context or a direct owner for relations that cross that delimitation: material flow, energy flow, signal, control, measurement, source use, publication use, evidence relation, transformation, probe relation, supply relation, commitment relation, A.6.C contract-language unpacking, or coupling.

Do not recast crossing relations as parthood merely because the relation is important.

#Boundary-Interface Compatibility Check

When a system aggregate exposes or hides crossing relations, record the compatibility choice:

BoundaryInterfaceCompatibilityCheck@Context:
  systemAggregationRelationRef:
  crossingRelationRef:
  compatibilityDecision: expose | namespace | internalize | exclude | useDirectOwner
  ownerPatternRef:
  evidenceRelationRef?

This check is a system-aggregation aid, not a new ontology. It prevents silent loss of external obligations and unmanaged endpoint explosion.

#Whole-Level Characteristics

Roll up system-level characteristics only after the relation and scale are selected.

Useful families include:

• additive quantities such as mass, cost, energy stock, or material amount;
• limiting quantities such as pressure rating, weakest connector, safety class, or availability bottleneck;
• logical or capability claims such as emergency-stop availability or vulnerability exposure;
• architecture characteristics that depend on selected structure.

Use C.16, A.19, and C.29 when characteristic space, scale, threshold, or mathematical lens is relied on for the current claim. Use B.2 when redundancy, closure, or coordination creates or reveals a whole that must be reidentified.

#Functional Elements And Bearers

A functional element in a functional view is not automatically a system part.

Recover separately:

• functional behavior or functional element under A.6.F;
• physical, organizational, software, or operational bearer under A.6.M, A.14, C.13, and architecture owners;
• allocation or correspondence between function and bearer;
• system aggregation only when bearer parthood is independently admitted.

One bearer may realize several functions. One function may require several bearers. This is allocation and correspondence before it is part-whole.

#Archetypal Grounding (Worked Cases)

#Bias-Annotation

#Resistor In A Circuit

A resistor symbol in a circuit diagram is a functional or design-description element. The physical bearer may be a packaged resistor, a length of wire, a transistor region, or a module allocation. B.1.2 admits system aggregation only for the chosen physical or operational bearer relation, not for the symbol by label.

#Digital Twin Of A Building Asset

A BIM model, asset register, dashboard, or digital twin may describe the built asset and its systems. It is not the asset's part by being linked in a model. Use architecture-description, publication, evidence, source-use, and designation owners for the description side; use B.1.2 only for admitted system parts of the built asset.

#Lathe And Workpiece

The lathe can change the workpiece through a bounded transformation and work occurrence. That relation does not make the workpiece a lathe component, nor the lathe the workpiece's super-holon. Use A.3.4, A.15.1, A.12, and boundary-crossing owners before any part-whole claim.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• System aggregation remains practical for engineering systems and organizations.
• Boundary and interface concerns become explicit relation work without false U-kinds.
• Functional architecture, module allocation, and physical parthood stop collapsing into one diagram.
• Digital-twin and publication artifacts stay on the description side unless another direct pattern admits a stronger relation.

Costs:

• Engineering diagrams need relation-owner annotations when used for decisions.
• Some familiar component lists must be split into physical parts, functional elements, external systems, sources, and descriptions.
• Whole-level characteristic claims need scale and relation discipline.

#Rationale

System aggregation is the place where holonic thinking is most tempting and most useful. It is also where false parthood is easy: anything connected, measured, represented, or controlled can be drawn inside a system box.

B.1.2 preserves the engineering payoff while requiring holon delimitation, boundary-crossing relation discipline, and direct owners for function, module, characteristic, evidence, and publication claims.

#SoTA-Echoing

#Relations

• Builds on: B.1, A.1, A.14, C.13, and A.6.5.
• Coordinates with: A.6.F for functional elements, A.6.M for module and bearer allocation, A.22 and C.30 for selected structure and architecture, C.16 and A.19 for characteristics, C.29 for mathematical lenses, A.3.4 and A.12 for transformation and acting-side externalization, and C.30.AD or C.30.AD.BA for architecture-description cases.
• Can contribute evidence to: B.2 when system aggregation no longer explains the whole-level claim and whole reidentification is needed.

#B.1.2:End

#Γ_epist - Knowledge‑Specific Aggregation

► decided‑by: A.14 Advanced Mereology A.14 compliance — Use ConstituentOf for semantic parts; PortionOf only for quantitative splits of texts/data with declared μ (token/byte, etc.); PhaseOf for versions/revisions of MethodDescription/documents; no ComponentOf here.

Plain‑English headline. Γ_epist composes epistemic holons (claims, models, datasets, arguments) into a single episteme while preserving provenance, applying conservative trust bounds (B.3 F/G/R), and penalizing poor conceptual fit via congruence levels (CL). It is not a physical sum; it is a semantic and evidential fold.

#Problem frame

• Holonic foundation. In the FPF, a U.Episteme is a holon whose identity is knowledge‑bearing (A.1). It can be a statement/claim, a model, a theory, a specification, a dataset with semantics, or a compiled scholarly artifact.
• Strict Distinction (A.15). We separate: structure (what the episteme comprises), order (argument flow), time (versioning/phases), work (what was spent to produce/validate it), and values (objectives/criteria). Γ_epist stays in the structure/semantics lane and calls out to Γ_ctx/Γ_time/Γ_work when needed.
• Mereology (A.14). For knowledge composition we primarily use ConstituentOf (logical/semantic parts), UsageOf/ReferenceTo (external reliance), and MemberOf for collections (anthologies, corpora). We do not use ComponentOf (physical) in Γ_epist. PhaseOf handles temporal versions of the same episteme; RoleBearerOf is irrelevant here because knowledge does not play a role—it is used by a holon‑in‑role (Transformer) at run‑time (A.12).
• Assurance (B.3). Knowledge carries F, G, R (Formality, ClaimScope, Reliability). Integration edges carry CL (congruence level) that penalizes poor fit. Γ_epist must preserve provenance and apply conservative bounds: no “truth averaging,” no silent context hops. Obligations here are mode/assurance‑gated per C.2.1. # [M‑0]
• Order/time flavours. Argument sequences may need Γ_ctx (non‑commutative ordering of premises to conclusion). Knowledge evolution uses Γ_time (versioning, deprecation, update). When composition produces new closure or supervision (e.g., explanatory theory emerges), we declare MHT (B.2).

#Problem

Naive aggregation of knowledge holons causes recurring failures:

1. Trust inflation by averaging. Averaging confidences of conflicting claims creates a falsely “reliable” whole; violates WLNK and B.3 conservatism.
2. Provenance erasure. Merges that drop sources, methods, or links break A.10 Evidence Graph Referring and make results unauditable.
3. Semantic drift. Folding across mismatched concepts without explicit mappings (and their CL) yields incoherent composites that look formal but mean nothing.
4. Order blindness. Arguments with essential dependency order (premise ⇒ lemma ⇒ conclusion) are treated as sets; non‑commutativity is lost and results become non‑reproducible.
5. Context chimeras. Combining items across bounded contexts (different vocabularies/units/policies) without a Context Reframe (B.2) silently corrupts claims and inflates R.
6. Category errors. Importing Γ_sys rules (e.g., “sum truth,” “avg formality”) into knowledge composition produces physically sounding but epistemically nonsensical models.

#Forces

#Solution — Terms, operator family, invariant Standard, core rules

#Terms (didactic recap)

• U.Episteme — a knowledge holon. Internally read it as an EpistemeSlotRelation: EntityOfConcernSlot for what it is about, ClaimGraphSlot or theory/model structure for what it claims, GroundingHolonSlot where grounding is live, and SCR/RSCR carrier references for text, code, figures, or datasets.
• Evidence/Provenance Graph — edges like evidences, derivesFrom, usesMethod, isMeasuredBy with anchors (A.10).
• Mapping edge — a typed relation between conceptual vocabularies (e.g., ontology alignment, unit conversion) with a CL score (0…3/4 per A.15/B.3 convention).
• SCR — a U.SCR that lists all symbol carriers included in the aggregate; never dropped.
• Bounded context — a modelling Standard (vocabulary/units/policy). Crossing it requires Context Reframe (B.2) or explicit mappings with CL.

Didactic reminders. • Knowledge does not “act.” Transformers (A.12) use knowledge. • MemberOf creates collections; it is not a semantic argument link. Use ConstituentOf for logical/evidential composition. • PhaseOf is for versions of the same episteme; if identity, boundary, or context re‑anchor, declare MHT.

#The operator family (companion flavours)

To keep design vs run clean (A.15), Γ_epist has two companion flavours that share the same algebra but serve different moments:

1. Synthesis (design‑time) — fold epistemes into a draft aggregate

Γ_epist^synth : ( D_know : DependencyGraph< U.Episteme >,
                  TA     : U.RoleAssignment[roleRef = TransformerRole@Context] ) → U.Episteme

• Domain. D_know uses ConstituentOf, UsageOf/ReferenceTo, evidences/derivesFrom, optional MemberOf for collections.
• Result. A composite episteme whose Object/Concept/Symbol components are assembled; provenance and SCR are preserved; F/G/R/CL are provisionally computed for later assurance. Gating: at M‑mode only tuple placeholders are required; numeric scoring may be omitted ([M‑0/M‑1]). At F‑mode the tuple MUST be computable in‑Context ([F‑*,L1+]). # [M/F]

2. Compile (run‑time) — produce the released artifact in a bounded context

Γ_epist^compile : ( E_synth : U.Episteme,
                    Ctx     : BoundedContext,
                    TA      : U.RoleAssignment[roleRef = TransformerRole@Context] ) → U.Episteme

• Domain. A synthesized episteme and a target context (journal, standard, program spec).
• Result. A context‑anchored episteme (e.g., published paper/spec) whose mappings to the context vocabulary are explicit and carry CL; assurance will reference this context baseline (B.3).

Relationship to Γ_ctx / Γ_time. If the knowledge fold explicitly depends on argument order (e.g., derivation), the internal fold uses Γ_ctx for the sequence. If a temporal storyline (updates, retractions) is important, use Γ_time to slice versions; Γ_epist then composes the current slice. If composition yields new explanatory closure beyond WLNK/CL, declare MHT (B.2).

#Invariant Standard (how the Quintet applies; math by level)

• IDEM (Idempotence). Folding a single episteme returns itself; no accidental “upgrade.”
• COMM/LOC (Local commutativity / locality). For independent subgraphs (no logical/evidential dependency), fold order/location is irrelevant; when dependencies exist, Γ_ctx controls order explicitly.
• WLNK (Weakest‑link bound). Aggregate Reliability (R) is bounded by the weakest supported link along any justification path, after considering the lowest CL on mappings used by that path.
• MONO (Monotonicity). Strengthening a part (raising R with valid evidence or raising CL on a needed mapping) cannot lower aggregate R. Adding contradictory evidence is not an improvement; it triggers conflict handling (below), not MONO.

2. Reliability fold. Along any support spine, R_raw = min_i R_i; apply congruence penalty Φ(CL_min) → R_eff = max(0, R_raw − Φ(CL_min)). No averaging; weakest‑link. Math by level: – [M‑0/M‑1] allow ordinal comparisons only (no arithmetic on R); Φ may be stated qualitatively (“low/med/high”). – [M‑2/L1] require numeric Φ table (default in §4.4) and reproducibility tag on empirical edges. – [F‑*,L1/L2] require formal derivability of the fold rules from LOG‑CAL; constructive mode annotates proof.kind=constructive. # [M/F]

#Core rules for epistemic aggregation (design‑time synthesis)

When computing Γ_epist^synth(D_know, T):

1. Provenance preservation. The provenance/evidence graph is unioned with de‑duplication; every claim in the aggregate remains traceable to its sources and methods. No source, method, or dataset that supports a retained claim may be dropped.

2. SCR construction. Build a U.SCR that lists all symbol carriers (texts, code, figures, datasets) that materially participate in the aggregate. Provenance nodes must be mappable to SCR entries.

3. Object alignment. Determine a common Object via domain taxonomy (e.g., least common ancestor) or create a U.CompositeEntity with explicit mappings. Record CL for each mapping; do not silently merge homonyms.

4. Concept integration with CL penalty. Compute provisional F/G/R of the aggregate:

   • F_eff = min(F_i) (formality is as strong as the least formal constituent actually used).
   • G_eff = function of coverage; typically monotone in included scope, capped by weakest definitional fit.
   • R_eff = min over justification paths of { R_i along the path } penalized by the lowest CL used by that path: R_eff := max(0, min_path( min_claimR(path) − Φ(CL_min(path)) )), where Φ is the normative penalty function defined below. If a mapping with CL < threshold is essential to a path, mark the claim provisional.

5. Normative Penalty Function Φ (v1.0) The penalty function Φ quantifies the loss of reliability due to poor conceptual alignment between parts.

A domain profile MAY provide an alternative table but MUST preserve monotonic decrease (a lower CL cannot have a smaller penalty). The default values are derived from empirical fits in KD-CAL Bench 0.3.

6. Conflict detection (no averaging). Detect contradictions (e.g., p and ¬p with overlapping scope). Do not average. Either (i) separate by context or scope (bounded contexts; Γ_time slices), (ii) mark provisional with explicit conflict edges, or (iii) if resolution yields new closure, consider MHT.

7. Handling of Axiomatic vs. Postulative Epistemes In alignment with ADR-028, the computation of R_eff depends on the episteme's declared mode.

• For an input episteme E_i with mode: axiomatic, empirical R is N/A; take R_i_eff = F_i. Tag: line=formal. # [F‑*]
• For mode: postulative, use declared R_i with decay; Tag: line=empirical. # [M‑1/M‑2/F]
• The aggregate E_eff MUST also declare a mode. If all inputs are axiomatic, the output is axiomatic. If any input is postulative, the output MUST be postulative.
• Constructive note. Under F‑constructive, equivalence claims use isomorphism/equivalence in the chosen UF library; CL=2 means proof‑reconstructed alignment, not mere model‑theoretic appeal. # [F‑constructive]

7. Order‑aware arguments (optional). If the argument requires premise ordering, embed a Γ_ctx fold inside Γ_epist; record the OrderSpec for reproducibility (NC‑1..3). Gating: OrderSpec is recommended at M‑1 and required at M‑2/F. # [M‑1→F]

8. No costs here. Any compute/collection effort is Γ_work; attach references but do not mix costs into epistemic aggregation.

#Core rules for compilation (run‑time context anchoring)

When computing Γ_epist^compile(E_synth, Ctx, T):

1. Context bindings. # [M‑1+] Map all operative concepts/units/claims into Ctx; record mappings and their CL. If the rebase changes boundary/objective of the episteme (e.g., from descriptive compendium to explanatory theory with commitments), declare Context Reframe (MHT) per B.2.

2. Assurance baseline (gated). Recalculate the assurance tuple (B.3) in Ctx: F and R may change with formalization and mapping penalties; G is re‑expressed in Ctx’s scope. Gating:

• [M‑0] narrative justification only;
• [M‑1] qualitative tuples allowed;
• [M‑2/L1] numeric tuple required;
• [F‑*/L2] tuple and proof obligations on weight/penalty model selection. # [M/F]

3. Release SCR. Produce RSCR with carrier hashes; at L2 require independent re‑hash verification. # [M‑1/L2]

4. Order/time hooks. If the compiled artifact includes an internal derivation, carry the OrderSpec; if it codifies a specific time slice of evolving knowledge, link back to the Γ_time slice used.

#Archetypal grounding (worked, didactic)

#Episteme — Meta‑analysis into a guidance statement

• Inputs (U.Episteme): E₁ randomized trial (R=0.84, F=3, G=medium), E₂ observational study (R=0.55, F=2, G=wide), E₃ mechanistic model (R=0.60, F=3, G=narrow). Mappings: dosage units (mg ↔ IU), outcome definitions (pain scale variants), each with declared CL (e.g., unit mapping CL=3, outcome alignment CL=2).

• Γ_epist^synth:

  • Provenance preservation: all study protocols, datasets, analysis scripts listed in the SCR.
  • Object alignment: “acute low‑back pain within 6 weeks” via taxonomy LCA; non‑aligned chronic cohorts excluded or mapped with low CL and flagged.
  • Concept integration: compute provisional R_eff along each justification path, penalized by **Φ(CL_min(path)); aggregate R_eff` = min over paths.
  • Conflict handling: E₂ contradicts E₁ in a subgroup; kept as provisional with explicit conflict edge and scope note (different baseline severity).

• Γ_epist^compile (journal context): Map outcomes to journal’s required measure, recalc F/G/R with mapping penalties; produce release SCR (hashes, versions) and context baseline. Result: “Guidance Statement v1.0” with conservative R.

• Why not averaging? Averaging would inflate R and hide low‑CL outcome mappings; Γ_epist enforces pathwise min + CL penalty.

#Episteme — Safety case from heterogeneous evidence

• Inputs: requirement spec (F=3, R=0.7), hazard analysis (F=2, R=0.6), test logs (F=1, R=0.8), formal proof of controller property (F=3, R=0.9).

• Γ_epist^synth:

  • Provenance union; SCR includes requirements, proof carrier, test datasets.
  • Concept integration: controller proof applies only under assumptions A; test logs violate A in edge case → CL low for mapping “test scenario ≡ proof assumption.”
  • R_eff bounded by the weakest justification path after Φ(CL_min); claim on “system‑level safety” marked provisional until assumption alignment is demonstrated.

• Γ_epist^compile (certification context): Context re‑base to regulatory vocabulary; if the re‑base changes objective/boundary (e.g., from internal assurance to public certification), consider MHT (Context Reframe) per B.2.

#Contrast (didactic)

#Proof obligations (normative)

At synthesis (Γ_epist^synth):

1. PO‑SYN‑PROV. The provenance/evidence graph MUST be preserved (union with de‑duplication); every retained claim is traceable to sources/methods in the SCR.
2. PO‑SYN‑OBJ. The Object MUST be identified (single subject via LCA or explicit U.CompositeEntity) with declared mappings and their CL.
3. PO‑SYN‑CL. All mapping edges that bridge semantics/units MUST carry CL; the chosen penalty Φ MUST be monotone in CL (lower CL ⇒ higher penalty). Thresholds for marking provisional MUST be stated.
4. PO‑SYN‑R. R_eff MUST be computed as min over justification paths of (claim reliabilities along the path minus Φ(CL_min(path))). No arithmetic mean is allowed for reliability.
5. PO‑SYN‑CONFLICT. Contradictions MUST be either (i) separated by context/scope, (ii) marked as provisional with explicit conflict edges, or (iii) escalated to MHT if resolution yields new explanatory closure.
6. PO‑SYN‑ORDER. If order matters, the OrderSpec MUST be recorded and Γ_ctx NC‑1..3 (determinism, context hash, partial‑order soundness) MUST hold.
7. PO‑SYN‑NOWORK. Resource spending, yields, and dissipation MUST NOT be computed here; instead, attach references to the aligned Γ_work composition.

At compilation (Γ_epist^compile):

1. PO‑COMP‑CTX. The target bounded context MUST be declared; all active concepts MUST be mapped with CL; context vocabulary/units recorded.
2. PO‑COMP‑ASSUR. The assurance tuple (F/G/R) MUST be recomputed in the target context with the applied CL penalties.
3. PO‑COMP‑REL. A release‑grade SCR (hashes, versions, dates) MUST be produced.
4. PO‑COMP‑MHT. If the compilation re‑anchors boundary, objective, or identity (e.g., from compendium to explanatory theory), an MHT (Context Reframe) MUST be declared with a Promotion Record (B.2).
5. PO‑COMP‑ORDER/TIME. If derivational order or a specific time slice is essential, the OrderSpec and the Γ_time slice MUST be referenced.

#Conformance Checklist (normative)

#Anti‑patterns & repairs

#Consequences

Benefits

• Auditability by construction. Every retained claim remains tied to its sources; SCR guarantees reconstructability.
• Safe synthesis. R cannot be inflated; CL penalties make conceptual misfit explicit.
• Context‑aware releases. Compiled epistemes or publications are aligned with a declared context; cross‑context reuse is principled.
• Didactic clarity. Separates semantic folding (Γ_epist) from order (Γ_ctx), time (Γ_time), spend (Γ_work), and emergence (B.2).

Trade‑offs

• Mapping overhead. Declaring mappings and CL costs time; it prevents silent incoherence.
• Conservative stance. Results may look pessimistic; this is deliberate (WLNK). Use MHT only for genuine explanatory closure.

#Rationale (informative)

• Epistemic composition is not physical addition. Reliability must be bounded by the weakest justified path, not averaged; conceptual misalignment must reduce confidence, not be ignored.
• Provenance is part of meaning. Dropping sources/methods changes what the episteme is; Γ_epist treats provenance and SCR as first‑class.
• Context matters. Bounded contexts structure practice; formal Context Reframe (MHT) prevents quiet re‑interpretations of claims.
• Parsimony with power. A small set of rules (provenance preservation, CL‑penalized pathwise min, order/time hooks, context discipline) is enough to model scientific and engineering knowledge without importing domain‑specific tool jargon.

#Relations

• Builds on: A.12 (Transformer Role—compilers/editors enact), A.14 (Mereology Extension—ConstituentOf/MemberOf/PhaseOf usage), A.15 (Strict Distinction).
• Coordinates with: B.1.1 dependency-structure and relation-grounding checks, B.1.4 (Γ_ctx/Γ_time inside knowledge folds), B.1.6 (Γ_work for compute/collection spend).
• Triggers/Complements: B.2 (MHT) when explanatory closure or context re‑base creates a new whole (theory, standard).
• Used by: B.3 assurance uses F/G/R and CL baselines computed here as inputs to trust calculations.

One‑sentence takeaway. Γ_epist preserves provenance, penalizes poor conceptual fit, forbids reliability averaging, and makes context explicit—so that knowledge aggregates are conservative, auditable, and genuinely coherent.

#B.1.3:End

#Contextual and Temporal Aggregation

Type: B-family aggregation pattern Status: Stable Normativity: Normative unless explicitly marked informative

Use this when. Use this pattern when the current claim aggregates relations across a bounded context, ordered situation, phase set, or time window, and the question is not just ordinary part-whole construction. Typical cues are ordered steps, order-sensitive argument chains, version histories, asset histories, phases of one carrier, rolling windows, context-scoped roll-ups, or time-sliced evidence.

Not this pattern when. If the question is ordinary part-whole or collection admission, use B.1, A.14, and C.13. If the question is the method as such, method description, work plan, or dated work occurrence, use A.3.1, A.3.2, A.15.2, or A.15.1. If the question is work-resource accounting, use B.1.6. If the question is changed identity, use A.3.4; if a new whole must be reidentified, use B.2 through B.2.P. If the question is temporal adequacy of a claim, use C.27.

What goes wrong if missed. Order, phase, context, or time-window wording becomes ordinary parthood, method order, performed work, evidence currentness, or whole reidentification by label.

What this buys. The practitioner can aggregate context-sensitive and temporal material while returning method, work, transformation, work-resource, temporal-adequacy, and MHT claims to their direct owners.

#Problem Frame

Many useful aggregates are not simple unordered wholes. A manufacturing sequence changes meaning when steps are swapped. An argument chain depends on which premise is used before which lemma. A turbine, paper, or dataset may be considered as the same carrier across phases. In these cases the aggregation is about contextual order or temporal coverage, not about a new level, a generic boundary, or a hidden interaction kind.

B.1.4 governs the aggregation claim. It asks which EntityOfConcern is being aggregated, which context or time window bounds the claim, which ordered or phase relation is being used, what the aggregate may be used for, and which neighboring owner must carry stronger claims.

#Problem

Without this pattern, four errors recur. First, SerialStepOf or another ordered relation is read as ordinary parthood, so changing the order looks harmless even when the aggregate meaning changes. Second, a phase label is read as a new holon level or a new whole, so identity change is hidden instead of handled by whole reidentification. Third, design-time plans, possible method order, run-time histories, and evidence windows are folded together as one sequence. Fourth, mathematical order, graph, or operator notation starts to govern the in-life object instead of expressing a recovered relation for one bounded use.

The practical failure is not a missing diagram. It is an inadmissible aggregate: the user cannot tell which carrier is being followed, which relation is ordered, which time window is covered, whether gaps or overlaps matter, and which stronger owner must carry work, resource, transformation, evidence, or whole-reidentification claims.

#Forces

#Solution

Recover a ContextTemporalAggregation@Context before using the aggregate:

ContextTemporalAggregation@Context:
  aggregationConcernRef
  aggregatedEntityOfConcernRef
  boundedContextRef
  aggregationMode: contextualOrder | temporalPhase | declaredMixedUse
  orderedRelationRefs?
  phaseRelationRefs?
  orderSpecRef?
  timeWindowRef?
  carrierIdentityRef?
  independenceOrJoinConditionRefs?
  coverageAndNonOverlapConditionRefs?
  boundaryCrossingRelationRefs?
  relatedMethodRefs?
  relatedMethodDescriptionRefs?
  relatedWorkOccurrenceRefs?
  relatedWorkResourceAggregationRefs?
  relatedTransformationRefs?
  relatedWholeReidentificationRefs?
  evidenceOrSourceRefs
  admissibleUse
  nonAdmissibleOverread
  strongerSourceReturnCondition

Use the record as a small typed relation, not as a new durable U.Level, U.Boundary, U.Interaction, or generic process object.

#Two Aggregation Modes

If one source phrase mixes both modes, split the record. A method may have an ordered relation structure, and the work that enacts it may also have dated phases, but those are different claims.

#Direct Owner Map

#Optional Operator Notation

Gamma_ctx and Gamma_time are optional notation for already recovered aggregation claims.

Gamma_ctx(contextualAggregationRecord, orderSpec, independenceAndJoinConditions)
  -> contextual aggregate record

Gamma_time(temporalAggregationRecord, timeWindow, coverageAndNonOverlapConditions)
  -> temporal aggregate record

The notation does not create a holon, transformation, method, work occurrence, or whole reidentification by itself. It records how the selected relation set is combined for the current use.

If the source says a system actually sequences, combines, transforms, measures, or audits something, name that acting-side relation separately through [A.12](/generated/patterns/A.12), [A.3.4](/generated/patterns/A.3.4), [A.15.1](/generated/patterns/A.15.1), [B.1.6](/generated/patterns/B.1.6), [A.10](/generated/patterns/A.10), or the direct owner. The person, team, controller, or tool that writes an aggregation record is not automatically the in-world transformer for the EntityOfConcern being aggregated.

#Admissible Checks

For contextual order aggregation:

• the ordered relation refs are named by value;
• the OrderSpec is declared as total order, partial order, or another named relation;
• independence, branch, or join conditions are named when parallel factors are used;
• all claims stay within one bounded context unless a boundary-crossing relation is named;
• method, method-description, work, transformation, and resource claims use their direct owners.

For temporal phase aggregation:

• the carrier identity is recoverable;
• the time window is declared;
• phase intervals are covered and non-overlapping, or the admissible use is narrowed;
• identity change is not hidden as another phase;
• work-resource and evidence-currentness claims use B.1.6, A.10, and C.27 when current.

B.1 invariant carry-through. B.1.4 keeps B.1 invariants only after the current relation is recovered. A singleton ordered relation or singleton phase is idempotent for the selected use. Contextual aggregation is deterministic only relative to the declared OrderSpec and join or independence conditions. Temporal aggregation is valid only relative to carrier identity, coverage, and non-overlap. Weakest-link and monotonicity claims must name the characteristic being bounded or improved; otherwise the aggregate is only an aggregation record, not a performance, safety, or assurance claim.

#Compact Obligation Rows

#Archetypal Grounding (Worked Slices)

Manufacturing sequence. A frame is prepared, welded, inspected, painted, and packed. B.1.4 records the contextual order claim: selected steps, order specification, join conditions, and admissible use for planning or comparison. The actual shop-floor work occurrences use A.15.1; energy and material roll-ups use B.1.6; a changed frame state uses A.3.4.

Paper revision history. A paper has draft, reviewed, and camera-ready phases. B.1.4 records the same episteme carrier across phases and the time or version window being claimed. Source-currentness and publication-use claims use A.10 and E.17; the phase relation does not make the publication authoritative by itself.

Cross-context evidence window. A dashboard aggregates observations from two operating contexts. B.1.4 records the bounded contexts and the admissible aggregation window. If one context has a different measurement basis, use C.16 or C.29 for comparability before relying on the aggregate.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

This pattern makes ordered and temporal aggregation inspectable without turning every sequence, phase, or context label into a holon level. It also lets practitioners keep useful Gamma_ctx and Gamma_time notation while avoiding a category error: the notation is an apparatus over a recovered aggregation claim, not the in-life work, method, transformation, or whole.

The cost is that the practitioner must name the relation being aggregated. The gain is that contextual order, temporal coverage, work evidence, resource accounting, transformation, and whole reidentification stop interfering with one another.

#Rationale

B.1.4 exists because contextual order and temporal phase aggregation are neither ordinary part-whole construction nor generic process talk. The same carrier can be considered through phases; a selected relation set can be order-sensitive; and both cases need admissible aggregation without inventing a new holon kind. The pattern therefore keeps relation discipline explicit: PhaseOf and carrier identity for phase aggregation; ordered relation refs and OrderSpec for contextual aggregation; direct-owner return for method, work, resource, transformation, evidence, and whole reidentification.

The old DesignRunTag warning is preserved as a rule rather than a label: do not fold design-time possible order and run-time history into one aggregate. If both are needed, make two records and relate them by value.

#SoTA-Echoing

#Relations

• Builds on B.1, A.14, and C.13 for part-whole, phase, and constructive grounding discipline.
• Coordinates with A.3.1, A.3.2, A.15.2, and A.15.1 for method, method description, work plan, and dated work occurrence.
• Coordinates with B.1.6 for work-resource aggregation.
• Coordinates with A.3.4 for transformation. When whole reidentification or emergence-family wording is current, B.2.P tests the problem and the relevant B.2-family pattern governs the recovered claim.
• Coordinates with C.27 for temporal-claim adequacy. When mathematical expression is selected, C.29 governs lens-use adequacy, E.18 governs selected transformation-flow structure, and E.18.2 governs mathematical description of that selected structure.

#B.1.4:End

#Gamma_method - Order-Sensitive Method Composition and Work Enactment

Type: Part B composition and grounding pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Problem Frame

Use this pattern when a project must decide whether several recovered methods compose into one larger U.Method, and when order, guarded choice, parallel branches, typed joins, adapters, or method-interface exposure changes the identity of that whole method.

Typical moments:

• a procedure, workflow, algorithm, pipeline, proof route, clinical protocol, manufacturing recipe, inference pipeline, or operational playbook has named steps or branches;
• changing the order of two candidate submethods changes the result or the admissible conditions of use;
• a diagram or code file looks like a method, but it may be only a method description, a work plan, a dated work trace, a selector registry, or a mathematical lens;
• a larger method must expose some interactions at its boundary while hiding internal steps;
• assurance needs to know which joins, adapters, cutsets, or exposed interfaces make the composite method reliable enough to enact.

Primary EntityOfConcern. The EntityOfConcern is one exact candidate or composite U.Method, already identified under A.3.1. The proposition that exact part Methods and whole-forming facts qualify it as composite is separately governed claim content. A separately identified C.2.1 episteme may carry that proposition in its ClaimGraph; the episteme then has the exact candidate Method as its EntityOfConcern under its effective ReferenceScheme. The proposition does not become the episteme.

First useful move. For each apparent step or branch, recover the governed object before composing anything: U.Method, U.MethodDescription, U.WorkPlan, dated U.Work, an A.22-selected U.Structure, method-family registry or selector outcome, mathematical lens, mechanism, formal substrate, or quoted wording that does not yet carry a method claim.

What goes wrong if missed. A flowchart becomes the method, a plan item becomes a submethod, an event log becomes proof that a method was enacted, an order edge becomes a part, or a registry of alternatives is treated as one composed method. Then work starts from a description or label whose method identity, joins, interfaces, and failure conditions were never recovered.

What this buys. The project can test whether an already identified candidate U.Method is composite and can state the needed part, order, join, interface, and identity facts without turning every useful sentence into a relation kind. If that qualification fails, the project still has a useful lower object: an A.22-selected U.Structure, description, plan, work occurrence, lens, selector result, or A.15.4 appearance-based reliance repair request.

Not this pattern when.

• If the current claim is one semantic way of doing with no order-sensitive composition question, use A.3.1.
• If the current claim is a claim-bearing episteme that describes a method or relations among methods, use A.3.2 and C.2.1.
• If the current claim is intended work, use A.15.2.
• If the current claim is a dated occurrence, use A.15.1.
• If the current claim is structural component parthood, use A.14, C.13, and B.3.5.
• If the current claim is only a method-family registry, selector, fallback relation, or useful organization of already identified methods without one whole-method construction, use G.5 or select a U.Structure under A.22.

#Composition Question And Object Boundaries

U.Method is a non-agentive method holon kind. A method can have submethods and can participate as a submethod in a larger method. This does not mean every step-looking node, document section, file module, graph edge, work-plan item, or work occurrence is a method part.

Order-sensitive method composition is a narrow constructive question:

Given independently recovered U.Method parts,
which methodPartOf occurrences, exact whole-forming claims, and constraints qualify one already identified candidate as composite,
and what whole-level commitments let a practitioner identify, reidentify, and enact that method?

The whole method is not the diagram, code, schedule, event log, card, or work history that may describe, plan, record, or evidence it. Work enacts the method; the method does not perform work. An A.22-selected U.Structure may organize several methods and obtaining relations for one use without constructing another method.

Gamma_method is the name for this method-composition discipline. It is not a new root U-kind, not a workflow notation, not a generic container, not a resource-accounting operator, and not a substitute for U.Work.

#Problem

Without B.1.5:

1. Source-wording composition. "Step", "stage", "activity", "task", "procedure", "workflow", "pipeline", or "algorithm" wording is accepted as method composition without recovering the actual objects.
2. Description-as-method. A workflow diagram, BPMN model, code repository, proof script, table, checklist, or graph path is treated as the composite method itself.
3. Order as mereology. SerialStepOf, ParallelFactorOf, guarded choice, or fallback relation is placed in a structural part-whole chain.
4. Typed joins disappear. One submethod's intended result is assumed to satisfy the next submethod's precondition without an adapter method, governed correspondence or equivalence, and an explicit failure route.
5. Interface exposure is hidden. Callers rely on internal interactions that should be encapsulated, or fail to see interactions that the composite method must expose.
6. Run-time leakage. Resources, timestamps, telemetry, performed values, and results are baked into the method instead of remaining occurrence-side facts and separately governed resource, result, and evidence relations.
7. False whole method. A method-family registry, fallback table, selector rule, or A.22-selected relation organization is treated as one whole method although no construction or whole identity has been recovered.

#Forces

#Solution

A.3.1 first identifies the exact candidate U.Method and every exact part method. B.1.5 does not create their U.Method membership. It asks the narrower question: do these already identified methods, contributions, constraints, and boundary decisions warrant the claim that the candidate Method is composite?

Start with the smallest useful composition claim:

1. Name the same exact A.3.1 candidate Method and exact A.3.1 part methods.
2. In ordinary domain language, state the candidate's reusable whole action, what each part contributes, and the order, guard, adapter, or join condition that the whole action actually needs.
3. For every whole-forming statement other than B.1.5's narrow methodPartOf, use A.6.RCD's lightest sufficient disposition: an existing direct predicate, a local compound claim, or a reusable predicate-definition episteme. A convenient edge label is not a relation-kind admission.
4. Add stable relation-occurrence identity, typed declarations, publication, or assurance only when a named receiving use consumes that extra result. Route any relation-kind candidate through E.24 and E.24.UK rather than admitting it here.
5. If the whole action, boundary, contribution, or reidentification rule is still missing, stop the composite claim and keep the useful lower object under its direct owner.

Minimal positive. BuildAndVerifyPumpUnit is already an exact A.3.1 Method. Its construction rule requires frame assembly, motor installation, connector adaptation when the installed connector does not meet the test precondition, and functional testing; installation and any required adaptation must finish before testing, and adapter failure stops the whole before test. These plain claims, exact methodPartOf facts, and the whole identity rule can warrant the composite-method qualification without minting one relation kind per arrow.

Discriminating non-composite. AssessVitals, ClassifyUrgency, and RouteToCare can support readable result-to-precondition and guarded-dispatch claims while still lacking one reusable whole action, complete boundary, and whole reidentification rule. Keep those claims local and do not call their organization a composite Method. Select an A.22 U.Structure only if a real receiving use needs a load-bearing selected organization.

When a caller system, planner system, substituting-method selection use, auditor, or assurance use needs a reliance-bearing account, check the complete coordinates below. This is a reading checklist, not a schema, record, RelationSignature, or set of SlotSpecs.

Composite-method qualification:
  candidate whole method: one exact U.Method already identified under A.3.1
  part methods: a non-empty set of exact U.Method values already identified under A.3.1
  B.1.5-owned method-part occurrences: methodPartOf(part method, whole method)
  other whole-forming claims and constraints:
    exact order, independence, guard, iteration, fallback, adapter, and join meanings used here
    each closed at A.6.RCD's lightest sufficient disposition
  whole semantics:
    generic participants, applicability, preconditions,
    intended effects or preserved conditions, invariants, bounds,
    accepted inputs and outputs, failure and stop conditions
  boundary decisions:
    exposed, forwarded, and encapsulated interactions
  identity and reidentification:
    what keeps this whole the same and what identifies another method
  enactment boundary:
    exact U.Work may enact the method only through A.15.1 enactsMethod
  lower disposition if construction is incomplete:
    selected U.Structure | U.MethodDescription | U.WorkPlan | U.Work |
    G.5 selector | lens | A.15.4 appearance-based reliance repair request

#Recover Parts Before Composition

Do not start from the word "step". Start from the object claim.

An apparent step can be:

• a U.Method submethod;
• a description constituent inside U.MethodDescription;
• a plan item inside U.WorkPlan;
• a dated U.Work occurrence or work part;
• an order, fallback, or selector claim among independently identified objects;
• a mathematical or representation lens over selected relations;
• mechanism or formal-substrate material;
• quoted wording that does not yet carry a method claim.

Only the first case can be a method part. Do not mint U.StepSpec, U.StepMethod, U.MethodStep, or U.MethodAlgebra for the others.

B.1.5 directly governs MethodPartOfRelation, expressed in Plain register as methodPartOf(partMethod, wholeMethod). Both participants are exact U.Method values already identified under A.3.1. The predicate obtains exactly when the whole Method's stable construction rule names the part Method as a required contributor or as an admitted alternative for a required contribution, and that contribution participates in the whole's reusable action. It establishes neither A.14 structural-component parthood, a work part, nor a transformation part.

One methodPartOf occurrence is determined by the ordered pair <part Method, whole Method>. Every bounded alternative already admitted by the whole's construction rule can stand in methodPartOf at the same time; dated Work selecting one alternative does not start, end, or recur the other occurrences. For the same two exact Methods, the relation is atemporal: there is no silent cessation and later recurrence. If the construction rule changes so that a part is newly admitted or no longer admitted, the composite Method must be reidentified or the claim remains unresolved; reidentifying either participant gives another pair. This is why the participant pair is sufficient for the narrow B.1.5-owned family even when actual enactments vary.

A source label, list membership, diagram containment, shared name, registry entry, description membership, plan position, or work decomposition does not make methodPartOf obtain. When the test fails, keep the apparent step under its direct owner and do not add a negative part merely to complete a diagram.

#Test The Composite-Method Qualification

First identify the exact candidate Method under A.3.1 from its reusable action, participant meanings, applicability, preconditions, intended result or preserved condition, bounds, and failure or stop conditions. If that Method cannot yet be identified, return to A.3.1. B.1.5 then tests whether already identified part Methods and exact whole-forming facts justify calling that same candidate a composite Method; it does not create the candidate's Method identity.

State each whole-forming fact in ordinary domain language before choosing its representational or ontological disposition. The words serial, parallel, guarded, iterative, fallback, adapter, and join do not settle the claim by themselves.

Then use A.6.RCD. Reuse an existing direct predicate when one already governs the needed claim. Otherwise stop at a local compound claim when it closes this use, or publish a reusable predicate-definition episteme when several uses need the same rule. Continue to a relation-kind candidate only when a named receiver needs stable occurrence semantics that claim content cannot supply; E.24 and E.24.UK decide admission. A label such as precedesInMethod is readable claim language, not admission evidence, and an ordinary composition claim needs no invented occurrence.

Keep definition, signature, kind, and edition distinct. A predicate-definition episteme may independently satisfy ordinary A.6.0 U.Signature membership. It is not a RelationSignature; that specialization opens only for an admitted relation kind. Changed predicate-definition or signature content identifies another episteme under C.2.1. Treat and connect the two epistemes as editions through EpistemeEditionRelation only when C.2.1's historical-continuation test passes: an exact system performed revision, refinement, or supersession Work under a Method whose semantics establish continuation, the earlier episteme participated through the exact source-to-revision use, and governed change facts support the claim. Otherwise the later episteme is a non-continuing replacement. The changed content triggers review of dependent claims; it does not by itself prove another relation kind or relation occurrence. If a relation kind is independently admitted, its direct subject owner supplies applicability, obtaining, continuation or cessation where relevant, and occurrence identity.

When several admitted order occurrences must be reviewed together, use B.1.4's OrderSpec, exact ordered-relation designations, and join or independence conditions in a separate bounded-use aggregation record. The record and optional Gamma_ctx notation neither participate in Method identity nor make any relation obtain. When the order statements remain local claims rather than admitted relation occurrences, compare those claim contents directly and do not pretend that an OrderSpec has occurrences to aggregate.

The composite-method qualification holds only when the candidate Method also has its own reusable semantic action, generic participant meanings, applicability, preconditions, intended effects or preserved conditions, invariants, bounds, accepted inputs and outputs, failure and stop conditions, and interface decisions. Its identity includes the exact part Methods and construction architecture on which those semantics depend. Cite an effective reference scheme or claim scope only when its variation changes a Method meaning or the use of a claim about that Method; neither is a generic container.

State the reidentification rule with the qualification. The same exact candidate continues through only those parameter changes, reorderings, or part substitutions that its A.3.1 identity rule already permits while preserving the whole action, applicability, preconditions, intended result or preserved condition, bounds, required joins, and interface boundary. A change outside those permitted variations identifies another U.Method. Use B.2 when a separate higher-level reidentification or emergence claim is current; a B.2 label is not needed to state an ordinary B.1.5 rule.

#Keep Order Out Of Structural Mereology

Source cues such as SerialStepOf, ParallelFactorOf, guarded choice, iteration, fallback, adapter, and typed join call attention to possible whole-forming claims. They are not admission evidence, they need not become relation kinds, they are not A.14 component parthood, and they do not make methodPartOf obtain by themselves.

Use A.14, C.13, and B.3.5 when the claim is about structural parts of a holon. Use B.1.5 when the claim is about how reusable ways of doing construct a larger reusable way of doing. The same project may need both, but the relation occurrences and truth conditions remain separate.

Use B.1.4 when a receiving use needs an inspectable order aggregation, partial-order test, or join/independence account. Its OrderSpec and optional notation describe already recovered order occurrences; B.1.5 still decides whether those methods and relations construct one composite U.Method.

When the current claim is temporal phasing of the same carrier or method-description edition history, use the pattern that governs the phase or temporal claim rather than B.1.5. A phase boundary becomes a B.2-family question only when the boundary also introduces whole reidentification, closure, or supervision. Order, phase, structural parthood, method composition, and whole reidentification remain different claims even when one source diagram uses one line for all of them.

#Expose The Composite Method Interface

The candidate Method's reusable action includes a boundary decision for each interaction:

• exposed: a caller system may rely on the interaction as part of the whole Method;
• forwarded: a caller system may address an internal submethod interaction through a declared designation or adapter;
• encapsulated: the interaction is internal and cannot be relied on from outside the whole Method.

An exposure decision contributes to Method identity whenever changing it changes the reusable action or its admissible boundary. That identity consequence does not wait for an outside party to rely on the Method. A named caller, planner, auditor, substituting-method selection use, or assurance use instead determines when the decision must be stated explicitly or published for reuse. Name the interaction, precondition, result or preserved condition, failure route, and any adapter needed for each exposed or forwarded case.

#Composite-Method Boundary Account and Publication Form

When a named receiver must reuse the boundary account, first identify one exact claim-bearing U.MethodDescription episteme under A.3.2 and C.2.1. Its claim content concerns the exact composite Method and states the exposed, forwarded, and encapsulated interactions. Then keep the publication-side objects and designation content below separate.

In B.1.5, composite-Method boundary account is the local Plain phrase for this MethodDescription claim content. A boundary-account form is the separately identified reusable arrangement used to present that content when publication is load-bearing. Neither phrase creates a new kind or acronym. The separate A.10 instantiation card keeps its different design-time use for Precedes, Choice, Join, guards, and exceptions.

1. A bounded-use-declaration episteme states the operations or decisions supported by this publication, the conditions of that use, and the excluded stronger use.
2. An audience-declaration episteme states the audience criterion. The actual audience consists of entities admitted by that declaration; those entities are not substituted for the declaration episteme as a publication-relation participant.
3. An independently identified reusable boundary-account arrangement is a publication-form participant only while E.24.PUB PublicationFormExpressionRelation(description edition, boundary-account form, bounded-use declaration) obtains.
4. A paper card, poster, page, file, or screen must first be identified independently as a physical or digital U.PresentationCarrier; E.24.PUB PublicationFormBearingRelation(carrier, boundary-account form) then states which form it bears.
5. An actual system performs separate rendering, printing, uploading, indexing, or access-granting publication Work. That Work may establish or restore availability, but it is not the publication occurrence or one of its participants.
6. One EpistemePublicationRelation occurrence, with the exact five participants <description edition, audience-declaration episteme, bounded-use-declaration episteme, boundary-account form, carrier>, makes the edition available to the declared audience for the declared use throughout its maximal continuous interval of availability. The relation occurrence is not performed by the publishing system, and the boundary-account form does not publish itself.
7. Names, labels, and links that designate the Method or description edition remain separately governed designation content. Neither the form nor the carrier establishes designation merely by displaying similar words.

Reader-facing boundary-account prompts:
  described Method, exact MethodDescription edition, and effective reference scheme when its variation changes the Method meaning or claim use
  named audience criterion and bounded use, including any excluded stronger use, when publication is load-bearing
  exposed and forwarded interactions
  accepted input or call meaning
  preconditions and intended result or preserved condition
  failure and stop routes
  invariants
  exact B.1.4 order aggregation or OrderSpec only when the receiver relies on its order, join, or independence limits
  applicability, bounds, and quality or assurance envelope only when they limit the interaction on which the receiver relies
  adapter, typed-join, and assurance references only when the receiver uses them
  plain rationale for each encapsulated interaction on which misuse is likely

These prompts organize presentation; they are not direct-relation SlotSpecs, relation participants, Method parts, or a schema that creates a Method. None supplies the world-side methodPartOf facts or any other whole-forming claim. For a lightweight internal use, state the few boundary decisions in clear sentences and stop; do not create a description edition, declaration episteme, boundary-account form, carrier, publication Work, or publication occurrence by ritual.

#Keep Method Qualification And Work Occurrence Separate

B.1.5 evaluates and grounds the composite-method qualification of an exact U.Method already identified under A.3.1. A separately constituted U.MethodDescription may state that composition claim. Neither object creates performed Work.

One dated occurrence W : U.Work enacts the exact method M : U.Method only when A.15.1 enactsMethod(W, M) obtains. For every actual performer system S, recover the exact assignment RA : U.RoleAssignment whose holder is S and the F.6 attribution performedUnderAssignment(W, RA) when explicit attribution identity is used; S performs the Work and RA does not act. The temporal extent and executedWithin relation remain occurrence-side facts. An assertion or occurrence-description episteme may cite those facts and the method-description reference used; the Work occurrence does not store a card or record.

Parameter bindings, affected referents, resource use, telemetry, retries, results, actual transformations, production, evidence, evaluation, delivery, and acceptance remain separate objects and direct relations under their own governors. They do not become method parts, method identity fields, or generic Work outcomes merely because a report places them beside the Work.

The composition link is not one-to-one. A Work occurrence may enact the whole method without exposing every submethod as a separate work part. A temporal work slice may enact the same whole method during a selected interval. An episode may span several method factors, repeat one factor, or be split by evidence policy without changing the method identity. Conversely, a work part does not establish a submethod. A work part enacts a submethod only when that submethod is already an independently identified U.Method and a separate enactsMethod(workPart, submethod) occurrence obtains.

Reader check. Before saying that a work part enacts a submethod, name both sides:

• the occurrence-side object: parent U.Work, obtaining work-part relation, interval or boundary, performer system, covering assignment, and any separately obtaining resource or evidence relation;
• the method-side object: exact A.3.1 submethod, methodPartOf occurrence, whole-forming claim at its A.6.RCD disposition, preconditions, intended result or preserved condition, interface boundary, and whole-Method identity;
• the cross-side fact: the exact enactsMethod(workPart, submethod) occurrence.

If any side is missing, lower only that side. Do not repair a missing submethod by inventing a work part, and do not repair a missing work part by inventing a submethod. Keep a method-description node, evidence segment, mechanism material, system-component behavior, or A.15.4 appearance-based reliance repair request under its direct owner.

#Planning And Performed-Work Obligations

B.1.5 has three common use positions, but they are positions in use, not U-kinds:

• Planning or description-side use. A planner system performing planning Work recovers the exact Methods, methodPartOf occurrences, whole-forming claims at their A.6.RCD dispositions, any justified order aggregation, typed joins or adapters, interface boundary, invariants, and whole-level commitments. A resulting exact U.WorkPlan may cite the MethodDescription edition on which it relies; neither the planning Work nor the plan is the reader that defines Method identity.
• Performed-work use. Recover the exact enactsMethod occurrence for the whole Work. Check the performer system and covering assignment, plus capability fit or admission only when the work-entry decision consumes those claims; then check preconditions, order conformance, and exposed or forwarded interactions through their direct owners. State resource use, evidence, and results only through their own obtaining relations. None becomes part of the method.
• Assurance use. Identify cutset submethods, fragile typed joins, adapter points, mapping congruence or CL-sensitive edges, and the envelope or scope in which the composite method is expected to hold. B.3 and related assurance patterns evaluate those hooks; B.1.5 only makes them visible.

Useful invariants remain: a single recovered submethod composed alone does not create a surprising new Method; order is deterministic only under the exact order claims and conditions at their selected A.6.RCD dispositions; any throughput or quality bound must name its characteristic, critical path, and weakest-link basis; strengthening a submethod, adapter, or typed join should not make the composite Method worse unless a stated side condition changes.

#Stop Before Transformation Composition

Method composition and Work decomposition establish no U.Transformation part, composite transformation, transformation atomism, or TransformationPartOfRelation. Even when several method parts address the same referent and one Work enacts the whole method, identify each actual transformation independently under A.3.4. If a claim needs transformation composition and no direct transformation-composition governor supplies its participants, obtaining rule, and occurrence identity, return missing-governor[transformation-composition] for the proposed whole and independently identified changes. Do not infer either composition or indivisibility from the gap.

#Select A Structure Below The Whole-Method Threshold

Use A.22 when independently identified Methods and already obtaining relations are useful to one question or action but do not construct one whole Method. For an actual load-bearing selection, first name the selecting system, selection Method, dated selection Work and bindings, and any result episteme needed to preserve the decision. Then name all four structure discriminators: exact constituents, exact selected obtaining relation occurrences, applied constraints, and the use frame. For a one-off hypothetical comparison, state the comparison and stop without asserting a selected U.Structure. MethodRelationStructure may be used as a local readable designator only for an actually selected structure; it is not a U-kind, relation kind, Method holon, or identity field.

Typical cases:

• a fallback registry selects among alternatives but supplies no whole method;
• a workflow diagram relates method descriptions but does not recover method parts;
• a method family has independently governed refinement, substitution, or dispatch relations;
• a graph or algebra represents selected method relations as a lens;
• the same method labels occur under different effective reference schemes, while the local senses have not been resolved and any F.9 Bridge would establish only sense correspondence, not method identity;
• a work plan orders tasks but does not define one reusable method.

The selected structure is a dependent organization for its named use. It does not create its constituents or relations, become a Method, or supply holonhood. Conversely, the internal construction of one exact Method whose composite qualification has been established does not become a second generic structure merely because a diagram can display it. Select a U.Structure only when that organization itself changes the next question or action.

This lower object is not a failure. It is the right governed object when relation organization is useful but whole-method construction is not current.

#Archetypal Grounding — Worked Slices

#Manufacturing Recipe

AssembleFrame, InstallMotor, AdaptMotorConnector, RunFunctionalTest, and BuildAndVerifyPumpUnit are exact U.Method values already identified under A.3.1; the last is now the candidate for a composite-method qualification. The four participant-determined occurrences methodPartOf(AssembleFrame, BuildAndVerifyPumpUnit), methodPartOf(InstallMotor, BuildAndVerifyPumpUnit), methodPartOf(AdaptMotorConnector, BuildAndVerifyPumpUnit), and methodPartOf(RunFunctionalTest, BuildAndVerifyPumpUnit) obtain because the stable whole construction rule names each contribution. Every already admitted connector-adapter alternative may stand in methodPartOf simultaneously; one Work occurrence selecting an alternative does not toggle those atemporal occurrences. Removing a contribution from the construction rule, adding a new admitted alternative, or changing a required order, join, whole result, or boundary outside the declared variations identifies another whole Method.

For the ordinary use, say: the installed motor must provide the harness-installed condition required by functional test; when the supplier connector does not provide it, AdaptMotorConnector must provide the conversion before test; adapter failure stops the whole before test. In this one use, PumpInstallBeforeTest and PumpConnectorAdapterJoin are readable labels for local compound claim content in the exact PumpBuildCompositionDescription-v1 : U.MethodDescription episteme under A.3.2 and C.2.1, not relation-kind names or occurrence designators. If several pump-family uses need the same parameterized rule, A.6.RCD can identify a reusable predicate-definition episteme. Only a later named receiver that needs stable occurrences can justify returning a derived-kind candidate to E.24 and E.24.UK.

The composite qualification additionally requires the candidate's generic participants, applicability, preconditions, accepted inputs, final effect, preserved conditions, exposed start and abort interactions, encapsulated calibration interaction, failure routes, and reidentification rule. A list of the five names or an arrow diagram establishes none of these facts.

PumpUnitBuildWork-2026-07-29 may enact the whole through one exact enactsMethod occurrence without four corresponding work parts. If a separately admitted MotorInstallationWorkPart-2026-07-29 exists, it enacts InstallMotor only through its own enactsMethod occurrence. Resource use, test telemetry, the produced pump unit, acceptance, and evidence remain under their direct owners.

#Emergency Intake

RegisterPatient, AssessVitals, ClassifyUrgency, and RouteToCare are independently identified Methods. For a one-off protocol review, the practitioner may state two local claims in ordinary language: the intended vital-sign result meaning of AssessVitals must satisfy the admitted input meaning of ClassifyUrgency; and the declared triage rule decides which admitted urgency category holds from the declared vital-sign conditions and, when the protocol uses them, the declared symptom conditions, then maps that category to one compatible RouteToCare. If no category or several incompatible categories hold, the practitioner stops the routing decision and returns the guard rule for repair. These are useful claim contents, not MethodResultPreconditionRelation or MethodDispatchRelation admissions.

This review is deliberately hypothetical and non-load-bearing. It compares the four Methods and the two claims but does not assert a persisted U.Structure or a selection judgment. If a later receiving use needs an A.22-selected structure, its selection must identify the exact selecting system, selection Method, dated selection Work and bindings, and—where the result must persist—the result episteme. The structure itself is then identified by all four A.22 discriminators: exact constituents, exact independently admitted obtaining relation occurrences, applied constraints, and use frame. The present local claims cannot be relabelled as such occurrences merely to fill that list.

The comparison still discriminates the non-composite case. No reusable whole action, complete precondition-to-result boundary, response to every guard conflict, or whole reidentification rule has been established. A wall poster may be a carrier bearing a publication form; an exact U.MethodDescription edition is a different claim-bearing episteme, and an actual publication occurrence is what makes that edition available to an audience. A system performing intake Work is separately checked for its role assignment and any capability or admission claim consumed by the work-entry decision. None of these facts is a Method part.

If a later hospital protocol first identifies an exact A.3.1 Method such as EmergencyIntakeMethod-v4 with the missing whole semantics, B.1.5 can test its composite-method qualification. Neither a poster, the one-off comparison, nor a later selected structure turns into that Method.

#Learned Model Pipeline

A neural-network pipeline may describe feature extraction, embedding, attention, retrieval, ranking, and explanation generation. Some blocks may be formal substrate or mechanism material, some may be constituents of a U.MethodDescription, and some may be recovered as U.Method values.

After the candidate whole represented by the pipeline and every claimed part have been independently identified as exact A.3.1 Methods, that candidate qualifies as composite only when exact methodPartOf occurrences, whole-forming claims at their A.6.RCD dispositions, accepted inputs and outputs, invariants or admissibility conditions, typed joins, fallback behavior, failure conditions, interface decisions, and reidentification rule are present. Otherwise keep the graph as a MethodDescription, mathematical lens, mechanism material, or—when an actual selection basis and receiving use exist—an A.22-selected U.Structure.

Suppose one dated training Work enacts the exact pipeline Method while three independently identified transformations occur: the feature store changes, model parameters change, and the ranking index changes. Common Work, shared data, Method order, and temporal adjacency do not establish transformation parts or one composite transformation. Without a direct transformation-composition governor, retain the three transformations and return missing-governor[transformation-composition] for the proposed three-change whole; do not call them atomic either.

#Evidence Synthesis And Publication

CollectDatasets, NormalizeSchemas, EstimateModel, CrossValidate, DraftManuscript, and EvidenceSynthesisAndPublication-v3 must first be exact A.3.1 Methods. B.1.5 can qualify the last as composite only when every claimed methodPartOf occurrence obtains and its whole-forming claims and constraints pass A.6.RCD's lightest sufficient disposition. In ordinary language, the intended result of NormalizeSchemas must satisfy the admitted input meaning of EstimateModel; legacy datasets may require adapter Methods; CrossValidate may be a critical cutset for later assurance; and a provenance condition may be a precondition of DraftManuscript before publication Work begins.

A paper draft, workflow diagram, repository, or notebook may be a claim-bearing episteme, a representation, or a carrier; its form does not make it the Method. Publication Work is U.Work. Compute, storage, reviewer time, artifact production, release, and acceptance stay with their direct owners.

EvidenceSynthesisInterfaceDescription-v3 : U.MethodDescription may state that the Method exposes Submit() and ReleaseArtifacts(), forwards CrossValidate.Folds(k), and encapsulates ad hoc scrubbing utilities. Identify SubmissionReleaseBoundaryAccountForm-v3 independently as the reusable arrangement entity selected as the boundary-account form. Identify EvidenceSynthesisMethodsPage-2026-07 : U.PresentationCarrier independently as the digital carrier. Identify SubmissionAndArtifactReleaseUse : U.Episteme as the bounded-use declaration whose claims state the supported submission and artifact-release operations, their conditions, and the excluded stronger use. Identify SubmittingResearchersAudienceDeclaration-v1 : U.Episteme as the audience declaration whose claims select the authorized submitting researchers; those researchers are the declared audience, not a participant substituted for the declaration episteme.

PublicationFormExpressionRelation(EvidenceSynthesisInterfaceDescription-v3, SubmissionReleaseBoundaryAccountForm-v3, SubmissionAndArtifactReleaseUse) must obtain for that form use, and PublicationFormBearingRelation(EvidenceSynthesisMethodsPage-2026-07, SubmissionReleaseBoundaryAccountForm-v3) must obtain for that bearing claim. ResearchPublicationSystem performs the separate EvidenceSynthesisInterfacePublicationWork-2026-07 : U.Work, which may establish or restore availability. The distinct EvidenceSynthesisInterfacePublication-2026-07 occurrence of EpistemePublicationRelation has the five fixed participants <EvidenceSynthesisInterfaceDescription-v3, SubmittingResearchersAudienceDeclaration-v1, SubmissionAndArtifactReleaseUse, SubmissionReleaseBoundaryAccountForm-v3, EvidenceSynthesisMethodsPage-2026-07> and carries the description edition's enduring availability to the audience selected by the audience declaration for the bounded use. Publication Work is not a participant of that occurrence. None of these description, declaration, form, carrier, Work, or publication-relation objects creates an interaction, SlotSpec, Method part, or composition fact.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: cross-domain order-sensitive composition of already identified U.Method values. It does not cover sole-Method identification, description-only organization, dated Work decomposition, structural mereology, or transformation composition without a direct governor.

• Gov: each methodPartOf occurrence and each other whole-forming claim stays with its direct governor; a named receiver changes how much of the boundary account must be stated or published, not whether a world-side fact obtains.
• Arch: the whole is qualified from exact part Methods and construction facts; order aggregation, a selected A.22 Structure, and a separate higher-level reidentification claim remain distinct architectural objects.
• Onto/Epist: Methods and obtaining relation occurrences remain distinct from MethodDescription claims, boundary-account presentation, carriers, publication Work, and publication occurrences.
• Prag: ordinary use may stop at readable local claims; reusable definitions, relation kinds, declarations, publication, and assurance are added only when a named receiving use needs them.
• Did: the manufacturing, emergency-intake, learned-pipeline, and evidence-synthesis slices show both positive composition and useful non-composite stopping results across different domains.

The pattern intentionally biases toward explicit construction and boundary accounts when joins or outside reliance are load-bearing. The lightweight local-claim lane and direct-owner exits mitigate that bias so inspectability does not become ritual apparatus.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

B.1.5 buys inspectable Method composition without confusing the candidate Method, composition claim, MethodDescription, selected Structure, Work occurrence, resource use, and assurance argument. The practitioner can say which exact Methods are parts, which ordinary whole-forming claims and constraints qualify the candidate as composite, which interactions belong to its boundary, what exact Work enacts it, and where a stronger claim must stop.

The cost is proportionate explicitness: exact Methods, methodPartOf occurrences, whole-forming claim content, order and join conditions, interface decisions, whole semantics, and reidentification must be stated before the composite qualification can be relied on. Ordinary use can stop at readable local claims; reusable definitions, relation kinds, declarations, publication, and assurance are added only when a named receiver needs them.

#Rationale

The rationale is a strict object separation. Paying this explicitness cost exposes brittle joins and accidental external dependencies at Method boundaries before someone relies on the composite claim. Order is semantic but not structural parthood. A method can be a non-agentive holon, but a step label, graph node, phase, source section, description constituent, plan item, or work part is not a method part until the U.Method and methodPartOf occurrence are recovered. Gamma_method concerns ways of doing; Gamma_work supports occurrence-side resource analysis; B.3 evaluates assurance; A.22 selects useful relation organizations; B.2 handles a separately current higher-level reidentification claim. None of those neighboring objects replaces the direct B.1.5 construction facts.

#SoTA-Echoing

These rows answer the B.1.5 practice question: how to decide and expose order-sensitive Method composition without mistaking descriptions, Work, event records, or construction diagrams for the composite Method.

Currentness and reopen. These four decisions are qualified by the exact source selections cited above. Reopen only the affected row when a cited source or edition is superseded, or when newer practice changes the relied-on model/occurrence separation, order or join condition, interface or substitution boundary, or construction and reidentification test. Recheck that row's B.1.5 adoption, refusal, and affected Solution, worked-case, checklist, and Relations loci; leave unaffected rows closed.

#Relations

• Uses A.1 for the general non-agentive-holon recognition boundary; A.1 does not supply Method-part or whole-forming facts.
• Uses A.3.1 to identify the exact candidate Method and every exact part Method before B.1.5 tests the composite-method qualification; B.1.5 directly governs only MethodPartOfRelation and the composite-construction test.
• Uses A.6.RCD for serial, parallel, guarded, iterative, fallback, adapter, join, substitution, and other whole-forming claims. Existing direct predicates, local compound claims, and reusable predicate definitions are valid stopping results; only a named occurrence-semantics need returns a kind candidate to E.24 and E.24.UK.
• Uses A.6.REL only when an independently admitted relation kind has an obtaining occurrence whose identity a receiver consumes. B.1.5 does not manufacture occurrence semantics for ordinary claim content.
• Uses C.2.1 to identify predicate-definition, signature, and MethodDescription epistemes and any later episteme with changed identity-bearing content. Uses EpistemeEditionRelation only when C.2.1's exact historical-continuation predicate obtains; otherwise the later episteme is a non-continuing replacement. A predicate definition may satisfy ordinary A.6.0 U.Signature membership; only an admitted relation kind can have a RelationSignature.
• Uses B.1.4 only when a receiving use needs an explicit aggregation of already admitted, obtaining order relations, an OrderSpec, and join or independence conditions.
• Uses A.3.2 for each exact claim-bearing U.MethodDescription and E.24.PUB only when a named use requires publication detail: independently identified bounded-use- and audience-declaration epistemes, boundary-account form and U.PresentationCarrier; exact PublicationFormExpressionRelation and PublicationFormBearingRelation; separate publication Work performed by a system; and the five-participant EpistemePublicationRelation occurrence that makes the edition available. Raw audience and designation content remain separately governed.
• Uses A.15, A.15.1, and A.15.2 for role/method alignment, exact dated U.Work, enactsMethod, and plans; the Method does not act, Work is not a relying reader, and a role assignment does not perform Work.
• Uses B.1.6 and Gamma_work only for occurrence-side work-resource aggregation after the Work and resource relations are recovered.
• Uses B.3 for cutset, weakest-link, CL-sensitive mapping, and assurance claims; composition alone supplies no assurance verdict.
• Uses A.22 only for a real selected organization with its selection basis and four identity discriminators. A one-off hypothetical comparison and local whole-forming claims do not assert a selected U.Structure.
• Uses C.13 only after B.1.5 supplies exact Method parts, whole-forming facts and constraints, and the whole reidentification rule; C.13 consumes those facts but does not create them or require one relation kind per fact.
• Keeps A.14 structural-component parthood distinct from Method composition; coordinates with B.3.5 only when a published structural claim and its grounding are current.
• Uses B.2 when a separate higher-level reidentification or emergence-family explanation is current; ordinary composite-Method identity still needs its explicit B.1.5 rule.
• Uses G.5 when a Method-family registry, selector, fallback, or candidate-set decision is current but no whole construction is claimed.
• Uses C.29, A.6.1, and E.20 when a mathematical lens, formal substrate, mechanism, or representation-maintenance claim is current.
• Uses E.10 for method, step, process, workflow, ownership/stewardship, requirement, and source wording precision recovery.
• Stops before any positive transformation-composition or transformation-part claim until a direct governor supplies exact participants, obtaining semantics, and occurrence identity.

#B.1.5:End

#Work-Resource Aggregation

Type: B-family aggregation pattern Status: Stable Normativity: Normative unless explicitly marked informative

Use this when. Use this pattern when the current claim aggregates resources, effort, time, energy, material, information, cost, or another measured resource over dated work occurrences, phase slices, boundary partitions, or comparable work-resource ledgers.

Not this pattern when. If the current question is the method as a way of doing, use A.3.1. If it is a method description, SOP, algorithm text, simulator configuration, or formal expression, use A.3.2. If it is a work plan, use A.15.2. If it is whether work occurred, use A.15.1. If it is work-entry readiness, full-kit condition, or resource readiness before work entry, use A.15.5. If it is temporal phase aggregation without resource accounting, use B.1.4. If it is a transformation claim, use A.3.4. If apparent resource gain changes whole identity, use B.2.P before any B.2-family owner.

What goes wrong if missed. Resource, effort, time, energy, or cost totals are read from methods, plans, dashboards, or phase labels without a dated work occurrence, resource ledger, and overlap policy.

What this buys. The practitioner can aggregate resources over performed work while avoiding double counting and returning method, plan, transformation, evidence, and MHT claims to their direct owners.

#Problem Frame

Practitioners need to roll up work-resource claims across runs, phases, teams, devices, stations, model-training epochs, or evidence-production episodes. The recurring error is to treat a method, method description, plan, phase label, dashboard, or expected efficiency as if it were measured performed work.

B.1.6 governs the work-resource aggregation claim. It keeps dated work occurrence, method, method description, work plan, resource ledger, holon delimitation, transformation, evidence, and whole reidentification in their own owners.

#Problem

Work-resource totals are often borrowed from plans, method descriptions, dashboards, or phase labels even when no performed-work evidence, resource-accounting basis, holon delimitation, time window, and overlap policy have been recovered. The failure is to treat a convenient total as a work-resource aggregation claim before the dated work occurrences and resource ledger are explicit.

#Forces

#Solution

Recover a WorkResourceAggregation@Context:

WorkResourceAggregation@Context:
  aggregationConcernRef
  parentWorkOccurrenceRef?
  workOccurrenceRefs
  boundedContextRef
  transformedOrAffectedEntityRef?
  holonDelimitationRefs
  boundaryCrossingRelationRefs?
  timeWindowRef
  phaseRelationRefs?
  resourceBasisRefs
  resourceMeasureRefs
  resourceLedgerRefs
  overlapOrDeduplicationPolicyRef?
  methodRefs?
  methodDescriptionRefs?
  workPlanRefs?
  evidenceOrMeasurementRefs
  aggregationRuleRef
  aggregatedResourceValueRef
  admissibleUse
  nonAdmissibleOverread
  strongerSourceReturnCondition

The record is a resource-aggregation relation over work evidence. It is not a method, not a method description, not proof that planned work happened, not a new holon level, and not a whole reidentification claim.

Resource readiness is a neighboring claim, not a measured aggregation result. Planned capacity, reserved inventory, staffing availability, or a full-kit-looking label may be cited as a work-plan, source, or readiness reference, but [A.15.5](/generated/patterns/A.15.5) governs whether intended work is ready to enter performed-work execution. [B.1.6](/generated/patterns/B.1.6) governs only the resource-accounting basis, ledger, evidence, aggregation rule, and aggregated value for dated work occurrences or explicitly narrowed planned estimates.

#Direct Owner Map

#Optional Gamma_work Notation

Gamma_work is optional notation for a recovered WorkResourceAggregation@Context.

Gamma_work(workResourceAggregationRecord, resourceBasis, aggregationRule)
  -> aggregated resource value plus ledger

The notation applies only after the work occurrence refs, resource-accounting basis, time window, holon delimitation, and evidence or measurement refs have been named. It does not order method steps, certify the method, create work evidence, or declare emergence.

#Ledger Discipline

A conforming WorkResourceAggregation@Context includes a work-resource ledger with:

• work occurrence refs or parent and child work occurrence refs;
• resource-accounting basis and unit refs;
• time window and phase refs when time slicing is used;
• holon delimitation refs and any boundary-crossing relation refs used for accounting;
• method, method-description, and work-plan refs only when those objects are actually used;
• evidence, measurement, or source refs for the resource values;
• overlap or deduplication policy when work occurrences share resources, time windows, ports, stocks, people, tools, or data;
• admissible use and non-admissible overread.

For any resource type in the selected resource-accounting basis, the ledger should say whether the value is measured, estimated, normalized, or converted. If the value is measured, it names the measurement or evidence relation. If the value is planned, it stays marked as expected work-resource use and does not become performed-work evidence.

When the aggregation divides a stock or resource amount, use PortionOf or the direct quantitative relation owner. When the aggregation slices one work occurrence or one carrier over time, use PhaseOf or the direct phase owner. Do not use MemberOf for resource stock, resource portion, or time-slice composition.

#Aggregation Rules

Resource vectors stay typed. Add joules to joules, hours to hours, kilograms to kilograms, and bytes to bytes. A conversion or equivalence relation needs its governing measurement, model, or mathematical-lens owner.

Partition additivity requires declared partitions. Resource values may be added across disjoint boundary partitions only after the boundary and stock relation are named. Shared stock, shared meters, shared people, shared tools, or overlapping time windows require an overlap or deduplication policy.

Time slicing requires temporal coverage. A resource roll-up over phases uses non-overlapping phase refs and a time window. If a missing phase matters, the admissible use is narrowed or B.1.4/C.27 supplies the temporal owner.

Plan and result stay separate. A method description or work plan may provide expected yield, expected duration, or expected resource use. Measured work-resource aggregation uses dated work occurrence evidence. Do not overwrite one with the other.

B.1 invariant carry-through. B.1.6 keeps B.1 invariants only for recovered work-resource ledgers. A singleton zero-resource occurrence is idempotent for the selected resource-accounting basis. Addition is commutative only for independent partitions, non-overlapping slices, or explicitly deduplicated overlaps. Weakest-link claims must name the critical resource, availability, or threshold; monotonicity claims must name the resource characteristic being improved. Apparent "free" gains remain measurement, equivalence, or whole-reidentification questions until their direct owner is recovered.

Proof-sketch obligations. For idempotence, show the zero-resource or singleton ledger under the selected resource-accounting basis. For commutativity or locality, show disjoint boundary partitions, disjoint time slices, or the declared deduplication relation. For weakest-link, name the critical resource and availability condition. For monotonicity, name the exact resource characteristic that cannot get worse under the selected improvement. These are user-facing obligations for the aggregation claim, not a separate proof package.

#Compact Obligation Rows

#Archetypal Grounding (Worked Slices)

Manufacturing cell. A frame is welded and painted in two dated work occurrences. B.1.6 records electricity, gas, consumables, and labor-hour ledgers with their time windows and meters. The step order belongs to B.1.4 or the method owner; the state change of the frame belongs to A.3.4.

Model training. A model-training run has epochs as dated work slices. B.1.6 aggregates compute energy, storage reads, and operator time from work evidence. The algorithm text is A.3.2; the trained model publication and source-use claims use episteme and publication owners; fairness or ethical assurance uses D-patterns when current.

Architecture documentation effort. A team records work spent building a multi-view architecture description. B.1.6 can aggregate the work-resource ledger. The architecture description itself remains C.30.AD; the usefulness or adequacy of a view remains C.30.ASV or its direct owner.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

This pattern gives FPF a conservative place for work-resource aggregation without turning it into a general method algebra. It makes resource claims usable across levels, phases, and contexts while keeping performed work evidence, measurement, temporal coverage, and transformation separate.

The cost is explicit accounting discipline. The gain is that resource roll-ups become comparable without claiming more than the evidence and boundary relation allow.

#Rationale

B.1.6 exists because work-resource accounting is easy to confuse with method, plan, phase, transformation, evidence, and whole reidentification. The governed object is the resource aggregation claim over dated work occurrences or explicitly narrowed estimates. That claim needs a ledger discipline: typed resource-accounting basis, holon delimitation, time window, stock and boundary-crossing relation, measurement or evidence relation, and overlap policy.

The pattern keeps the useful old Gamma_work notation, but only as notation over a recovered aggregation record. It also preserves the old planned-versus-measured warning: a method description or work plan can declare expected yield or expected resource use, but measured aggregation depends on dated work evidence.

#SoTA-Echoing

#Relations

• Builds on A.15.1 for dated work occurrence and on A.15 for role-method-work alignment.
• Coordinates with A.3.1, A.3.2, and A.15.2 for method, method description, and work plan.
• Coordinates with A.15.5 for work-entry readiness, full-kit condition, and resource readiness before work entry; B.1.6 may cite those refs but does not decide readiness.
• Coordinates with B.1.4 and C.27 for phase and temporal-claim adequacy.
• Coordinates with A.1, B.1, A.14, and C.13 for holon delimitation, part-whole, phase, and constructive grounding.
• Coordinates with A.3.4 for transformation. When whole reidentification or emergence-family wording is current, B.2.P tests the problem and the relevant B.2-family pattern governs the recovered claim.
• Coordinates with C.16, C.29, and A.10 for measurement, mathematical lens, and evidence relations; source-use and publication-use relations remain with E.17 or the direct source owner.

#B.1.6:End

#Meta-Holon Transition - Whole Reidentification

Type: Part B holonic construction pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Use This When

Use this pattern when a configured whole can no longer be treated as the same whole for the current claim: its delimitation, part relation, constitutive assembly, objective, supervision, capability envelope, agency threshold, or temporal consolidation has changed enough that the EntityOfConcern must be reidentified.

Typical moments:

• a set of coordinated parts becomes a regulated system with its own objective and externally visible commitments;
• a commissioning history crosses into operation and the assurance claim must restart for the operational whole;
• a theory, model family, or knowledge body becomes an episteme whole recognized under the already admitted U.Episteme kind rather than remaining a loose catalogue;
• separately governed structure, functioning, method, and work facts support a capability envelope that the existing whole cannot explain; evidence separately supports the claim about those facts;
• an architecture residual cannot be explained inside the existing whole.

First useful move. Try ExistingWholeExplanationCheck first. If the observed gain or shift can be explained inside the existing whole by better parts, corrected relations, improved measurement, method or work repair, richer phase coverage, or architecture-view repair, stay with the existing whole and use the direct governing pattern for that explanation. Use B.2 only when the whole itself must be reidentified.

What goes wrong if missed. Emergence becomes rhetoric, ordinary improvement is overclaimed as a new whole, or a genuinely new whole remains hidden under old part, evidence, assurance, architecture, or responsibility claims.

What this buys. B.2 gives one accountable whole-reidentification move: recover the exact existing whole, the separately governed facts that challenge its identity, the exact candidate new whole, and decide whether the existing whole continues or the new whole must carry the claim before relying on evidence, a record, or a receiving-use decision.

Not this pattern when.

• If the claim is ordinary part-whole construction, use B.1, A.14, and C.13.
• If the claim is a whole-level characteristic change, use C.16 and the direct measurement or evaluation pattern.
• If the claim is capability without whole reidentification, use the direct capability and characteristic patterns.
• If the claim is transformation or work, use A.3.4, A.12, A.15, and A.15.1.
• If the claim is only wording repair for emergence-family language, use B.2.P first.
• If the claim is graph, RG-like, MSPD, or other mathematical expression, use C.29 unless whole reidentification is also current.

#Problem Frame

A Meta-Holon Transition is not a new root ontology, generic emergence label, or mathematical graph result. It is a whole-reidentification claim about an exact holon already recognized through A.1 construction, identity, part relations, whole-level characteristics, and a direct kind-specific pattern.

The old whole remains a possible explanatory object. B.2 is selected only when it is no longer the right EntityOfConcern for the current claim. The candidate new whole can be recognized as a U.System, U.Episteme, U.Method, U.Work, U.Discipline, or another holon kind only after E.24.UK has admitted that public kind and the exact candidate satisfies A.1 plus the direct kind-specific criterion.

#Problem

Without B.2:

1. New whole is missed. A constructive assembly or coordinated closure changes the object, but evidence and architecture still point to old parts.
2. Ordinary improvement is overclaimed. A better component, stronger measurement, or corrected method is called emergence.
3. Record fields become ontology. A result field, trigger mnemonic, profile, or checklist is treated as a U-kind or actor.
4. Agency becomes binary. A threshold crossing is read as "agent or not agent" instead of a characteristic-space threshold for a system in role.
5. Mathematics replaces ontology. A graph, RG-like flow, MSPD score, or benchmark jump is treated as MHT without recovering the holon claim.
6. Transformation becomes containment. A system changing another holon is treated as that holon's super-holon.

#Forces

#Solution

Use B.2 as a world-side whole-reidentification pattern. Start with the actual wholes and the facts governed by their direct patterns; add records only when a receiving use needs them.

1. Name the exact existing whole, its admitted kind, and its identity or reidentification rule.
2. Recover each changed delimitation, constituent, constructive part relation, assembly, supervision, objective, capability, characteristic, or temporal fact under its direct pattern. A cue word, profile field, measurement, or graph edge does not make the fact obtain.
3. Test whether those facts can be explained as a change of the same whole. If repair, maintenance, changed characteristics, phase coverage, method or work correction, measurement, or architecture-view correction is enough under the existing reidentification rule, keep that whole and stop B.2.
4. If the existing whole is not enough, identify the exact candidate new whole and execute the complete A.1 criterion. Recover its constituents, obtaining constructive relations, assembly, reidentification rule, and composition-grounded whole characteristic. Also show that the candidate's actual boundary, interfaces, relevant characteristics, and identity-preservation conditions satisfy the applicability and compatibility conditions of at least one governed larger-assembly construction method or rule under which it can remain a constituent. Then name its already admitted holon kind and satisfy the direct kind-specific criterion. If a required condition fails, the candidate fails A.1; if missing evidence or an unavailable dependency prevents a determination, evaluation returns unknown.
5. State the whole-reidentification claim: why the existing whole no longer carries the current subject claim and why the candidate new whole is the EntityOfConcern. This comparison does not itself create, admit, or classify either whole.
6. Materialize a trigger profile, explanation check, reidentification assertion, or record only when named receiving work must inspect, cite, compare, or preserve that claim.

The optional MHTTriggerProfile, ExistingWholeExplanationCheck, and HolonReidentificationRecord below are ordinary C.2.1 epistemes. Their content can designate exact wholes, facts, claims, and relation occurrences; the content fields are not world-side participants and supply no substitute for the preceding move.

#MHTTriggerProfile

MHTTriggerProfile is a U.Episteme whose EntityOfConcern is the exact existing whole already recognized under an admitted holon kind. It collects exact current cues and support for asking whether whole reidentification is live. It is not MHT itself, and its content fields do not declare another relation.

The profile's effective U.ReferenceScheme, any current U.ClaimScope, and an independently selected model-use structure can qualify this episteme under C.2.1 when its receiving use needs them. They do not identify either whole, become MHT trigger facts, or make any referenced relation obtain. A single cue warrants attention; it does not establish whole reidentification.

#ExistingWholeExplanationCheck

ExistingWholeExplanationCheck is a U.Episteme whose EntityOfConcern is the same existing whole. It compares the observed change claim with direct explanations that preserve that whole.

If the existing-whole verdict is sufficient, stop B.2 and use the direct governing pattern named by the selected explanation claim. The checklist does not perform the repair and its content fields do not create the referenced claims or relations.

#HolonReidentificationRecord

HolonReidentificationRecord is an optional U.Episteme whose EntityOfConcern is the exact new holon. Use it only when receiving work needs a durable account of why that new holon, rather than the prior whole, is the current EntityOfConcern. Candidate classification remains a separately governed judgment.

The record does not make the A.1 criterion true, admit a public kind, or create the candidate new holon. E.24.UK owns public-kind admission; A.1 owns world-side recognition; C.2.1 owns the optional classification assertion; exact evidence and assurance relations own its warrant. Publication of the record is another relation under the publication patterns.

#Candidate New Whole Reference And Kind

Use one resultHolonRef : U.HolonRef for the candidate new whole and one resultHolonKindRef : U.KindRef for its kind. E.24.UK must already have admitted that public kind, and the candidate new whole must satisfy the A.1 constructive criterion plus any kind-specific membership condition. Neither the references nor the record establish those facts.

When downstream work must inspect or cite the classification judgment, add the optional resultHolonClassificationAssertionRef. That C.2.1 assertion may report a governed evaluation of true, false, or unknown; its evidence, warrant, and G.11 currentness stay separate from world-side criterion satisfaction. B.2 still asks a different question: whether the existing whole can continue to carry the subject claim or a new whole must be identified.

Do not use post* field names as live governed names. They hide the candidate new whole and its kind and invite temporal shorthand. Name that whole and its admitted public kind; cite a classification assertion only when the receiving use needs that episteme.

#Agency Threshold

Agency is not a binary status and not a root kind. Treat agency as a characteristic-space threshold for one exact system, predicate, claim scope, and qualification window.

Use A.13, A.19, and C.16 for the characteristic-space and threshold claim. Levin-line TAME work can discipline the multi-characteristic framing when agency evidence is relied on for the current claim. B.2 uses agency threshold only as one possible trigger in MHTTriggerProfile, and only when crossing the threshold changes closure, supervision, objective, or whole identity.

#Acting-System Participation

When a source describes a system changing another holon, recover acting-system participation and transformation separately.

Use A.12 for acting-side externalization, A.3.4 for bounded transformation, and A.15.1 for work occurrence. A system changing another holon does not become that holon's super-holon, and no U.Transformer kind is created.

#Mathematical-Lens Separation

Graph, algebra, RG-like, MSPD, benchmark, scaling, and morphism language can bear on MHT recognition only as mathematical or analytical expression.

Use C.29 when the mathematical lens is relied on for the current claim. Use B.2 only after the holon identity claim is recovered and the existing-whole explanation check leaves a whole-reidentification question.

#Keep Whole Identity, Evidence, Currentness, And Reliance Separate

Keep five results apart:

• the existing whole and candidate new whole, their constituents, obtaining constructive relations, assemblies, characteristics, and identity rules are world-side objects and facts under their direct patterns;
• a B.2 whole-reidentification assertion is a C.2.1 episteme about those objects;
• evidence and assurance relations support or warrant the assertion's claim content but create neither whole and decide neither identity rule;
• G.11 decides whether the selected assertion or record edition is current for the receiving use;
• receiving work decides whether to rely, decline to rely, defer, or reopen.

Evidence present or missing, and a current or stale record, can change what an evaluation returns and whether receiving work relies. They cannot turn the same whole into a new whole or a new whole into the same one. Whether the existing whole continues or a new whole must be identified follows the direct identity and reidentification rules plus the actual construction facts. A.1 recognition of either candidate supplies no B.2 warrant and does not select B.2.

#Archetypal Grounding (Worked Cases)

#Closed-Loop Regulated System

Parts: plant, sensor, controller, actuator.

Existing-whole repair may be enough if only a sensor improved or a controller parameter changed. B.2 becomes current only when exact constructive relations and a governed assembly close the feedback and supervision around an objective, yielding a candidate system whose boundary, external commitments, and capability envelope are no longer explainable as changes of the existing whole. The candidate can satisfy A.1 only if its actual boundary, interfaces, relevant characteristics, and identity-preservation conditions also satisfy at least one applicable governed larger-assembly construction method or rule—for example, a rule under which the regulated system can remain one constituent of a larger plant or production system. If that compatibility condition does not hold, the candidate fails A.1; if the needed evidence or dependency is unavailable, evaluation remains unknown. Loop closure, a record, or a measurement supplies none of those facts.

MHTTriggerProfile@Control : U.Episteme
  EntityOfConcernSlot: plant-plus-devices configuration
  content:
    changedSupervisionRelationRefs: closed feedback relation
    changedObjectiveClaimRef: maintain output y near reference r
    changedCapabilityClaimRef: capability envelope after closure

HolonReidentificationRecord@Control : U.Episteme
  EntityOfConcernSlot: regulated control system
  content:
    existingWholeRef: plant-plus-devices configuration
    selectedTriggerProfileRef: MHTTriggerProfile@Control
    existingWholeExplanationCheckRef: ClosedLoopExistingWholeCheck
    resultHolonRef: regulated control system
    resultHolonKindRef: U.System
    resultHolonClassificationAssertionRef: RegulatedControlSystemClassificationAssertion
    wholeReidentificationClaimRef: ClosedLoopWholeReidentificationClaim
    changedClaimGoverningPatternRefs: A.1, B.1.2, B.2.2, C.30.LCA, A.2.2

EntityOfConcernSlot belongs to the ordinary C.2.1 episteme-slot relation. The indented content names references carried by each episteme; those labels are not participant SlotKinds of a new MHT relation. The feedback and capability relations retain their direct identities, while the optional classification assertion retains its own C.2.1 identity and does not establish world-side holonhood.

#Compendium Becomes Theory

A collection of results can remain a catalogue. B.2 becomes current only when the knowledge body is reidentified as an episteme whole with its own claim-bearing structure, explanatory objective, reference scheme, and evidence relations.

B.2.3 specializes this case when the exact candidate new holon named by the MHT claim is recognized under the already admitted U.Episteme kind. C.2.1 and the episteme family own episteme constitution, publication, source use, and claim-bearing structure.

#Capability Envelope Appears

Several systems, methods, and work occurrences align and a new capability envelope appears. Apply the direct capability, characteristic, function, transformation, method, work, evidence, and architecture patterns first.

Use B.2.4 only when separately governed capability or functioning facts make a whole-reidentification question live under B.2. Evidence can support the claim about those facts; it creates neither the facts nor the question.

#Lathe And Workpiece

A lathe transforms a workpiece. That is transformation and work, not MHT and not parthood. B.2 becomes current only if the manufacturing arrangement creates or reveals a new whole that must be reidentified, such as a production cell with exact constituents, obtaining coordination and supervision relations, a governed assembly, an objective, a whole-level capability, and a reidentification rule that the earlier arrangement lacks. A.1 recognition additionally requires the cell's actual boundary, interfaces, relevant characteristics, and identity-preservation conditions to fit at least one applicable governed construction method or rule under which the cell can remain a constituent of a larger production system.

#Same Whole, New Whole, And Lost Evidence

Replacing Pump #37's seal is an ordinary constituent change when the pump's reidentification rule admits that maintenance phase. The same pump remains the EntityOfConcern; use the direct maintenance, part-relation, work, transformation, and characteristic patterns and stop B.2.

Closing a controller-sensor-actuator loop can yield a new regulated-system whole only when the exact candidate assembly, supervision and coordination relations, boundary, objective, whole-level capability, admitted U.System kind, and reidentification rule satisfy A.1 and the system criterion. Its actual boundary, interfaces, relevant characteristics, and identity-preservation conditions must also satisfy at least one applicable governed larger-assembly construction method or rule under which the regulated system can remain a constituent. If that condition fails, the candidate fails A.1; if the needed evidence or dependency is unavailable, evaluation returns unknown. A wiring diagram, commissioning record, loop closure, or capability measurement alone supplies none of those construction or compatibility facts.

If the support for the reidentification assertion is present and its edition is current, receiving work may rely on it. If the same evidence is unavailable, evaluation can return unknown; if the record is stale, G.11 can disqualify that edition; and receiving work may decline, defer, or reopen. None of those branches changes whether the regulated-system whole actually exists or whether the prior configuration remains the same whole.

#Selected Structure And Transformation Stops

A selected BoundedModelUseStructure organizes exact model-use relations. It is not the new holon named by an MHT claim and gains no parts, agency, or whole identity from selection, naming, or a Context Map.

Several actual changes during assembly may each be exact U.Transformation occurrences. B.2 does not treat them as constituents of one composite transformation. If whole reidentification would require positive transformation composition, transformation parthood, or composite-transformation identity and no direct governor supplies contribution, compatibility, boundary, interfaces, and reidentification, retain the exact blocker and the independently identified changes. The missing composition facts do not show that any change is atomic.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• MHT becomes a precise whole-reidentification move rather than a synonym for improvement.
• Cases involving a candidate new system, episteme, method, work occurrence, or discipline use the same B.2 whole-reidentification solution while retaining their direct governing patterns.
• Trigger language remains useful without becoming ontology.
• Mathematical and benchmark evidence can be used without replacing the holon claim.

Costs:

• Users must try existing-whole explanations before declaring MHT.
• MHT records require a reference to the exact candidate new whole, a reference to its already admitted public kind, A.1 recognition, and the evidence needed by any classification assertion used downstream.
• Some attractive emergence claims will return to ordinary characteristic, method, work, architecture, or measurement repair.

#Rationale

Holonic work needs a way to recognize when a whole has changed enough that the old EntityOfConcern no longer carries the current claim. B.2 provides that move without collapsing all novelty into "emergence" and without inventing record-field U-kinds.

The pattern is intentionally conservative: it applies repairs from direct governing patterns first, then supports whole reidentification only when the existing whole no longer explains the observed shift. This protects B.1 part-whole construction, A.15 work, A.3.4 transformation, C.16 characteristics, C.29 math-lens use, and episteme and publication discipline from being swallowed by MHT.

#SoTA-Echoing

#Relations

• Builds on: A.1 for world-side holon recognition, B.1 for part-whole construction, A.14 and C.13 for relation and constructional grounding, and E.24.UK for one-time public-kind admission.
• Coordinates with: A.12 and A.3.4 for acting-side and transformation, A.15 and A.15.1 for method and work, C.16 and A.19 for characteristic space and threshold, C.2.1 for optional claim and record epistemes, A.10 and B.3 for evidence and warrant, G.11 for edition currentness, C.29 for mathematical lenses, and C.32.P2S when architecturing pressure becomes whole reidentification rather than local structure repair.
• Specialized by: B.2.2 when the candidate new whole is a system, B.2.3 when it is recognized under the admitted U.Episteme kind, and B.2.4 when capability or functioning facts require whole reidentification.
• Can use neighboring evidence from: B.2.5 when a supervisor-subholon feedback relation is part of the B.2 case evidence or neighboring structure; that does not make B.2.5 a specialization for the candidate new holon's kind.
• Uses: B.2.P when emergence-family, MHT, MET, MFT, synergy, or metric-mirage wording hides which claim kind is current before B.2 is applied.

#B.2:End

#Emergence and MHT Precision Restoration

Type: Part B precision-restoration pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Use This When

Use this pattern when wording such as emergence, emergent, synergy, higher-level property, meta-system, meta-epistemic, meta-functional, MHT, MET, MFT, promotion, post*, or collection words mixed with those terms could be pointing to several different FPF objects.

The first useful move is:

Recover the claim kind before choosing replacement wording.

B.2.P is selected only when the source wording hides one of these recurring questions:

• Is this a B.2 whole-reidentification claim?
• Is the candidate new whole a system or episteme, or do capability and functioning facts make whole reidentification necessary?
• Is this only a characteristic, capability, functioning, architecture, evidence, measurement, or mathematical-lens claim?
• Is a collection, fleet, community, pool, or base being admitted as a whole, acting collective, whole-level characteristic bearer, or merely a membership set?
• Is a metric jump or benchmark result being overread as a new whole?

What goes wrong if missed. A word like "emergent" becomes a shortcut to a new U-kind, a collection receives agency by name, a metric jump becomes MHT, or source title mnemonics survive as if they were current pattern authority.

What this buys. B.2.P gives one local recovery profile for emergence-family and MHT wording. It keeps B.2-family subject patterns centered on whole reidentification while ordinary capability, characteristic, function, architecture, evidence, math-lens, publication, and collection claims remain with their direct owners.

Not this pattern when.

• If the text already names the governing pattern and object by value, use that pattern directly.
• If the question is ordinary collection admission without emergence, synergy, MHT, metric mirage, or whole-reidentification wording, use [A.14](/generated/patterns/A.14), [C.13](/generated/patterns/C.13), [B.3.5](/generated/patterns/B.3.5), [A.1](/generated/patterns/A.1), [A.15](/generated/patterns/A.15), A.2 patterns, or [C.16](/generated/patterns/C.16) directly.
• If the question is phrase-level plain technical rewriting after the object is recovered, use [F.19](/generated/patterns/F.19).
• If the question is general wording-use architecture, use [E.10](/generated/patterns/E.10) and [E.10.ARCH](/generated/patterns/E.10.ARCH).

#Problem Frame

Emergence-family wording is overloaded. It can point to a new system whole, an episteme whole, a capability envelope, a characteristic crossing, an architecture residual, a mathematical scale expression, a benchmark artifact, a publication claim, or a collection-as-whole question.

It asks which exact EntityOfConcern, world-side or claim-side fact, and direct governing pattern are current, and whether the same whole still carries the claim.

#Problem

Without B.2.P:

1. Generic emergence becomes ontology. U.Emergence or an equivalent hidden kind appears even though no such root kind is selected.
2. Collections become systems by poetry. A fleet, community, pool, or base is treated as an acting system because the phrase sounds collective.
3. Capability becomes MHT. A new capability envelope or functioning relation is treated as a new whole without checking existing-whole explanations.
4. Mathematics becomes declaration. A graph, scaling law, RG-like expression, benchmark jump, or MSPD score is treated as whole reidentification.
5. Old mnemonic titles become current owners. Source labels such as MET or MFT hide whether the claim concerns an episteme whole, capability or functioning facts, evidence for those facts, or something else.
6. Semio-bias returns. Publication, dashboard, model, or source interpretation claims displace the in-life holon or characteristic under concern.

#Forces

#Solution

Recover the claim kind and direct owner before any wording replacement.

#Emergence Claim-Kind Recovery

Read the sentence once and recover five things before rewriting it:

1. Practical use. What decision, explanation, design move, or stop depends on the sentence?
2. Exact object. Is the concern an existing whole, candidate new whole, collection, characteristic, capability, functioning relation, structure, transformation, measurement result, assertion, or mathematical expression?
3. Concrete claim. What changed or obtains: construction, identity, capability, characteristic value, evidence, publication, representation, or only the wording?
4. Direct owner. Which pattern governs that object and claim without using emergence as a substitute?
5. Disposition. Keep the exact direct claim, open B.2 only for a remaining whole-reidentification question, or stop with the exact missing object or governor.

A temporary author note may retain the source phrase, exact object, direct owner, blocked overread, and replacement or stop. The note is not a U-kind, relation, result object, or required project record. Do not ask a practitioner to fill a generic emergence card before the direct object can be named.

#Claim-Kind Recovery and Owner Selection Table

#Whole-Reidentification Recovery

When a whole-reidentification question remains after claim-kind recovery, do not create a second MHT schema. Return to B.2 with this concrete account:

1. name the exact existing whole, admitted kind, and identity or reidentification rule;
2. name each changed delimitation, constituent, constructive relation, assembly, supervision, objective, capability, characteristic, or temporal fact and its direct owner;
3. try the existing-whole explanation and state whether it preserves the existing whole;
4. if a new whole is still needed, return to B.2 and execute the complete A.1 criterion: name the exact candidate, its constituents, obtaining constructive relations, assembly, reidentification rule, and composition-grounded whole characteristic; show that its actual boundary, interfaces, relevant characteristics, and identity-preservation conditions satisfy at least one applicable governed larger-assembly construction method or rule under which it can remain a constituent; then name its already admitted kind and satisfy the direct kind-specific criterion;
5. state whether the direct identity rules preserve the same whole or require a new whole for the current subject claim;
6. only when a specific downstream task must inspect or cite the decision, identify any separate assertion or record, supporting evidence and warrant, G.11 currentness result, and rely, decline, defer, or reopen decision.

Evidence availability, an evaluation value, a record field, and receiving reliance neither construct the candidate nor decide whether the existing whole continues or a new whole must be identified. If the exact candidate, one required constructive fact, or the larger-assembly compatibility condition has no governor, stop with that missing object or governor rather than writing candidateResultRef, resultKindRef, mhtWitnessRef, or a context-shaped placeholder.

#Collection Boundary

Collection words enter B.2.P only when they are entangled with emergence, synergy, MHT, metric mirage, or whole-reidentification wording.

If the claim is plain collection admission:

• use A.14 for membership and part-whole relation vocabulary;
• use C.13 for collection-as-whole constructional grounding;
• use B.3.5 for working-model assurance grounding;
• use A.1 with A.15 and A.2 patterns for an acting collective admitted as U.System;
• use C.16 for a whole-level characteristic.

B.2.P may point to these direct owners; it does not own their claims. An unassembled collection remains an unassembled collection even when a list, dashboard, or project card names it as one whole. A C.13 collection construction does not by itself establish an integrated assembly, acting system, or A.1 holon.

#Source Mnemonics and Result Fields

Treat source labels and short forms as recognition cues until the concrete thing or claim and its direct pattern are identified.

• MET may point to a claim that the candidate new whole is an episteme, source-title wording, episteme morphing, publication synthesis, or a source-only phrase. Identify the concrete claim before use.
• MFT may point to capability and functioning whole reidentification, a functional-structure view, function-like wording, method and work collapse, or source-only phrase. Recover before use.
• promotion may hide whole reidentification, status change, release, gate, publication, or project process wording. Recover before use.
• post* fields do not survive as generic governed names. When B.2 is current, name the exact candidate new whole and its already admitted holon kind directly; cite an optional classification assertion or reidentification record only when receiving work needs that episteme.

Do not keep the source label as the pattern owner merely because it is recognizable.

#Archetypal Grounding (Worked Cases)

#"The Fleet Emerged As A New Actor"

Recover:

• Is "fleet" a membership set, collection-as-whole, acting collective system, or the candidate new system named by an MHT claim?
• Does the agency wording name a system in role, an agency-threshold claim, or only ordinary prose?
• Does the candidate new system have its own delimitation, objective, coordination, and capability envelope, and is the reidentification claim separately supported by evidence and assurance?

If the candidate new whole is an acting system, use B.2 and B.2.2. If the case is only a managed collection with a whole-level metric, use A.14, C.13, B.3.5, and C.16.

#"The Model Shows Emergent Robustness"

Recover:

• Is the model a description episteme or mathematical-lens expression?
• Is robustness a characteristic-space claim?
• Is the result a benchmark artifact?
• Is there an in-life holon whole-reidentification question?

Most cases use C.29, C.16, A.10, and source-use owners. Use B.2 only if the in-life whole has to be reidentified.

#"A Meta-Functional Transition Happened"

Recover:

• Is there capability or functioning evidence?
• Do separately governed capability or functioning facts make a whole-reidentification question live, with evidence only supporting the claim about those facts?
• Is the concern function-like wording, a functional-structure view, a method-and-work relation, or a candidate new holon?

Use B.2.4 only for the B.2-facing whole-reidentification case. Otherwise use A.6.F, A.2.2, C.16, A.3.4, C.30.TFS-REL, A.15, or architecture owners.

#"The Selected Context Became A Meta-System"

Recover the exact selected relation organization. If it is BoundedModelUseStructure, keep it as dependent U.Structure under A.1.1 and A.22. A context label, Context Map, diagram, or selection decision supplies no constituents, part relations, agency, holonhood, or MHT. If the source instead concerns an actual system whole, identify that system and its construction independently before B.2.

#"The Evidence For Emergence Was Lost"

Recover the exact whole-reidentification assertion, its evidence or assurance relation, the selected assertion edition, and the receiving work. Missing evidence can make a governed evaluation return unknown; a stale edition can fail G.11 currentness; receiving work can decline, defer, or reopen. None of those results reverses an actual construction or changes the direct rule that decides whether the existing whole continues or a new whole must be identified. Do not rewrite evidence loss as absence of the whole or as a new MHT.

#"The Assembly Changes Form One Higher-Level Change"

Identify each actual change independently under A.3.4. A shared work occurrence, flow, changed referent, time window, method decomposition, or C.13 construction trace does not make those changes parts of one transformation. If the use requires a composite transformation and no direct governor supplies constituent contribution, compatibility, boundary, interfaces, whole identity, and reidentification, return that exact blocker. Do not infer either composition or atomism.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• B.2-family emergence language no longer creates hidden U-kinds.
• B.2, B.2.2, B.2.3, and B.2.4 stay centered on their subject claims instead of carrying repeated first-stage precision restoration.
• Collections, capabilities, functions, characteristics, architecture residuals, mathematical expressions, and publications keep their direct owners.

Costs:

• Ambiguous emergence-family phrases take one recovery step before use.
• Some attractive umbrella claims become narrower direct-owner claims.
• Old mnemonic labels may survive only as quoted source wording or reduced-use cues unless the concrete thing or claim and its direct pattern are identified.

#Rationale

Emergence-family wording is useful because it marks a possible explanatory concern. It is dangerous because it can hide the actual object: a holon, system, episteme, capability, characteristic, architecture structure, mathematical expression, evidence relation, source publication, or collection.

B.2.P follows the E.10.ARCH algorithm: recover ontology first, then choose wording. This prevents one word from creating several local ontologies.

#SoTA-Echoing

#Relations

• Builds on: E.10, E.10.ARCH, E.24, F.18, and B.2.
• Returns whole reidentification to: B.2, with B.2.2, B.2.3, and B.2.4 as current specializations.
• Keeps collection admission with: A.14, C.13, B.3.5, A.1, A.15, A.2 patterns, and C.16.
• Coordinates with: A.2.2, C.16, A.6.F, A.3.4, C.30, A.22, A.1.1, C.30.ASV, C.30.TFS-REL, C.30.ILC, C.32.P2S, C.29, A.10, B.3, C.2.1, G.11, E.17, and source-use patterns.

#B.2.P:End

#Meta-System Transition - System Specialization of MHT

Type: Part B holonic construction pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Use This When

Use this pattern when B.2 has identified one exact candidate new whole and that same individual must be recognized under the already admitted U.System kind: a swarm, production cell, cloud platform, regulated control system, organizational unit, or another physical or operational whole that can act in work or transformation while remaining itself.

The first useful question is not "is there emergence?" First test the exact candidate against A.1's six common components. Then test whether its physical or operational organization makes it eligible to act in work or transformation while preserving its identity—the direct U.System criterion. After those two tests, recover only the additional facts used by the concrete case, such as delimitation, an objective or commitment, coordination, capability, role, method, work, transformation, functioning, architecture, evidence, assurance, or time, and state each such fact or claim under its direct owner. Do not make an objective or commitment a condition for U.System recognition; require it only for the separate objective or commitment claim being made.

Use B.2 first to decide whether whole reidentification is needed and to identify the one candidate new whole. Use B.2.2 only when that candidate's already admitted kind is U.System.

What goes wrong if missed. A real operating whole is still managed through old component claims, or a mere collection is declared a new system without system participation evidence.

What this buys. The system MHT keeps the useful meta-system-transition intuition while preserving FPF's direct owners for system participation, architecture, capability, transformation, work, evidence, and assurance.

Not this pattern when.

• If the result whole is claim-bearing and non-agentive, use B.2.3 and the episteme family.
• If the evidence is only a capability or functioning gain without whole reidentification, use A.2.2, C.16, A.6.F, A.3.4, C.30.TFS-REL, and A.10.
• If the claim is ordinary system aggregation or delimitation, use B.1.2, A.1, A.14, and C.13.
• If the claim is a mathematical, simulation, graph, benchmark, or scaling expression, use C.29 and the relevant description or publication pattern before returning to B.2.
• If the claim is only supervisor-subholon feedback relation inside an already admitted system whole, use B.2.5.

#Problem Frame

B.2 is holon-general. B.2.2 is its U.System specialization.

A system-result MHT is current when B.2's exact candidate new whole is an acting physical or operational holon and the case needs that same whole to carry one or more separately governed system-level claims, such as delimitation, objective, coordination, capability, functioning, architecture, transformation, work, assurance, or time. The old constituent systems may remain parts, participants, resources, or interacting neighbors, but their claims do not automatically become claims about the candidate system.

A collection of systems is not thereby a system MHT. B.2.2 carries B.2's existing-whole/new-whole comparison through complete A.1 recognition and the direct U.System criterion; it does not create a system-specific result object or record schema.

#Problem

Without this specialization:

1. System identity stays on old parts. The project keeps component assurance, component responsibilities, and component interfaces after the operating whole has changed.
2. System claims become rhetoric. A group gets a collective name, but no candidate-system delimitation, objective, obtaining coordination relation, or capability envelope is established.
3. Supervision is overread. A coordination mechanism is treated as a super-holon, safety warrant, or complete system recognition.
4. Transformation is confused with containment. One system changing another holon is treated as part-whole construction instead of transformation and work.
5. Architecture description replaces architecture. Dashboards, diagrams, simulations, bills, and digital twins are treated as the operating system rather than descriptions of it.

#Forces

#Solution

After B.2 leaves a whole-reidentification question open, continue with the same exact candidate new whole and direct facts. Add no system-specific result species or context-shaped slice.

#Reuse The B.2 Candidate And Complete System Recognition

Keep B.2's one resultHolonRef for the exact candidate new whole and its one resultHolonKindRef, which here resolves to the already admitted U.System kind. The references may appear in B.2's optional HolonReidentificationRecord when a receiving use needs a durable account; B.2.2 adds no second record.

Before calling the candidate a system result:

1. execute the complete A.1 criterion over the candidate's exact constituents, obtaining constructive relations, governed assembly, reidentification rule, and composition-grounded whole characteristic;
2. show that its actual boundary, interfaces, relevant characteristics, and identity-preservation conditions satisfy at least one applicable governed larger-assembly construction method or rule under which it can remain a constituent;
3. apply the direct U.System criterion to that same individual: its actual physical or operational organization must make it eligible to act causally in work or transformation while preserving its identity;
4. recover only the additional system facts used by the concrete case—including any delimitation, objective, commitments, coordination, capability, role, method, work, transformation, functioning, architecture, evidence, assurance, or temporal claim—and keep each with its direct owner; and
5. keep the classification judgment, evidence or assurance, currentness, and receiving reliance separate from those world-side facts.

If a required A.1 component or the acting-eligibility criterion fails, do not identify the candidate as the system result. If an additional system fact needed for another claim is absent, withhold that claim rather than treating its absence as failure of the U.System criterion. If missing evidence or an unavailable dependency prevents a determination, report unknown; neither a filled reference nor an optional record changes that result.

#Carry Result-System Claims Through Direct Owners

When the candidate is recognized as U.System, state every changed result-system fact or claim under its direct owner:

• role assignments through A.2.1 and role-relation owners;
• capabilities through A.2.2 and C.16;
• methods and mechanisms through A.15, A.6.1, and their current direct owners;
• transformations through A.3.4;
• work occurrences through A.15.1;
• functioning and functional structure through A.6.F and C.30.TFS-REL;
• architecture through C.30, A.22, and C.30.ASV;
• evidence and assurance through A.10, B.3, and B.3.5;
• temporal and dynamics claims through C.27, A.19, and the direct temporal owners.

Do not reuse old component evidence as if it automatically covered the candidate system. Carry an unchanged component claim only through its exact continuing relation; establish each changed result-system fact under its direct owner and support the associated claim through a separate evidence or assurance relation.

#System Trigger Interpretation

When a receiving use has materialized B.2's optional MHTTriggerProfile, read its cues for a system case as follows:

No cue is enough by itself. Each row points to facts and claims to inspect; B.2's direct existing-whole/new-whole comparison, complete A.1 recognition, and the system-kind criterion decide the result.

#Delimitation and External Acting Systems

For system-result MHT, distinguish:

• a part of the result system;
• an external acting system that changes the result system or a constituent;
• an environment or resource that participates in work;
• a description, dashboard, twin, model, diagram, or publication about the result system.

A lathe making a workpiece, a controller steering a plant, or a teacher changing a learner does not become a super-holon merely because it changes another holon. Use A.12, A.3.4, and A.15.1 for acting side, transformation, and work. Use part-whole owners only when parthood itself is admitted.

#Assurance Re-Basing

When the exact candidate new whole is recognized as U.System, test old assurance against that system rather than transferring it by name.

Ask:

• Which component evidence still applies unchanged?
• Which evidence applies only through explicit correspondence or source-use relation?
• Which assurance claims must be rewritten for the result system?
• Which architecture, capability, functioning, work, temporal, or evidence claims now have different owners?

A claim about the candidate system may reuse component evidence only through an exact correspondence or source-use relation and a fresh evaluation of applicability. The candidate does not inherit safety, reliability, responsibility, or performance claims by label.

#Archetypal Grounding (Worked Cases)

#Bias-Annotation

#Cloud Platform

Independent services become a platform only if the current claim concerns a result system: a shared control plane, system-level SLO, deployment and rollback coordination, platform-level evidence, and external commitments.

If the only change is a better dashboard or one more service, use architecture-description, publication, measurement, or component owners. Use B.2.2 only when B.2 identifies the operating platform itself as the exact candidate new whole and that candidate passes A.1 plus the direct U.System criterion.

#Production Cell

A machine, robot, fixture, workpiece carrier, and inspection station can become a production cell when the cell has its own delimitation, objective, obtaining coordination relations, transformation structure, exact work occurrences, and capability envelope. Evidence separately supports the claims about those facts.

The fixture being manufactured is not part of the machine merely because the machine changes it. The production cell claim needs a result system; the manufacturing relation remains transformation and work.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• Meta-system transition remains usable for engineering and organizational systems without making B.2 system-only.
• System ontic preservation becomes explicit: the same exact candidate is recognized under A.1 and U.System, while each system fact and claim stays with its direct owner.
• Assurance, responsibility, architecture, work, and evidence claims are kept with their direct owners.

Costs:

• A system-result MHT cannot be declared by name, diagram, dashboard, or metric jump alone.
• Teams must separate old component evidence from result-system evidence.
• Some apparent emergence claims return to ordinary system aggregation, capability, measurement, or architecture repair.

#Rationale

Valentin Turchin's meta-system transition remains a useful intuition for the system case: components can become a higher operating whole when coordination and control create a new object of management and assurance. FPF generalizes that intuition in B.2, then uses B.2.2 to keep the classical system case precise.

The key distinction is ontological, not lexical. A candidate system is not a trigger profile, coordination mechanism, graph, description, dashboard, or process label. It is one exact candidate new whole that satisfies A.1 and the direct U.System criterion; every changed system fact and claim stays with its direct owner.

#SoTA-Echoing

#Relations

• Specializes: B.2 for one exact candidate new whole independently recognized under the already admitted U.System kind.
• Builds on: A.1, B.1.2, A.14, and C.13 for holon and system delimitation and part-whole grounding.
• Coordinates with: A.12, A.3.4, A.15, A.15.1, A.2.1, A.2.2, C.16, A.6.F, C.30, A.22, C.30.ASV, C.30.TFS-REL, A.10, B.3, and B.3.5.
• Uses: B.2.5 when supervisor-subholon feedback relation is part of the system-result evidence.
• Contrasts with: B.2.3 for MHT-result holons admitted as U.Episteme and B.2.4 for capability and functioning whole-reidentification evidence.

#B.2.2:End

#Meta-Holon Transition With Episteme Result

Type: Part B holonic construction pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Use This When

Use this pattern when B.2 has identified one exact candidate new whole and that same individual must be recognized under the already admitted U.Episteme kind: a theory, model family, standard, doctrine, specification body, research programme, field-level knowledge body, or other claim-bearing non-agentive holon.

Use B.2 first to decide whether whole reidentification is current and to identify the one candidate new whole. Use B.2.3 only when its resultHolonKindRef resolves to U.Episteme.

First useful move. For B.2's exact candidate, identify one U.ClaimGraph, one exact EntityOfConcern, and one effective U.ReferenceScheme, then test whether their EpistemeConstitutionRelation obtains under C.2.1. Keep grounding, viewpoint, view, publication, source use, representation, evidence, and assurance in their neighboring direct relations.

What goes wrong if missed. A catalogue, literature review, dashboard, model repository, or vocabulary is called a new theory without claim-graph reidentification; or a real new episteme whole is treated as a pile of publications.

What this buys. The pattern preserves B.2 whole reidentification while keeping episteme ontology with C.2.1 and the episteme family. It prevents episteme-result MHT from becoming episteme agency, publication authority, generic emergence, or a second episteme ontology.

Not this pattern when.

• If the result whole is an acting physical or operational holon, use B.2.2.
• If the question is episteme constitution, empirical grounding, publication, source use, view, viewpoint, ClaimGraph, reference scheme, or description use without MHT, use C.2.1, C.2.P, C.2.P.DR, E.17, and the direct episteme-family owner.
• If the question is effect-free episteme morphing, viewing, retargeting, or controlled semantic coarsening, use A.6.2, A.6.3, A.6.4, or A.6.3.CSC.
• If the question is synthesis work, use A.15.1 for performed work and A.12 or A.3.4 for acting-side and transformation claims.
• If the wording is ambiguous emergence-family language, use B.2.P before selecting B.2.3.

#Problem Frame

A library is not a theory, and a theory is not its publication.

A group of papers, models, datasets, design notes, forecasts, standards, or local doctrines may remain a collection. B.2.3 becomes current only when B.2's exact candidate new whole can be constructively recognized under A.1 and the current C.2.1 constitution criterion identifies that same individual as one claim-bearing episteme.

B.2.3 introduces no special episteme result object. It retains B.2's one resultHolonRef and resultHolonKindRef, then returns episteme constitution and every neighboring relation to C.2.1 and its direct owners.

#Problem

Without this specialization:

1. Catalogues become theories. Aggregated publications or dashboards are treated as a new episteme because they are stored together.
2. Theory becomes publication. The paper, report, standard document, model card, or dashboard is used as the episteme itself.
3. Episteme receives agency. The theory, standard, or doctrine is described as if it performs work or enforces behavior by itself.
4. Morphing becomes MHT. A view, retargeting, coarsening, translation, or model transformation is treated as a new episteme whole.
5. Assurance is inherited silently. Trust in constituent sources is treated as trust in the reidentified episteme whole.
6. Generic emergence replaces claim structure. "Emergent theory" hides the actual claim graph, reference scheme, and grounding relation.

#Forces

#Solution

Use B.2.3 as the U.Episteme specialization of B.2. Reuse B.2's exact existing whole, exact candidate new whole, direct construction facts, and optional C.2.1 records; add no context-shaped slice or episteme-result schema.

#Reuse The B.2 Candidate And Complete Episteme Recognition

Keep B.2's one resultHolonRef for the candidate and its one resultHolonKindRef, which here resolves to the already admitted U.Episteme kind. Execute the complete A.1 criterion over that candidate, including the larger-assembly applicability and compatibility condition. Then apply C.2.1 to the same individual:

1. identify its exact claim content as one U.ClaimGraph;
2. identify the exact independently governed U.Entity that those claims concern;
3. identify the effective U.ReferenceScheme under which the claims are read about that entity; and
4. test whether the direct EpistemeConstitutionRelation among those participants obtains and yields one interpretable claim-bearing whole.

The candidate and its constitution relation are distinct, even though C.2.1 reidentifies them from the same participant triple. A card, tuple, repository, publication set, graph representation, or filled reference does not make the relation obtain. If A.1 or C.2.1 fails, do not identify the candidate as the episteme result; if a required dependency cannot be evaluated, return unknown.

#Keep Constitution And Neighboring Relations Separate

The exact ClaimGraph, EntityOfConcern, and effective ReferenceScheme are the three participants of C.2.1's EpistemeConstitutionRelation. That constitution relation does not by itself identify A.1 constituents or constructive part relations. When A.1 requires those facts, recover them from an exact direct episteme-part or claim-composition owner. The EntityOfConcern remains an independently governed entity related through aboutness and reference. Keep all other current questions in their direct relations:

• empirical grounding uses EpistemeEmpiricalGroundingRelation only when designated empirical claims have current claim-to-world mappings involving the exact grounding holon;
• viewpoint selection and U.View recognition use their description-context and conformance owners;
• publication occurrence, publication form, carrier, source use, and C.29 representation remain distinct from the episteme and its constitution;
• synthesis work belongs to the acting system, method, work, and transformation owners; and
• evidence and assurance support or challenge exact claims but do not enter episteme identity or establish constitution.

Add only the neighboring object or relation required by the receiving use. Do not infer any of them from a publication set, and do not turn them into extra identity positions.

#Episteme Trigger Interpretation

When a receiving use has materialized B.2's optional MHTTriggerProfile, interpret its cues without giving agency to epistemes:

These cues identify claims and relations to inspect. They neither constitute the candidate episteme nor select B.2; the direct facts, complete A.1 criterion, C.2.1 constitution test, and B.2 existing-whole/new-whole comparison decide the result.

#Blocked Readings

Do not use B.2.3 as:

• a name for generic emergence;
• an authority claim for a publication;
• an agentive claim about a theory, standard, or doctrine;
• an effect-free episteme morphism, view, retargeting, or coarsening;
• a second episteme ontic beside C.2.1;
• a shortcut from source synthesis to high trust;
• a replacement for source-use, evidence, assurance, or publication patterns.

#Archetypal Grounding (Worked Cases)

#Bias-Annotation

#Model Family Becomes Theory

A model family can remain a toolbox. It becomes an episteme-result MHT only if B.2's candidate passes A.1 and one exact ClaimGraph, EntityOfConcern, and effective ReferenceScheme stand in an obtaining C.2.1 constitution relation. Empirical grounding and explanatory or predictive use are checked through neighboring direct relations when the receiving use needs them; they are not extra identity constituents.

If the change is only a new model publication or benchmark score, use publication, source-use, measurement, evidence, and mathematical-lens owners instead.

#Standard Body

A set of clauses, examples, and annexes can become a standard episteme when the result is one claim-bearing whole with terms, references, scope, conformance claims, and publication forms.

The standard is not the committee, not the PDF, and not the work of enforcement. The committee is an acting system or role-bearing system; the PDF is a publication form; enforcement is work by systems in role.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• Episteme-result MHT becomes usable without preserving title mnemonics as ontology.
• C.2.1 remains the episteme ontic owner.
• Publications, source use, synthesis work, evidence, assurance, and acting systems remain separate.

Costs:

• A claimed synthesis must identify and test the current C.2.1 constitution, not only cite a portfolio.
• Result-episteme assurance requires fresh relation work.
• Some "new theory" claims return to publication, source-use, morphism, benchmark, or evidence owners.

#Rationale

Knowledge synthesis can create a new holon, but only when the result is a reidentified claim-bearing episteme. B.2.3 keeps that useful case and removes the drift toward episteme agency, publication authority, generic emergence, and duplicate episteme ontology.

This pattern is deliberately thin. B.2 owns whole reidentification; C.2.1 owns the ClaimGraph/EntityOfConcern/ReferenceScheme constitution relation and episteme identity; publication and source-use patterns own their relations; A.6 episteme-morphism patterns own morphing and retargeting; A.15 and A.12 own synthesis work and acting systems.

#SoTA-Echoing

#Relations

• Specializes: B.2 for an exact candidate new whole independently recognized under the already admitted U.Episteme kind.
• Builds on: B.2 for the exact candidate new whole and whole reidentification, A.1 for candidate recognition, C.2.1 for the obtaining ClaimGraph/EntityOfConcern/ReferenceScheme constitution relation, and E.24.UK for prior public-kind admission.
• Coordinates with: C.2.P, C.2.P.DR, E.17, E.17.*, A.6.2, A.6.3, A.6.4, A.6.3.CSC, A.10, B.3, B.3.5, C.29, F.18, and F.19.
• Uses: B.2.P when source wording such as emergence-family or title-mnemonic wording hides the claim kind.
• Contrasts with: B.2.2 for system-result MHT and B.2.4 for capability and functioning whole-reidentification evidence.

#B.2.3:End

#Capability and Functioning Whole Reidentification

Type: Part B holonic construction pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#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

#Supervisor-Subholon Feedback Relation

Type: Part B holonic construction pattern Status: Stable Normativity: Normative unless a section is explicitly informative

#Use This When

Use this pattern when a holon is supervised, regulated, steered, corrected, constrained, or coordinated through a two-sided feedback relation between a supervisor role and one or more supervised holons.

The first useful move is to recover the relation:

Which holons are supervised?
Which acting system holds the supervisor role in this bounded context?
What observation, report, signal, publication, or source relation carries state?
What influence, constraint, objective, mode, or work change returns?
Which transformation, work, architecture, evidence, assurance, timing,
or causal claim is being made in addition to the relation?

What goes wrong if missed. A control diagram, policy note, dashboard, publication channel, or supervisor word starts carrying part-whole, agency, safety, assurance, timing, gate, or architecture claims that belong elsewhere.

What this buys. B.2.5 gives a small relation record: supervised holons, supervisor role, acting system, medium or publication relation, observation or report side, influence or constraint side, and direct owners for stronger claims.

Not this pattern when.

• If the question is a control-structure view, use [C.30.LCA](/generated/patterns/C.30.LCA).
• If the question is architecture or selected structure, use [C.30](/generated/patterns/C.30), [A.22](/generated/patterns/A.22), and [C.30.ASV](/generated/patterns/C.30.ASV).
• If the question is reusable dynamics, timing, rate, or temporal validity, use [A.3.3](/generated/patterns/A.3.3) and [C.27](/generated/patterns/C.27).
• If the question is causal use, use [C.28](/generated/patterns/C.28).
• If the question is evidence, assurance, gate, or constraint validity, use [A.10](/generated/patterns/A.10), [G.6](/generated/patterns/G.6), [B.3](/generated/patterns/B.3), [A.20](/generated/patterns/A.20), or [A.21](/generated/patterns/A.21).
• If the question is module allocation or interface commitment, use [A.6.M](/generated/patterns/A.6.M).
• If the question is whole reidentification, use [B.2](/generated/patterns/B.2).

#Problem Frame

Supervisor-subholon feedback is a relation among holons, roles, acting systems, observed or published state, and returned influence or constraint. It is not automatically parthood, not automatically a control-structure view, not automatically evidence, and not automatically a mathematical loop object.

B.2.5 governs the relation-level claim. It can sit inside a broader architecture description, control-structure view, MHT claim, work claim, or evidence claim, but those claims keep their direct owners.

#Problem

Without this pattern, three different structures collapse:

1. Part-whole structure. Which holons are parts of which wholes.
2. Supervisor-subholon feedback relation. Which acting system holds the supervisor role, what it observes, and what influence or constraint returns.
3. Description or representation structure. Which diagram, dashboard, report, model, publication, or control-view description represents the relation.

When these are confused, a functional layer is treated as a physical part, a publication is treated as an acting system, a diagram is treated as evidence, or a supervisor label is treated as a gate or assurance result.

#Forces

#Solution

Model the current object as SupervisorSubholonFeedbackRelation@Context.

SupervisorSubholonFeedbackRelation@Context:
  supervisedHolonRefs: FinSet(U.HolonRef)
  boundedContextRef:
  supervisorRoleRef:
  supervisingActingSystemRef:
  supervisedWorkOrTransformationRefs?
  observationOrReportRefs: FinSet(ObservationRef | ReportRef | PublicationUnitRef | SourceUseRef)
  influenceOrConstraintRefs: FinSet(InfluenceSignalRef | ConstraintRef | ObjectiveRef | ModeRef)
  sharedMediumOrPublicationRefs?
  holonBoundaryCrossingRelationRefs?
  feedbackClosureCondition:
  admissibleUse:
  nonAdmissibleUse:
  neighboringClaimOwnerRefs?

This relation is not a U-kind and not a mathematical loop lens. It is a relation record for the current bounded context.

#Two-Sided Feedback Relation

A one-way command, publication, or report relation is not yet a supervisor-subholon feedback relation. Name both:

• the observation, report, signal, source, or publication side; and
• the returned influence, constraint, objective, mode, or work-change side.

If only one side is current, record a one-sided relation and use the direct owner for that claim.

#Part-Whole Boundary

A supervised holon may be part of a larger holon, but supervision and parthood are different relations. An acting controller system, committee system, platform-governance system, review board, or tool-mediated group can hold the supervisor role without being a physical part of the supervised holon. A method, policy, or review practice can structure the supervision work; it does not supervise by itself.

Use A.1, B.1, A.14, and C.13 for parthood. Use B.2.5 only for the supervisor-subholon feedback relation.

#Acting-System Boundary

The supervisor role is held by an acting system in a bounded context. Do not create U.TransformerRef or treat a publication, theory, dashboard, model, method description, or report as the acting system.

For acting-side externalization, use A.12. For transformation, use A.3.4. For work, use A.15.1. For role assignment, use A.2.1.

#Control-Structure View Boundary

When the relation is drawn as planner, controller, observer, plant, and supervisor structure, B.2.5 names the relation, while C.30.LCA owns the control-structure view. A diagram or view does not establish the relation by appearance; recover the in-life relation and the description relation separately.

#Neighboring Claim Boundary

B.2.5 does not certify stability, safety, assurance, evidence sufficiency, causal validity, gate passage, rate adequacy, or mathematical adequacy.

Use:

• A.3.3 for reusable dynamics or state-evolution claims;
• C.27 for temporal and rate adequacy;
• C.28 for causal-use claims;
• A.10 and G.6 for evidence and provenance;
• B.3 for assurance;
• A.20 and A.21 for constraint validity and gate decisions;
• C.29 for mathematical-lens use.

#Archetypal Grounding (Worked Cases)

#Robotic Swarm

A fleet controller supervises drones. B.2.5 records each drone as a supervised holon, the controller system holding the supervisor role, telemetry as observation side, and waypoint or mode commands as influence side.

Claims about convergence, delay tolerance, disturbance damping, evidence, assurance, or safety use their direct owners. The feedback relation does not certify them.

#Scientific Theory Revision

A theory is revised when labs publish findings and a research community reviews anomalies and accepted revisions.

B.2.5 may record the theory or constituent epistemes as supervised objects only when the current claim is about a feedback relation around review and revision. The acting system is the research community, standards body, lab, review board, or tool-mediated group in role. The theory does not sense, judge, plan, decide, or act.

Publication channels, journals, datasets, reports, and review records remain publication or source-use objects.

#Product Platform Policy

A product platform constrains component teams through interface rules and release gates. B.2.5 records the acting platform or governance system holding the supervisor role, component holons, report channels, and constraint returns.

Work authority uses A.15; gate passage uses A.21; interface commitments use A.6.M; architecture view uses C.30.LCA when the control structure is described.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• Supervisor-subholon language stays useful without creating false acting objects or false part-whole claims.
• Control diagrams, publication channels, and feedback relations can be coordinated without being collapsed.
• Stability, safety, assurance, gate, timing, and evidence claims stay inspectable.

Costs:

• A feedback relation record is only the beginning of stronger analysis.
• Some control diagrams become less impressive because their unproven claims are separated.
• Episteme examples require explicit acting systems for review and revision.

#Rationale

Supervisor-subholon feedback is a recurring relation in control, organization, architecture, and epistemic revision. It becomes precise only when separated from part-whole composition, control-structure views, publication and source-use relations, and stronger assurance claims.

The selected name is SupervisorSubholonFeedbackRelation@Context because the governed object is a relation. A mathematical loop, if needed, is a lens or structure selected by another pattern; it is not selected by the name of this relation.

#SoTA-Echoing

#Relations

• Builds on: A.1, A.2.1, A.12, A.3.4, A.15.1, B.1, A.14, and C.13.
• Coordinates with: B.2 when feedback evidence creates a whole-reidentification question.
• Coordinates with: C.30.LCA for control-structure view, A.3.3 for dynamics, C.27 for temporal and rate adequacy, C.28 for causal use, A.10 and G.6 for evidence, B.3 for assurance, A.20 and A.21 for constraint validity and gate decisions, A.6.M for module-interface relation, and C.29 for mathematical-lens use.
• Uses: B.2.P when feedback, supervision, emergence, or MHT wording hides the claim kind.

#B.2.5:End

#Trust and Assurance Calculus (F-G-R with Congruence)

Type: Foundational (B) Status: Stable Normativity: Normative for FPF use that claims assurance, trust, readiness, compliance, safety, release confidence, F, G, R, or CL for a named claim.

Plain-English headline. B.3 defines how assurance or trust is assigned, aggregated, and reused for physical systems, epistemes, and publication or evidence records that are used to claim assurance. It uses one typed assurance tuple, F-G-R: F and R as characteristics, G as the scope value, plus edge-scoped CL; the aggregation rules stay conservative, respect the current composition, transformation, temporal, and work invariants named by their governing patterns, and keep the A.7 EntityOfConcern and description strict distinction. It treats the E.14 Working-Model layer as the publication-facing assertion layer for claims, with assurance inputs attached downward from Mapping, Logical, Constructive, and Empirical Validation layers.

Use this when. Use B.3 when a claim, label, dashboard, evidence bundle, model, report, gate decision, or assurance-input package is being used to raise assurance, trust, readiness, compliance, safety, release confidence, F, G, R, or CL for a named claim.

What goes wrong if missed. Labels, dashboards, model cards, credentials, provenance marks, gate decisions, or evidence bundles start raising trust or readiness without one typed assurance claim, named evidence, scope, limitations, decay, and relying context.

What this buys. Assurance becomes a conservative typed claim over F, G, R, and edge-scoped CL, with explicit evidence, scope, time, limitations, contestability, and stop or reopen conditions.

First output. Write one typed Assurance(H, C | K, S) claim per named assurance claim C, or write an explicit no-assurance-claim disposition when the encountered publication face, rendering, cue, evidence pointer, wording issue, gate decision, role assertion, status-value assertion, commitment, or work occurrence does not carry an assurance claim.

Not this pattern when. If the encountered source or publication face is only a cue, action invitation, boundary wording, evidence question, currentness question, gate decision, release decision, role assertion, status-value assertion, commitment, or work occurrence, use A.15, A.6, A.10, A.21, A.20, A.2.1, A.2.8, A.2.9, or A.15.1 as appropriate.

Assurance result selection. Use the lightest assurance result that can decide the assurance use being claimed. A cue or source pointer gets no B.3 tuple. A local, non-release, non-compliance, non-safety, non-reused claim may be written as a compact bounded assurance claim statement that names claim, assurance use carried by the assurance tuple or relying context, evidence pointer, limit, and stop or reopen condition. Reserve a full typed Assurance(H, C | K, S) claim for readiness, compliance, safety, release confidence, trust, F, G, R, CL, or reused assurance input.

Assurance claim over time. Treat an assurance claim as time-bounded and updateable: it can decay, reopen, narrow, or be withdrawn, not remain a one-time checklist result. For model, data, AI, documentation, release, or operational assurance, name the drift, monitoring, incident, evidence refresh, version change, policy change, gate change, or residual unsupported-use condition that reopens the assurance claim.

#Problem frame

Every non‑trivial result in FPF—a composed system is safe, a model is credible, a conclusion holds—is a claim that rests on composed evidence.

• For U.System holons, assurance is about capabilities and constraints under stated conditions.
• For U.Episteme holons, assurance is about the quality of evidence relation for a statement or model.

To make such claims comparable and auditable across domains, B.3 introduces a Trust and Assurance Calculus that:

• uses a small typed assurance tuple (F-G-R: F and R as characteristics plus G as scope value) governed by conservative propagation rules; this tuple is not a state space,
• accounts for integration quality via Congruence Level (CL) along the edges of a DependencyGraph (B.1.1, A.14),
• and composes these values only through current governing composition, transformation, temporal, and work operators while respecting their declared invariants.

B.3 is conceptual and normative: it defines which assurance components must be published and how they propagate. How those components improve (for example by formalizing, replicating, reconciling, or widening or narrowing scope under declared operation rules) is handled by KD-CAL improvement moves; those knowledge-dynamics references are descriptive, not required to read here.

Mechanism linkage. For law-governed operation families (for example USM and UNM) authored as mechanisms, use A.6.1 — U.Mechanism to publish OperationAlgebra, LawSet, AdmissibilityConditions, and the Transport clause (Bridge-only; CL, CL^k, and CL^plane). All such penalties reduce R_eff only; F and G remain invariant.

Working-Model handshake (alignment with E.14, B.3.5, and C.13). Assurance consumes two inputs declared in the Working-Model assertion layer (CT2R-LOG, B.3.5): the justification declaration validationMode ∈ {postulate, inferential, axiomatic} and, where present, the grounding link tv:groundedBy. Structural claims that aspire to the strongest guarantees rely on Constructive grounding as a constructive-composition narrative referenced via tv:groundedBy. No assurance record or publication defines Working-Model wording or layout; dependence remains downward-only under E.14.

#Problem

Without a disciplined calculus, four chronic failures appear:

1. Trust inflation: Averaging or summing heterogeneous “quality” tags yields aggregates that look better than their weakest parts, violating WLNK.
2. Scale confusion: Mixing ordinal and ratio scales (e.g., averaging F ordinal scale values with numeric reliabilities) produces meaningless numbers.
3. Congruence blindness: Integration quality (how well pieces fit) is invisible; brilliantly strong parts connected by weak mappings produce overconfident wholes.
4. Scope drift: Design-time formalism and run-time evidence are composed into a single score; dashboards then claim “assurance” for a blueprint using run-time data, or vice versa.

#Forces

#Solution — Part 1: The assurance tuple and the universal aggregation skeleton

B.3 defines what the assurance components are, where they are assigned on nodes and edges of the dependency graph, and the shape of the aggregation that any Γ-flavour must honor when producing an assurance result.

#The F-G-R assurance components (typed; F and R as CHR, G as USM)

We standardize two node characteristics, one node scope value, and one edge characteristic:

1. Formality (F) — how constrained the reasoning is by explicit, proof-grade structure.

   • Scale kind: ordinal (its scale values do not admit arithmetic).
   • Canonical scale values (example): F0 Informal prose - F1 Structured narrative - F2 Formalizable schema - F3 Proof-grade formalism.
   • Monotone direction: higher is better (never lowers assurance when all else fixed).

2. ClaimScope (G) — the declared set of U.ContextSlice values where the result applies.

   • Type: set-valued USM scope value (A.2.6), not a CHR characteristic.
   • Well-typed operations: membership and set algebra (∈, ⊆, ∩, ⋃, SpanUnion, plus declared Bridge translation, widening, narrowing, or refit operation).
   • Scalar proxy (report-only): if a G scope report needs a number, it may publish an explicitly declared CoverageMetric(G); such a proxy must not replace G in norms, gates, bridge semantics, or CL-bearing relation decisions.

3. Reliability (R) — how likely the claim or behavior holds under stated conditions.

   • Scale kind: ratio in [0,1] (or a conservative ordinal proxy when numeric modeling is unavailable).
   • Monotone direction: higher is better.

4. Congruence Level (CL) — edge property: how well two parts fit (semantic alignment, calibration, interface standard).

   • Scale kind: ordinal with a monotone penalty function Φ(CL) where Φ decreases as CL increases.
   • Canonical scale values (example): CL0 tentative guess - CL1 plausible mapping - CL2 validated mapping - CL3 verified equivalence.
   • Interpretation: low CL reduces the credibility of the integration itself (not the parts), and therefore penalizes the aggregate R.

EntityOfConcern and description strict distinction (A.7).

• Assurance components are recorded as value and scope claim components: F and R as characteristics, G as a scope value, while the governing composition, order, temporal, and work patterns keep structure, order, and time distinct.
• Do not smuggle assurance components into structural edges; keep F, R, and CL explicit as CHR metadata and G explicit as a USM scope value.

Assurance shoulders (Working-Model split). Mapping raises TA (typing, fit, and CL). Logical and Constructive contribute to VA (intended relation semantics; constructive-composition identity for structure when the governing pattern admits it). Empirical Validation contributes to LA (evidence in a bounded context). These assurance inputs attach downward from the Working-Model assertion layer (E.14).

#Assurance as a typed claim

B.3 speaks about assurance of a specific typed claim C over a holon H under context K and scope S ∈ {design, run}:

Assurance(H, C | K, S) = ⟨F_eff, G_eff, R_eff, Notes⟩

• C examples: meets load L, argument Q holds, model M predicts within δ.
• K binds assumptions (environment, usage, priors).
• Notes include carrier/source-currentness records, evidence-provenance references (A.10), OrderSpec or TimeWindow where applicable, cutsets, and evidence citations.

This tuple gives practitioners an at-a-glance assurance result while preserving the pieces needed for audit and improvement.

Validation modes (declaration, normative). Each published Working-Model assertion declares validationMode ∈ {postulate, inferential, axiomatic} (E.14).

• postulate -> pragmatic working claim; Empirical Validation is required for audit.
• inferential -> reasoned consequence; Logical assurance carries the reasoning requirement.
• axiomatic -> constructive identity; structural edges provide a constructive-composition narrative and a tv:groundedBy pointer (C.13, B.3.5).