Supervisor–Subholon Feedback Loop

B.2.5 · Stable · Architectural pattern · Normative for FPF use that claims a supervisor-subholon feedback-loop relation. · Part B - Trans-disciplinary Reasoning Cluster

About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Architectural pattern Status: Stable Normativity: Normative for FPF use that claims a supervisor-subholon feedback-loop relation.

Use this pattern when a holon is described as being supervised, regulated, steered, corrected, constrained, or coordinated through a feedback loop between a supervisor role and one or more subordinate holons.

Keywords

control architecture
feedback loop
supervisor
stability
layered control.

Relations

B.2.5builds onMeta-Holon Transition (MHT): Recognizing Emergence and Re-identifying Wholes

B.2.5builds onU.Holon, U.System, and U.Episteme

B.2.5outline parentMeta-Holon Transition (MHT): Recognizing Emergence and Re-identifying Wholes

B.2.5outline prev siblingMFT (Meta-Functional Transition)

B.2.5outline next siblingBOSC Triggers

B.2.5explicit referenceControl Structure View Adequacy (LCA)

B.2.5explicit referenceU.Dynamics: State-Space and Transition-Law Episteme

B.2.5explicit referenceTemporal Claim Adequacy: State Readings, Temporal Trends, and Intervention-Sensitive Temporal Change

B.2.5explicit referenceCausalUse-CAL: Causal-Use Questions, Causality-Ladder Rungs, Identification and Realizability

B.2.5explicit referenceEvidence Graph Referring (C-4)

B.2.5explicit referenceEvidence Graph & Provenance Ledger

B.2.5explicit referenceTrust & Assurance Calculus (F–G–R with Congruence)

B.2.5explicit referenceU.Flow.ConstraintValidity — Eulerian

B.2.5explicit referenceGateProfilization: OperationalGate(profile) (GateFit core)

B.2.5explicit referenceModule Relation Repair

B.2.5explicit referenceMathematical Lens Use

B.2.5explicit referenceRole-Method-Work Alignment (Contextual Enactment)

B.2.5explicit referenceGrounded Architecture and Selected-Structure Adequacy

B.2.5explicit referenceMeta-Holon Transition (MHT): Recognizing Emergence and Re-identifying Wholes

B.2.5explicit referenceU.Holon, U.System, and U.Episteme

B.2.5explicit referenceRole Taxonomy

B.2.5explicit referenceU.RoleAssignment: Contextual Role Assignment

B.2.5explicit referenceTransformer Constitution (Quartet)

B.2.5explicit referenceU.Transformation: Bounded Change Under Conditions

B.2.5explicit referenceStrict Distinction (Clarity Lattice)

Content

Problem frame

The first-minute working situation is familiar: a fleet controller supervises drones, a plant supervisor changes allowed operating modes, a policy role constrains teams, or a scientific community reviews and revises a theory. The useful first move is to recover the feedback-loop relation: who or what is the supervised holon, which acting system or acting holon holds the supervisor role in the bounded context, which transformation relation or supervised work is being governed, what signal or publication channel carries state or observations, what influence or constraint returns, and what objective or constraint the loop is trying to maintain.

What goes wrong if B.2.5 is missed: the supervised holon, supervisor transformer, shared medium, returned influence, and loop-closure condition remain unnamed; then layer labels, diagrams, publication channels, or supervisor words start carrying claims that belong elsewhere.

What B.2.5 buys in practice: the practitioner can keep useful supervisor/subholon language while naming the acting role, medium, returned influence, and governing pattern for any stronger claim being made. Not this pattern when the issue under repair is only a control-structure view, reusable dynamics law, rate/timing claim, causal intervention claim, evidence or assurance claim, gate decision, or module-interface relation. Use C.30.LCA, A.3.3, C.27, C.28, A.10/G.6, B.3, A.20/A.21, or A.6.M as appropriate.

The primary EntityOfConcern is one supervisor-subholon feedback-loop relation. Stability, safety, evidence sufficiency, gate readiness, causal validity, or assurance claims remain neighboring claims under their governing patterns when those claims are being made.

Problem

Layered supervision is useful across engineered, biological, organizational, and epistemic cases, but it is easy to model incorrectly. The common error is to collapse three different structures into one drawing:

Structural composition: part-whole or structural composition of a holon.
Supervisory relation: an acting system or acting holon holding the supervisor role through current U.RoleAssignment in a bounded context, the supervised holon set, and the transformation, work, or constraint relation being governed.
Interaction or publication network: observation, signal, command, constraint, report, review, or publication channels through which the loop is enacted, observed, constrained, or revised.

When these are confused, a functional or supervisory layer is treated as a physical part, a publication is treated as an acting agent, a diagram is treated as proof, or a controller label is treated as a gate or assurance result.

Forces

Supervisory-loop language is useful and recognizable in control theory, cyber-physical systems, organizations, and science.
Layered-control language often uses layer, level, stack, and hierarchy; those words need declared kind recovery.
U.Episteme cases are especially fragile: an episteme can be reviewed, revised, cited, published, or used by acting systems, but the episteme itself does not sense, judge, plan, decide, or act.
A supervisor-subholon loop can be a relation in an architecture description, but stability, safety, assurance, evidence, gate, causal, and timing claim kinds belong to governing patterns.
The pattern needs to remain small enough to identify the loop before opening heavier control or assurance apparatus.

Solution

Model a supervisor-subholon feedback loop as a relation among holons, roles, transformers, media, and returned influence. A conforming loop identifies:

SupervisorSubholonFeedbackLoop@Context ::= {
  supervisedHolonRefs      : FinSet(U.HolonRef),
  supervisorRoleRef        : U.RoleRef,
  supervisorTransformerRef : U.TransformerRef | TransformerBearingSystemRef,
  sharedMediumRefs         : FinSet(U.InteractionRef | PublicationChannelRef),
  observationOrReportRefs  : FinSet(ObservationRef | ReportRef | PublicationUnitRef),
  influenceOrConstraintRefs: FinSet(InfluenceSignalRef | ConstraintRef | ObjectiveRef),
  feedbackRelationRefs     : FinSet(QualifiedRelationRecordRef),
  objectiveOrConstraintRef?,
  loopClosureCondition,
  admissibleUse,
  nonAdmissibleUse,
  governingClaimPatternRefs?
}

Loop relation readout. The loop has an observation/report side and an influence/constraint side. A one-way command relation is not yet a closed supervisor-subholon feedback loop unless the return observation, report, or state relation is also declared.

Structural-composition boundary. A supervised holon may be part of a larger holon, but supervision is not the same relation as part-whole composition. A controller, committee, method, or review practice can supervise a subholon without being a physical component of that subholon.

Control-structure view boundary. When the loop appears in an architecture description as planner/controller/observer/plant/supervisor structure, use [C.30.LCA](/generated/patterns/C.30.LCA) to record the control-structure view. [B.2.5](/generated/patterns/B.2.5) supplies the supervisor-subholon relation; [C.30.LCA](/generated/patterns/C.30.LCA) records the broader control-structure view.

Proof boundary. A conforming [B.2.5](/generated/patterns/B.2.5) loop is a relation, not proof. Stability and reusable state-evolution claims use [A.3.3](/generated/patterns/A.3.3); rate and timing claims use [C.27](/generated/patterns/C.27); causal-use claims use [C.28](/generated/patterns/C.28); evidence claims use [A.10](/generated/patterns/A.10) or [G.6](/generated/patterns/G.6); assurance claims use [B.3](/generated/patterns/B.3); gate and constraint-validity claims use [A.20](/generated/patterns/A.20)/[A.21](/generated/patterns/A.21); mathematical-lens transfer uses [C.29](/generated/patterns/C.29).

Episteme case boundary. In an episteme case, the acting and revising work is performed by systems or acting holons holding Transformer roles. Review practices or methods describe the revision work; they do not hold the role. The U.Episteme is the knowledge-bearing object being reviewed, revised, stabilized, cited, or published. It does not itself sense, judge, plan, or act.

Worked slice A - robotic swarm. A drone fleet has individual drones, a shared communication medium, and a fleet-scope controller or distributed consensus method. [B.2.5](/generated/patterns/B.2.5) records each drone as supervised holon, the controller or consensus system as supervisor transformer, telemetry as observation side, and waypoint or mode commands as influence side. Claims about exponential convergence, delay tolerance, or disturbance damping use [A.3.3](/generated/patterns/A.3.3), [C.27](/generated/patterns/C.27), and the evidence or assurance pattern governing the claim being made.

Worked slice B - scientific theory. A scientific theory is revised when labs publish findings and a research community reviews anomalies and accepted revisions. [B.2.5](/generated/patterns/B.2.5) records the theory or its constituent epistemes as supervised objects and the research community as supervisor only when it is modeled as an acting holon or system holding the transformer role; review practices or methods describe the revision work. Journals, conferences, datasets, and review records are publication or interaction channels. The theory does not perform the sensing or judging; acting systems and holons do.

Worked slice C - product supervisor loop. A product platform constrains component teams through published interface rules and release gates. [B.2.5](/generated/patterns/B.2.5) records the supervising platform policy role, component/subproduct holons, report channels, and constraint returns. Work authority uses [A.15](/generated/patterns/A.15); gate passage uses [A.21](/generated/patterns/A.21); interface commitments use [A.6.M](/generated/patterns/A.6.M).

Archetypal Grounding

Archetype	Without B.2.5	With B.2.5
System	A control diagram mixes physical parts, roles, and commands, then claims coordination is obvious.	The supervised systems, supervisor transformer, shared medium, feedback relation, and returned influence are named.
Episteme	A theory or model is said to sense, judge, plan, or adapt.	Acting systems or acting holons may hold a transformer role through current `U.RoleAssignment`; review practices or methods describe how the episteme is reviewed, revised, cited, or published.

Bias-Annotation

Diagram closure bias. A loop drawn on a diagram is read as a closed feedback loop. Repair by naming both observation/report and influence/constraint sides.
Layer/level bias. Layered diagrams hide whether the label names control role, declared system level, aggregation scope, rate band, or publication grouping. Repair by recovering the declared kind.
Episteme-agent bias. Knowledge-bearing objects are described as acting agents. Repair by naming the acting Transformer, publication or revision practice, and source or reliance relation.
Proof-by-loop bias. A loop relation is read as stability, safety, or assurance proof. Repair by assigning the claim kind being made to the governing pattern.

This checklist verifies the preceding guidance after the practitioner has chosen the selected move; it is not a required project control form and not a substitute for the card, note, view, relation, or repair move above.

Conformance Checklist

ID	Check	Why it matters
CC-B2.5-1	A conforming use names supervised holon refs and the supervisor role/transformer refs.	Prevents ghost coordination.
CC-B2.5-2	A conforming use names the shared medium or publication/interaction channel that carries observations, reports, signals, constraints, or influence.	Makes the loop inspectable.
CC-B2.5-3	A conforming use names both observation/report and influence/constraint sides or explicitly says the loop is not closed.	Separates closed feedback loops from one-way commands.
CC-B2.5-4	A conforming use keeps structural composition, supervisory relation, and interaction/publication network distinct.	Prevents layer/part category errors.
CC-B2.5-5	Stability, safety, timing, causal, evidence, assurance, gate, and mathematical-lens claims are assigned to their governing patterns.	Prevents loop-as-proof overread.
CC-B2.5-6	Episteme examples name the acting systems or practices that perform review, revision, publication, or use.	Prevents episteme-agent overread.
CC-B2.5-7	If a control-structure view is being claimed, the control-structure-view claim is governed by `C.30.LCA`.	Keeps relation-level feedback claims and view-level architecture claims aligned.

Common Anti-Patterns and How to Avoid Them

Anti-pattern	Symptom	Repair
Ghost coordination	Subholons coordinate, but no supervisor role, shared medium, or feedback relation is named.	Name supervisor role, acting transformer, observation/report side, and influence/constraint side.
Functional layer as component	A planning or control layer is modeled as a physical part of the controlled holon.	Separate structural composition from supervisory relation.
Perfect communication	The loop assumes instant, complete, or lossless access to subholon state.	Add interaction/publication medium limits and assign timing or information claims to `C.27`, `A.3.3`, or evidence claim.
Episteme acts	A theory, model, paper, or dashboard senses, judges, plans, or adapts.	Name the acting system, operator, review practice, or revision practice; keep the episteme as described or revised object.
Loop proves safety	The loop is treated as evidence, assurance, gate, or safety proof.	Keep the loop relation and apply the governing pattern for the claim kind being made.

Consequences

The gain is a precise loop relation that is usable for architecture, control, organizational, and epistemic examples without collapsing them. A practitioner can keep ordinary supervisor/subholon language while naming the acting role, medium, and returned influence.

The cost is that B.2.5 no longer lets a layered-control diagram establish stronger proof or project-reliance claims. That cost is intentional: the loop relation is useful because it tells the practitioner what to inspect next, not because it silently certifies stability, safety, evidence, or assurance.

Rationale

Supervisor-subholon feedback loops are a recurring architecture form. The form is most useful when it is separated from structural mereology and from proof. That separation preserves the engineering insight from layered control architecture while keeping FPF's EntityOfConcern and Description-episteme boundary and specification use and role/transformer distinctions intact.

The same separation also keeps the epistemic case precise. Scientific theories, documents, models, and other epistemes can participate in feedback loops as reviewed or revised objects and as publications, source objects, or reliance objects, but acting systems or acting holons hold the transformer role through current U.RoleAssignment, while practices or methods describe how the transformation is performed. This lets the same pattern cover systems and epistemes without agentive overread.

SoTA-Echoing

SoTA/practice anchor	What it informs	FPF adoption stance	Practitioner implication
Layered and multi-rate control architecture practice, with Matni/Ames/Doyle used here as lineage and practice lineage for layered multi-rate control rather than as current proof by itself.	Supervisor, plant, controller, planner, observer, feedback, and rate separation are useful relation cues for supervisor-subholon loop recovery.	Adopt and adapt: keep supervisor-subholon loop recognition, then assign stability, timing, safety, evidence, assurance, and gate claims to their governing patterns.	A loop diagram starts the relation record; dynamics, timing, and safety claims still need their own pattern.
Cyber-physical systems and feedback-control practice.	Shared medium limits, observation channels, actuation, delay, disturbance, and plant dynamics affect whether a loop is adequate.	Adopt: require loop closure and medium visibility; assign reusable dynamics claims to `A.3.3`.	If communication delay matters, it is not solved by the B.2.5 label.
Organizational policy and review practice.	Supervisory relations can be enacted through policies, review boards, reports, and publication channels.	Adapt: model the acting systems/practices and publication/source or reliance relations explicitly.	A committee or review practice may supervise; a published note does not act by itself.
FPF architecture-description discipline under `C.30` and `C.30.LCA`.	A supervisor loop can be one relation inside a control-structure view.	Reuse: `B.2.5` supplies relation recovery; `C.30.LCA` supplies view recovery.	Use the pattern that governs the claim kind being made, then add the related pattern only when a second claim being made is present.

Relations

Builds on B.2, A.1, A.2, A.2.1, A.3, A.3.4, A.7, and A.15; work-facing transformer responsibility is represented through current U.RoleAssignment, U.Work, and transformation discipline, without bypassing those current relations.
Coordinates with C.30.LCA for control-structure view adequacy.
Applies A.3.3 for reusable dynamics or stability claims, C.27 for temporal/rate adequacy, C.28 for causal-use claims, A.10/G.6 for evidence claim, B.3 for assurance, A.20/A.21 for constraint validity and gate decisions, A.15 for work authority, and C.29 for mathematical-lens transfer.

Neighboring claim governance: use C.30.LCA for control-structure view adequacy, A.3.3 for dynamics claims, C.27 for temporal/rate adequacy, C.28 for causal-use claims, A.10 or G.6 for evidence claims, B.3 for assurance, A.20 or A.21 for gate and constraint-validity records, A.15 for work authority, A.6.M for module-interface relation repair, and C.29 for mathematical-lens use.

B.2.5:End

Last Updated: 2026-06-17 — this section last modified in upstream FPF commit 205de763 (github.com/ailev/FPF)

#Supervisor–Subholon Feedback Loop

#About this pattern

#How to use this pattern

#Keywords

#Relations

#Content

#Problem frame

#Problem

#Forces

#Solution

#Archetypal Grounding

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

#SoTA-Echoing

#Relations

#B.2.5:End

Supervisor–Subholon Feedback Loop

About this pattern

How to use this pattern

Keywords

Relations

Content

Problem frame

Problem

Forces

Solution

Archetypal Grounding

Bias-Annotation

Conformance Checklist

Common Anti-Patterns and How to Avoid Them

Consequences

Rationale

SoTA-Echoing

Relations

B.2.5:End