#Part B — Trans-disciplinary Reasoning Cluster

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

#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

#Use This When

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 source 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 an order-sensitive method-composition claim: a claim that recovered U.Method values form one composite U.Method under a bounded context.

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, MethodRelationStructure@BoundedContext, method-family registry or selector outcome, mathematical lens, mechanism, formal substrate, or quote-only source wording.

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 admit a composite U.Method only when method parts, whole-forming relations, whole identity, interface exposure, assurance hooks, and enactment boundary are explicit. If that threshold is not met, the project still has a useful lower object: a selected method relation structure, description, plan, work record, lens, or source-restoration 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 representation that describes a method or method relation structure, use A.3.2.
• 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 alternative set without one whole-method assembly, use G.5 or MethodRelationStructure@BoundedContext.

#Problem Frame

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 recovered U.Method parts in one bounded context,
which whole-forming relations assemble them into one larger U.Method,
and what whole-level commitments make the resulting method reidentifiable and enactable?

The whole method is not the diagram, code, schedule, event log, or work history that may describe, plan, record, or evidence it. Work enacts the method; the method does not perform work.

Gamma_method is the name for this method-composition discipline. It is not a new root U-kind, not a workflow notation, 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 output is assumed to satisfy the next submethod's precondition without an adapter, bridge, conversion, or declared equivalence.
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 outcomes are baked into the method instead of being recorded on U.Work.
7. False whole method. A method-family registry, fallback table, selector rule, or local relation structure is treated as one whole method although no whole-method identity has been recovered.

#Forces

#Solution

Admit one composite U.Method only when all composition coordinates are recovered.

OrderSensitiveMethodComposition:
  WholeMethodRef: U.Method
  BoundedContextRef: U.BoundedContext
  PartMethodRefs: non-empty set of U.Method
  WholeFormingRelations:
    serial | parallel | guardedChoice | iteration | refinement | substitution | fallback | adapter | typedJoin
  WholeIdentity:
    preconditions
    effects or postconditions
    invariants
    accepted inputs and outputs
    failure and stop conditions
  MethodInterfaceExposure:
    exposed interactions
    forwarded interactions
    encapsulated interactions
  MHTOrWholeReidentification:
    whole-level commitment or B.2 relation when needed
  AssuranceHooks:
    typed joins, adapters, fragile branches, cutsets, evidence targets
  EnactmentBoundary:
    which U.Work may enact this method and which U.MethodDescription describes it
  LoweredDispositionIfNotComposite:
    MethodRelationStructure | U.MethodDescription | U.WorkPlan | U.Work | G.5 selector | lens | source-restoration 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 relation, fallback relation, or selector relation inside MethodRelationStructure@BoundedContext;
• a mathematical or representation lens over a relation structure;
• mechanism or formal-substrate material;
• quote-only source wording.

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

#Admit The Composite Method

When the apparent parts are recovered as U.Method values, compose them only after naming the whole-forming relations:

• serial composition when one submethod's accepted result is a precondition for the next;
• parallel composition when branches can proceed independently under a declared join condition;
• guarded choice when one branch is selected by a declared predicate;
• iteration when a submethod repeats until a stop condition is met;
• refinement or substitution when a submethod can stand in for another under declared bounds;
• fallback or dispatch when a selector chooses a method family member;
• adapter when a conversion method is needed to make a typed join admissible.

For order-sensitive composition, the method-composition claim also needs the order apparatus by reference: OrderSpecRef, any context hash or partial-order reproducibility condition inherited from B.1.4, and the typed join or adapter evidence that says one submethod's accepted outputs meet the next submethod's preconditions. This preserves the old capability-continuity obligation without treating "capability type" as the capability instance itself.

The result is one composite U.Method only when the whole has its own identity: preconditions, effects, invariants, accepted inputs and outputs, failure conditions, and work-facing acceptance relation. If those whole-level commitments cannot be named, lower the claim to MethodRelationStructure@BoundedContext or another neighboring object.

#Keep Order Out Of Structural Mereology

SerialStepOf, ParallelFactorOf, guarded choice, iteration, fallback, adapter, and typed join are method-composition or method-relation claims. They are not A.14 component parthood.

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 ways of doing compose into a larger way of doing. The same project may need both, but they are different relation families.

When the current method-composition claim needs explicit order aggregation, context hash, partial-order soundness, or Gamma_ctx notation, use B.1.4 for that ordered-relation apparatus. B.1.4 can express the order discipline; B.1.5 still decides whether the recovered ordered methods are enough to admit one composite U.Method.

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

#Expose The Composite Method Interface

A composite method needs an interface exposure decision:

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

The interface exposure decision is part of the composite method identity when outside work, assurance, planning, or substitution relies on it. It is not a publication layout decision.

#Method Interface Card (MIC)

When an interface exposure decision is reliance-bearing, publish it as a compact Method Interface Card (MIC). The MIC is a method-description or assurance-facing card about the composite method; it is not a new U-kind and not the method itself.

MethodInterfaceCard:
  methodRef: U.Method
  methodDescriptionRef?: U.MethodDescription
  orderSpecRef?: B.1.4 order apparatus
  externalInteractions:
    - interactionName
      exposureMode: exposed | forwarded | encapsulated
      acceptedInputOrCallSignature
      preconditions
      postconditionsOrEffects
      qualityEnvelopeRefs?
  invariants
  adapterOrTypedJoinRefs?
  assuranceHookRefs?
  rationale

Use a MIC when callers, planners, auditors, or substituting methods may rely on the composite boundary. For lightweight internal use, a few exposure lines may be enough; do not create a separate card by ritual.

#Keep Method Admission And Work Occurrence Separate

B.1.5 admits and grounds a composite U.Method. It may require a U.MethodDescription to describe the composition. It does not by itself create performed work.

A performed enactment is U.Work under A.15.1. The work record cites:

• the enacted U.Method;
• the method-description source when current;
• the performer through U.RoleAssignment;
• the time window, parameter bindings, affected referent, resource ledger, outcome, and evidence relations.

Resource aggregation, elapsed time, telemetry, retries, and work outcomes belong to U.Work, Gamma_work, and evidence patterns. They do not become parts of the method.

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 often enacts 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. A work part enacts a submethod only when that submethod has already been recovered as U.Method; otherwise the current object is a work part, method-description node, evidence segment, mechanism material, system-component behavior, or source-restoration request.

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

• the occurrence-side object: parent U.Work, part relation, interval or boundary event, performer, resources or evidence role;
• the method-side object: recovered U.Method submethod, whole-forming relation, preconditions, effects, interface, and whole-method identity.

If either 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.

#Planning And Performed-Work Obligations

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

• Planning or description-side use. Recover the submethods, order apparatus, typed joins or adapters, method interface exposure, invariants, and whole-level commitments. The output is a composite U.Method claim and, when a representation is needed, a U.MethodDescription or MIC that describes that method.
• Performed-work use. A U.Work occurrence may cite the composite U.Method and the method-description source it used. The work record checks role assignment, capability-fit or admission conditions when current, preconditions, postconditions, order conformance, MIC-honouring interactions, resource ledger handoff, and evidence relations. These checks annotate or support the performed work; they do not become parts 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 declared order apparatus; composite quality or throughput is constrained by critical path and weakest-link considerations unless a B.2-family whole reidentification claim is separately admitted; strengthening a submethod, adapter, or typed join should not make the composite method worse unless a stated side condition changes.

#Use MethodRelationStructure Below Whole-Method Threshold

Use MethodRelationStructure@BoundedContext when method-side relations are current but one whole method is not admitted. Typical cases:

• a fallback registry selects among alternatives;
• a workflow diagram relates method descriptions but does not recover method parts;
• a method family has refinement, substitution, or dispatch relations;
• a graph or algebra analyzes method relations as a lens;
• a cross-context source uses the same method names without a bridge for method identity;
• a work plan orders tasks but does not define one reusable method.

This lower object is not a failure. It is the right governed object when relation structure is useful but method holon composition is not current.

#Worked Slices

#Manufacturing Recipe

AssembleFrame, InstallMotor, and RunFunctionalTest are recovered as U.Method values in a bounded manufacturing context. InstallMotor must precede RunFunctionalTest; the test accepts the installed harness as input; an adapter method is needed when a supplier motor uses a different connector.

The composite BuildAndVerifyPumpUnit is admitted as a U.Method only after the whole states its preconditions, accepted inputs, final effect, exposed start and abort interactions, encapsulated internal calibration interactions, and failure conditions. The actual Tuesday build is U.Work; resource burn and test telemetry are not method parts.

#Emergency Intake

RegisterPatient, AssessVitals, ClassifyUrgency, and RouteToCare may compose into EmergencyIntake@Hospital. The guarded choice is driven by declared vital-sign and symptom predicates. A role assignment and capability check determine who may enact the work, but they are not parts of the method.

If the source only provides a wall poster with boxes and arrows, the current object is first U.MethodDescription. The composite U.Method is admitted only when the hospital context recovers the methods, guards, typed joins, failure response, and interface exposure.

#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 U.MethodDescription, and some may be recovered as U.Method values.

The pipeline is one composite U.Method only when it has accepted inputs, outputs, invariants or admissibility conditions, typed joins, fallback behavior, failure conditions, and work-facing acceptance criteria. Otherwise keep the graph as a method description, mathematical lens, mechanism material, or MethodRelationStructure@BoundedContext.

#Evidence Synthesis And Publication

CollectDatasets, NormalizeSchemas, EstimateModel, CrossValidate, and DraftManuscript can compose into EvidenceSynthesisPublish@ResearchContext only when each candidate is recovered as a U.Method and the typed joins are explicit. NormalizeSchemas must produce a feature or evidence space acceptable to EstimateModel; legacy datasets may need adapter methods; CrossValidate may be a critical cutset for later assurance; DraftManuscript may require a provenance or SCR condition before publication work is admitted.

A paper draft, workflow diagram, repository, or notebook is first a U.MethodDescription or another episteme. The publication work is U.Work. Compute, storage, reviewer time, and artifact-release resource costs belong to U.Work and Gamma_work. The MIC may expose Submit() and ReleaseArtifacts(), forward a parameterized CrossValidate.Folds(k) interaction, and encapsulate ad hoc scrubbing utilities.

#Conformance Checks

#Anti-Patterns And Repairs

#Consequences And Rationale

B.1.5 buys deterministic method composition without confusing method, method description, work occurrence, resource ledger, and assurance argument. The practitioner sees what is being composed by order and typed joins, what is spent by performed work, and what is later assessed by assurance.

The cost is explicitness: submethods, order apparatus, typed joins, adapters, interface exposure, and assurance hooks must be named before the composite method can be relied on. That cost prevents hidden brittleness at joins and accidental external dependencies at method boundaries.

The rationale is the old strict distinction in updated ontology. Order is semantic but not structural parthood. A method can be a non-agentive holon, but a step label, graph node, phase, source section, or work part is not a method part until the U.Method object is recovered. Gamma_method composes ways of doing; Gamma_work accounts resources; B.3 evaluates assurance; B.2 handles whole reidentification when the composed method participates as a new whole.

#SoTA-Echoing

#Relations

• Builds on A.1 for holon admission and non-agentive holon kinds.
• Builds on B.1.4 when the method-composition claim uses Gamma_ctx, ordered-relation aggregation, context hash, or partial-order soundness.
• Builds on A.3.1 for U.Method.
• Builds on A.3.2 for U.MethodDescription.
• Coordinates with A.15, A.15.1, and A.15.2 for role, method, work-plan, and performed-work separation.
• Coordinates with B.1.6 and Gamma_work for work-resource aggregation.
• Coordinates with B.3 for weakest-link, cutset, CL-sensitive mapping, and assurance evidence use.
• Coordinates with A.14, C.13, and B.3.5 when structural parthood and constructive grounding are current.
• Coordinates with B.2 when whole reidentification, MHT, or emergence-family explanation is current.
• Coordinates with G.5 when method-family registry, selector, fallback, or candidate-set relation is current.
• Coordinates with C.29, A.6.0, A.6.1, and E.20 when mathematical lens, formal substrate, or mechanism claim is current.
• Coordinates with E.10 for method, step, process, workflow, owner, requirement, and source wording precision recovery.

#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, objective, supervision, capability envelope, agency threshold, temporal consolidation, or bounded context 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 admitted episteme whole rather than a loose catalogue;
• a capability envelope appears only after structure, functioning, method, work, and evidence align;
• an architecture residual cannot be explained inside the existing whole.

First useful move. Try ExistingWholeExplanationCheck@Context 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 its direct owners. 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 existing whole, trigger profile, result holon kind, identity claim, evidence, direct owner of changed content, and blocked overreads before any MHT claim is relied on.

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 measurement or evaluation owners.
• If the claim is capability without whole reidentification, use capability and characteristic owners.
• 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, not a generic emergence label, and not a mathematical graph result. It is a whole-reidentification claim about a holon in a bounded context.

The old whole remains a possible explanatory object. B.2 is selected only when the old whole is no longer the right EntityOfConcern for the current claim. The result can be admitted as a U.System, U.Episteme, U.Work, U.BoundedContext, U.Discipline, or another holon kind only when the direct governing pattern admits that kind and slot discipline.

#Problem

Without B.2:

1. New whole is missed. A coordinated closure or context reframe 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 whole-reidentification pattern with three artifacts: a trigger profile, an existing-whole explanation check, and a holon reidentification record.

#MHTTriggerProfile

MHTTriggerProfile@Context is a trigger and evidence profile for possible whole reidentification. It is not a U-kind and not MHT itself.

MHTTriggerProfile@Context:
  existingWholeRef: U.Holon
  boundedContextRef:
  holonDelimitationChangeRef?
  objectiveOrEvaluationChangeRef?
  supervisionOrCoordinationChangeRef?
  capabilityOrClosureEvidenceRef?
  agencyThresholdRef?
  temporalConsolidationRef?
  contextReframeRef?
  evidenceRelationRefs:
  sourceUseRelationRefs?
  candidateResultHolonKindRef?

The profile asks whether enough has changed to make the old whole no longer the right EntityOfConcern. A single trigger is evidence for attention, not automatic admission.

#ExistingWholeExplanationCheck

Before declaring MHT, run:

ExistingWholeExplanationCheck@Context:
  observedGainOrShiftRef:
  existingWholeRef:
  explanationByBetterParts?
  explanationByCorrectedPartRelation?
  explanationByImprovedMeasurement?
  explanationByRaisedCongruenceOrSourceQuality?
  explanationByMethodOrWorkRepair?
  explanationByTemporalCoverageRepair?
  explanationByArchitectureViewRepair?
  explanationByCapabilityOrFunctioningRepair?
  remainingWholeReidentificationQuestion:

If an existing-whole explanation is sufficient, do not declare MHT. Use the direct owner for the repair.

#HolonReidentificationRecord

Declare MHT only with a record that names the old whole, result whole, result kind, triggers, identity claim, and owner boundaries.

HolonReidentificationRecord@Context:
  existingWholeRef: U.Holon
  boundedContextRef:
  selectedTriggerProfileRef: MHTTriggerProfile@Context
  existingWholeExplanationCheckRef: ExistingWholeExplanationCheck@Context
  mhtResultHolonRef:
  mhtResultSystemRef?
  mhtResultEpistemeRef?
  mhtResultWorkOccurrenceRef?
  mhtResultBoundedContextRef?
  mhtResultDisciplineRef?
  resultHolonKindAdmissionRef:
  identityContinuationOrReidentificationClaim:
  changedContentOwnerRefs:
  evidenceRelationRefs:
  sourceUseRelationRefs?
  mathLensUseRefs?
  blockedOverreads:

This record is not a U-kind and not an actor. It carries the reidentification claim and the direct owners of neighboring claims.

#Result References

Use result references as fields, not as kinds:

• mhtResultHolonRef for the reidentified whole;
• mhtResultSystemRef only when the result is admitted as U.System;
• mhtResultEpistemeRef only when the result is admitted as U.Episteme;
• mhtResultWorkOccurrenceRef only when the result is admitted as U.Work;
• mhtResultBoundedContextRef only when a bounded context is itself the result whole under its direct owner;
• mhtResultDisciplineRef only when the result is a discipline holon under C.20.

Do not use post* field names as live governed names. They hide the result kind and invite temporal shorthand.

#Agency Threshold

Agency is not a binary status and not a root kind. Treat agency as a characteristic-space threshold for a system in bounded context.

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@Context, 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.

#Archetypal Grounding (Worked Cases)

#Bias-Annotation

#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 MHT-result holon is admitted as U.Episteme. C.2.1 and the episteme family own episteme slot relation, publication, source-use, and claim-bearing structure.

#Capability Envelope Appears

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

Use B.2.4 only when that capability or functioning evidence creates or reveals a whole-reidentification question under B.2.

#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 closure, objective, coordination, and evidence that cannot be explained by the existing parts alone.

#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.
• System, episteme, work, bounded-context, and discipline result cases share one B.2 spine while keeping their direct owners.
• 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 explicit result-kind admission and evidence.
• 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 preserves ordinary direct-owner repairs first, then admits 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 holon admission, B.1 for part-whole construction, A.14 and C.13 for relation and constructional grounding, and E.24.UK for result-kind admission discipline.
• 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.29 for mathematical lenses, C.32.P2S when architecturing pressure becomes whole reidentification or emergence rather than local structure repair, and A.10 for evidence.
• Specialized by: B.2.2 for system-result MHT, B.2.3 for MHT-result holons admitted as U.Episteme, and B.2.4 for capability and functioning 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 result-kind specialization.
• 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 this a system-result, episteme-result, or capability and functioning specialization of B.2?
• 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.

The pattern therefore does not ask "what word should replace emergence?" It asks which EntityOfConcern, claim kind, slot relation, and direct governing pattern are current.

#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 result is an episteme whole, capability and functioning evidence, 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

Use this recovery note:

EmergenceClaimKindRecovery@Context:
  sourceExpression:
  projectConcern:
  candidateEntityOfConcernRef:
  sourceUseDisposition:
  recoveredClaimKind:
  recoveredDirectOwnerPattern:
  candidateWholeReidentificationRef?
  candidateResultHolonKindRef?
  characteristicOrCapabilityRef?
  functionOrFunctioningRef?
  architectureOrStructureRef?
  mathematicalLensUseRef?
  evidenceOrMeasurementRef?
  collectionAdmissionRef?
  publicationOrSourceUseRef?
  blockedOverreads:
  replacementWordingOrStop:

The recovery note is not a U-kind and not a durable project object by itself. It is a local precision-restoration record.

#Claim-Kind Recovery and Owner Selection Table

#Whole-Reidentification Recovery

When whole reidentification remains possible after the claim-kind recovery, recover the B.2 slot relation:

B2WholeReidentificationRecovery@Context:
  existingWholeRef:
  boundedContextRef:
  candidateResultHolonKindRef:
  candidateResultRef:
  mhtTriggerProfileRef:
  existingWholeExplanationCheckRef:
  changedContentOwnerRefs:
  evidenceOrSourceRelationRefs:
  mathematicalLensUseRefs?
  blockedOverreads:

Then return to B.2. B.2.P does not declare MHT.

#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 record that these are the direct owners; it does not own them.

#Source Mnemonics and Result Fields

Treat source labels and short forms as recognition cues until their governed object is recovered.

• MET may point to an episteme-result MHT, source-title wording, episteme morphing, publication synthesis, or source-only phrase. Recover 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 should become mhtResult*Ref only when B.2 record fields are current.

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 MHT-result system?
• Does the agency wording name a system in role, an agency-threshold claim, or only ordinary prose?
• Is there result-system delimitation, objective, coordination, capability envelope, evidence, and assurance?

If the result is an acting system whole, use B.2 and B.2.2. If it 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?
• Does the evidence create or reveal a whole-reidentification question?
• Is the current object a function-like wording issue, a functional-structure view, a method and work relation, or a result 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.

#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 their current governed object is recovered.

#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, C.30.ASV, C.30.TFS-REL, C.30.ILC, C.32.P2S, C.29, A.10, C.2.1, 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 a Meta-Holon Transition result is an acting physical or operational holon admitted as U.System: a swarm, production cell, cloud platform, regulated control system, organizational unit, or another operating whole that now has system participation slots of its own.

The first useful question is not "is there emergence?" but:

Is the MHT-result whole a U.System whose delimitation, objective,
supervision or coordination, capability envelope, role assignments,
methods, work occurrences, transformations, functioning, evidence,
assurance, and temporal claims must be re-declared for the result whole?

Use [B.2](/generated/patterns/B.2) first to decide whether whole reidentification is needed. Use [B.2.2](/generated/patterns/B.2.2) only after the result-kind question points to mhtResultSystemRef.

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](/generated/patterns/B.2.3) and the episteme family.
• If the evidence is only a capability or functioning gain without whole reidentification, use [A.2.2](/generated/patterns/A.2.2), [C.16](/generated/patterns/C.16), [A.6.F](/generated/patterns/A.6.F), [A.3.4](/generated/patterns/A.3.4), C.30.TFS-REL, and [A.10](/generated/patterns/A.10).
• If the claim is ordinary system aggregation or delimitation, use [B.1.2](/generated/patterns/B.1.2), [A.1](/generated/patterns/A.1), [A.14](/generated/patterns/A.14), and [C.13](/generated/patterns/C.13).
• If the claim is a mathematical, simulation, graph, benchmark, or scaling expression, use [C.29](/generated/patterns/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](/generated/patterns/B.2.5).

#Problem Frame

B.2 is holon-general. B.2.2 is its system-result specialization.

A system-result MHT occurs when the result of whole reidentification is an acting physical or operational holon. The old constituent systems may remain parts, participants, resources, or interacting neighbors, but the current claim now needs a result system with its own selected delimitation, objective, supervision or coordination, capability envelope, functioning relation, architecture claims, transformation participation, work occurrences, evidence, assurance, and temporal claims.

The pattern does not say that every collection of systems is a system MHT. It says how to carry the system ontic when B.2 has already left a whole-reidentification question and the result-kind admission is U.System.

#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 result-system delimitation, objective, coordination, or capability evidence is named.
3. Supervision is overread. A coordination mechanism is treated as a super-holon, safety evidence, or a complete system admission.
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 an MHT question open, admit the system-result case with a system-focused slice of the HolonReidentificationRecord@Context.

#System-Result MHT Slice

Use this slice when mhtResultSystemRef is selected.

SystemMHTSlice@Context:
  existingWholeRef: U.Holon
  mhtResultSystemRef: U.System
  boundedContextRef:
  selectedTriggerProfileRef: MHTTriggerProfile@Context
  existingWholeExplanationCheckRef: ExistingWholeExplanationCheck@Context
  systemKindAdmissionRef: A.1 or B.1.2 admission
  resultDelimitationRelationRef:
  resultBoundaryCrossingRelationRefs:
  objectiveOrEvaluationRelationRef?
  supervisionOrCoordinationRelationRef?
  capabilityEnvelopeRef?
  roleAssignmentRefs?
  methodOrMechanismRefs?
  transformationParticipationRefs?
  workOccurrenceRefs?
  functioningRelationRefs?
  architectureClaimRefs?
  evidenceOrAssuranceRefs?
  temporalOrDynamicsRefs?
  blockedOverreads:

This slice is not a U-kind. It is the system-result part of the B.2 record, written so that every system-dependent claim can return to its direct owner.

#System Participation Re-Basing

When the result is U.System, re-base system participation slots for the result system:

• 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 result system. Carry continuities by explicit relation; re-declare changed slots for the result system.

#System Trigger Interpretation

The B.2 trigger profile can be interpreted for systems as follows:

No single row is enough by itself. The row names evidence to inspect. B.2 decides whether the whole must be reidentified.

#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 mhtResultSystemRef is admitted, old assurance must be tested against the result system.

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?

The result system can inherit evidence only through named relations. It 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 mhtResultSystemRef is the operating platform itself.

#Production Cell

A machine, robot, fixture, workpiece carrier, and inspection station can become a production cell when the cell has its own delimitation, objective, coordination, transformation structure, work occurrence evidence, and capability envelope.

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: system slots are re-based rather than replaced by generic whole language.
• 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 result system is not a trigger profile, coordination mechanism, graph, description, dashboard, or process label. It is an admitted U.System whose system participation slots must be available and, where changed, re-declared.

#SoTA-Echoing

#Relations

• Specializes: B.2 for MHT-result holons admitted as U.System.
• 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 a Meta-Holon Transition result is admitted as U.Episteme: 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. Use B.2.3 only when the result-kind question points to mhtResultEpistemeRef.

First useful move. Recover the episteme result as a U.Episteme holon with its C.2.1 slot relation: EntityOfConcern, grounding holon, claim graph, reference scheme, viewpoint, view, and publication or source-use relations when current.

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 slot relation, publication, source use, view, viewpoint, claim graph, reference scheme, or description use without MHT, use C.2.1, C.2.P, C.2.P.DR, E.17, and the episteme family directly.
• 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. It becomes an MHT-result episteme only when the current claim needs one reidentified claim-bearing holon whose C.2.1 slot relation can be filled and governed as one episteme.

B.2.3 does not introduce a special episteme ontology. It uses mhtResultEpistemeRef in the B.2 record and then returns episteme structure to C.2.1.

#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 episteme-result specialization of B.2.

#Episteme-Result MHT Slice

When mhtResultEpistemeRef is selected, use:

EpistemeResultMHTSlice@Context:
  existingWholeRef: U.Holon
  mhtResultEpistemeRef: U.Episteme
  boundedContextRef:
  selectedTriggerProfileRef: MHTTriggerProfile@Context
  existingWholeExplanationCheckRef: ExistingWholeExplanationCheck@Context
  epistemeKindAdmissionRef: C.2.1
  epistemeSlotRelationRef: U.EpistemeSlotRelation
  entityOfConcernSlotRef:
  groundingHolonSlotRef:
  claimGraphSlotRef:
  referenceSchemeSlotRef:
  viewpointSlotRef?
  viewSlotRef?
  publicationOrSourceUseRefs?
  constituentEpistemeRefs:
  synthesisWorkRefs?
  evidenceOrAssuranceRefs:
  mathematicalLensUseRefs?
  blockedOverreads:

This slice is not a U-kind and not a second episteme ontology. It is the B.2 record slice that says the MHT result is an episteme and names the C.2.1 relation that governs it.

#Episteme Slot Re-Basing

For the result episteme, re-base at least these C.2.1 slots when current:

• EntityOfConcernSlot: what the result episteme is about;
• GroundingHolonSlot: where the result claim is grounded or tested;
• ClaimGraphSlot: what the result episteme says as a claim structure;
• ReferenceSchemeSlot: how claims are read as about their entities;
• ViewpointSlot and ViewSlot: when the result episteme has viewpoint-governed views;
• publication, source-use, and representation relations when the result episteme is published, cited, carried, or represented.

Do not infer these slots from the existence of a publication set. Fill them as episteme slots.

#Episteme Trigger Interpretation

Interpret MHTTriggerProfile@Context for epistemes without giving agency to epistemes:

B.2.3 uses these rows as evidence to inspect. B.2 decides whether whole reidentification is admitted.

#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 the result has a unified claim graph, reference scheme, grounding holons, and admissible explanatory or predictive use that the collection did not carry as one whole.

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 fill episteme slots, 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 episteme slot relation; E.17 and source-use patterns own publications; 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 MHT-result holons admitted as U.Episteme.
• Builds on: C.2.1 for U.EpistemeSlotRelation, A.1 for holon admission, and E.24.UK for result-kind admission discipline.
• 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 capability-envelope evidence, functioning-relation evidence, or transformation-flow-structure evidence creates or reveals a B.2 whole-reidentification question.

The first useful question is:

Does this capability or functioning evidence show that the existing whole
is no longer the right EntityOfConcern, or is this only a direct capability,
functioning, transformation, method, work, module, characteristic, or
architecture claim?

Use [B.2.4](/generated/patterns/B.2.4) only for the first case. Use direct owners for the second.

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 evidence available for B.2 while 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](/generated/patterns/A.2.2) and [C.16](/generated/patterns/C.16).
• If the claim is function-like wording or functioning relation without whole reidentification, use [A.6.F](/generated/patterns/A.6.F).
• If the claim is transformation or transformation-flow structure, use [A.3.4](/generated/patterns/A.3.4), [E.18](/generated/patterns/E.18), and C.30.TFS-REL.
• If the claim is method, method relation, method description, work plan, or work occurrence, use [A.15](/generated/patterns/A.15), [A.3.1](/generated/patterns/A.3.1), [A.3.2](/generated/patterns/A.3.2), [A.15.2](/generated/patterns/A.15.2), and [A.15.1](/generated/patterns/A.15.1).
• If the claim is module allocation or bearer allocation, use [A.6.M](/generated/patterns/A.6.M) and architecture owners.
• If the claim is measurement, threshold, score, robustness, quality, or whole-level characteristic, use [C.16](/generated/patterns/C.16), [A.19](/generated/patterns/A.19), and evidence owners.
• If the wording is ambiguous emergence, synergy, or title-mnemonic language, use [B.2.P](/generated/patterns/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 capability, functioning, or transformation-flow evidence makes the existing whole explanation fail and points to a reidentified holon. It is not a pattern for all capabilities or all functions.

#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 capability and functioning evidence to B.2 whole reidentification.

#Capability-Functioning Whole-Reidentification Slice

Use this slice only when B.2 remains current after direct-owner explanations are checked.

CapabilityFunctioningWholeReidentificationSlice@Context:
  existingWholeRef: U.Holon
  boundedContextRef:
  capabilityEnvelopeRef?
  functioningRelationRef?
  transformationFlowStructureRef?
  functionalStructureViewRef?
  candidateBearerRefs?
  methodRelationRefs?
  methodDescriptionRefs?
  workPlanRefs?
  workOccurrenceRefs?
  moduleAllocationRefs?
  characteristicOrThresholdRefs?
  evidenceOrMeasurementRefs:
  existingWholeExplanationCheckRef: ExistingWholeExplanationCheck@Context
  candidateB2RecordRef:
  blockedDirectOwnerOverreads:

This slice is not a U-kind and not a capability object. It carries the evidence needed to decide whether B.2 whole reidentification is current.

#Direct-Owner Test

Before using B.2.4 for whole reidentification, test whether a direct owner explains the evidence:

#Existing-Whole Explanation

Use ExistingWholeExplanationCheck@Context before claiming whole reidentification.

Direct-owner explanations that often stop B.2.4:

• 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 performed capability evidence;
• better work coordination inside the same whole;
• module allocation repair;
• architecture-view or transformation-flow-structure repair;
• evidence or source-currentness improvement.

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 evidence shows that the current object must be reidentified as a result holon. Examples:

• a production cell now has a capability envelope, coordination relation, transformation-flow structure, and assurance claim that cannot be explained by individual machines;
• a service platform now has a functioning relation and external commitments that cannot be assigned to one service or module;
• a team, toolchain, and method family now operate as one result system with new capability and work evidence;
• an episteme or standard now has a capability for explanation, prediction, or specification use that requires result-episteme reidentification.

After the return, B.2 owns the MHT record and result-kind admission. B.2.4 carries only the capability and functioning evidence slice.

#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 the capability evidence points to a result holon: a platform, team-system, or work occurrence whole with new delimitation, coordination, external commitments, evidence, and assurance. An automated delivery sequence label 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 carry the explanatory-capability evidence, but B.2.3 owns the episteme-result MHT if the result is U.Episteme; C.2.1 owns the episteme slot relation; C.29 owns mathematical-lens use when the lens is relied on for the current claim.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• Capability and functioning evidence can bear on real whole reidentification without becoming a generic emergence owner.
• 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 new wholes first become visible. But the evidence is mixed: it may belong to capability measurement, function-like wording, architecture structure, transformation flow, method relation, work occurrence, module allocation, or whole reidentification.

B.2.4 exists to keep that mixed evidence disciplined. It does not rename all of it as "meta-function". It asks whether the evidence defeats the existing whole explanation and, only then, returns to B.2.

#SoTA-Echoing

#Relations

• Specializes: B.2 for cases where capability, functioning, or transformation-flow evidence creates or reveals whole reidentification.
• 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).

Design versus run (no chimeras). Assurance tuples for design-time and run-time are reported separately and are not composed into a single score; see the Scope drift hazard in B.3:2 and the obligations in B.3:4.6.

#Authority-looking labels and dashboard tiles

A badge, label, score, dashboard tile, credential display, provenance mark, compliance-looking mark, model card, datasheet, data card, assurance document, attestation label, assurance-looking note, or generated confidence phrase does not enter assurance calculus or improve F, G, R, CL, readiness, safety, compliance, trust, release confidence, or assurance by display alone.

Adversarial misuse guard. Do not let dashboards with favorable labels, compliance-looking badges, old model cards, provenance labels, assurance-looking documents, or generated confidence phrases supply missing evidence, limitations, scope, decay, or argument for an assurance claim.

B.3 dispositions for such a source or publication face are:

Build a B.3 assurance claim only when the next work occurrence or reliance use depends on a typed assurance claim. The typed assurance claim names:

Assurance evidence minimization. A typed assurance result cites the minimum A.10 evidence-provenance path needed for the named assurance claim and relying context. Use redacted, hashed, scoped, or role-mediated evidence refs when raw evidence records would expose personal data, secrets, privileged logs, tenant identifiers, security-sensitive traces, incident details, or unnecessary identities; do not build a full assurance dossier when pointers preserve enough recoverability.

Viewpoint prompts for assurance use:

Display guidance for assurance labels: a readiness, safety, compliance, trust, release-confidence, or assurance display should show the named assurance claim, assurance use carried by the assurance tuple or relying context, evaluation condition, evidence-provenance ref, scope, window, limitation, decay condition, reopen condition, and assurance, work, or reliance claims not carried by the assurance tuple. A label that only points to documentation should remain a source pointer, not an assurance result.

Incident-learning fields for assurance overread: visible label, documentation record, attempted assurance claim, missing tuple or evidence-provenance field, assurance claim, work claim, or reliance claim not carried by the assurance tuple, limitation or decay condition that defeated the claim, next legitimate formalization, evidence repair, scope narrowing, or claim narrowing move, and upstream repair record for documentation, evidence refs, assurance label wording, monitoring, or reopen trigger.

Contestability and redress relation: when the B.3 material-reliance threshold is met, the B.3 result should name the claim being contested, evidence-provenance path, limitation or decay condition, contest forum or decision forum, safe interim disposition, and what evidence or scope change would reopen the assurance claim.

If those fields are missing, the encountered publication face, rendering, or cue remains an orientation label, source pointer, evidence pointer, documentation record, or unsubstantiated confidence cue. Use A.15 when the question is whether that lane may guide work or reliance, A.10 when the question is evidence, currentness, or provenance, and A.6 when the question is mixed policy, API, or schema wording.

Positive repaired assurance statement. When the assurance use being claimed and the required assurance fields are present, write the smallest typed assurance result that can guide work or reliance: the named claim, context, scope, evaluation condition, evidence-provenance path, argument, limitations, decay condition, and reopen condition. That result may improve or justify assurance only for the stated claim and scope; other gate, evidence, work-occurrence, or compliance uses still need their own named sources. Constructive assurance moves:

• narrow G to the evidenced or rule-bounded scope;
• raise F by formalizing argument structure, method-description fields, or MethodRelationStructure@BoundedContext when method composition, fallback, selection, or method-family relation is current;
• raise R by adding validation, replication, more probative, repeated, current, or more relevant evidence;
• improve CL by repairing mappings, units, interfaces, or integration edges;
• separate design assurance from run assurance;
• add limitations, assumptions, defeaters, monitoring, drift, and reopen triggers;
• reject or downgrade the assurance use when those moves are not available.

Negative controls:

Model cards, datasheets, data cards, assurance documents, and assurance-looking notes are external documentation records or source records unless they are mapped into existing FPF claims and publication faces. They do not add MVPK face kinds and do not bypass B.3 when the use under repair is an assurance claim.

Lint trigger. A model card, datasheet, or data card cited as readiness, safety, compliance, release confidence, or assurance proof requires documented intended-use match, evaluation condition, limitations, an A.10 evidence-provenance path, and one typed Assurance(H, C \| K, S) claim for the named assurance claim. Without those, classify the use as no assurance use or as a rejected or downgraded assurance claim.

Positive repaired example: a model card plus documented bounded-use statement or external intended-use field, evaluation condition, version, window, limitations, an A.10 evidence-provenance path, and a typed Assurance(H, C \| K, S) claim may carry assurance for that named model claim in that evaluated context. The same documentation still does not carry another deployment context, gate passage, release work occurrence, or compliance proof unless those sources are separately present.

#Minimum reliance safety assurance record

Use this B.3 section when the B.3 material-reliance threshold is met: reliance on a visible source may materially change behavior, safety, release, compliance, public or protocol behavior, access, resource allocation, people or team status value, operational action, or controlled-entity regulation. The first B.3 move is to decide whether an assurance claim is being made; if it is, write the minimum reliance safety assurance record for the named reliance use. Mere attention shift, learning, orientation, source-finding, or source-wording correction is not enough.

RelianceSafetyCase is the local Tech label for this B.3 assurance-record form. The plain phrase is minimum reliance safety assurance record. The label is not a new FPF pattern, Core kind, safety authority, gate, policy source, approval, certificate, compliance method, or general safety-case ontology.

Assurance-record use: the trigger and non-trigger table is a B.3 recognition aid, the minimum assurance-record table is a minimum local record aid, and the worked reliance-threshold slices are examples for users of the pattern. They are not a universal project checklist, sign-off sequence, untyped status vocabulary, or replacement for Assurance(H, C | K, S); use them only when the named material reliance trigger is met. This local section keeps the attempted reliance inside the B.3 assurance relation; it does not create an extra SEMIO authority or cross-pattern relation vocabulary.

Affordability card: orientation or source-finding stays outside B.3; bounded local reliance stays with the local evidence, explanation, CV, gate, or pattern-quality relation unless an assurance claim is being made; threshold reliance uses the minimum reliance safety assurance record only when the B.3 material-reliance threshold is met. Plain wording remains ordinary unless it changes bounded use, source relation, evidence, gate, assurance, work, decision, or selected governing pattern.

Common wrong first classification: a safety-looking note, safety case, compliance-looking label, or dashboard warning is a certificate, approval, or gate. First honest entry: state one typed B.3 assurance claim with A.10 evidence-provenance path, assumptions, limitations, defeaters, residual uncertainty, monitoring or stop condition, contest and redress relation, bounded assurance use, and unsupported attempted use.

First B.3 move: name the reliance use, the assurance claim, the affected context or audience, the trigger that meets the B.3 material-reliance threshold, the A.10 evidence-provenance path, the argument, limitations, defeaters, contest and redress relation, stop or monitoring condition, bounded assurance use, and unsupported attempted use. If those pieces are absent, use A.10, E.17.EFP, A.20, A.21, E.19, or the local relation that actually governs the source use rather than inventing assurance by label.

Trigger and non-trigger cases: