#Supervisor-Subholon Feedback Relation

B.2.5 · Stable · Part B holonic construction pattern · Normative unless a section is explicitly informative · Part B - Trans-disciplinary Reasoning Cluster

#About this pattern

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

#How to use this pattern

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

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

Use this pattern when a holon is supervised, regulated, steered, corrected, constrained, or coordinated through a two-sided feedback relation between one supervising acting system and one or more supervised holons. If the supervision is conditioned by a local system-role kind or assignment, recover that classification and exact assignment separately.

#Relations

#Content

#Use This When

Use this pattern when a holon is supervised, regulated, steered, corrected, constrained, or coordinated through a two-sided feedback relation between one supervising acting system and one or more supervised holons. If the supervision is conditioned by a local system-role kind or assignment, recover that classification and exact assignment separately.

The first useful move is to recover the relation:

Which holons are supervised?
Which admitted system supervises these holons for this feedback use, under which policy and during which time window, and which local supervisor system-role kind and exact assignment obtain when that classification matters?
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, supervising acting system, optional exact system-role kind and assignment, medium or publication relation, observation or report side, influence or constraint side, and the patterns that define any stronger claim.

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, provenance, assurance, or a gate decision, use [A.10](/generated/patterns/A.10), [G.6](/generated/patterns/G.6), [B.3](/generated/patterns/B.3), or [A.21](/generated/patterns/A.21) respectively. Use [A.20](/generated/patterns/A.20) for its internal-constraint test in a transformation-flow structure; other constraint claims need their direct pattern.
• If module or interface wording hides the exact claim, use [A.6.M](/generated/patterns/A.6.M) to recover it; use the direct pattern for an already precise allocation or commitment claim.
• If the question is whole reidentification, use [B.2](/generated/patterns/B.2).

#Problem Frame

Supervisor-subholon feedback is a relation among supervised holons, a supervising acting system, observed or published state, and returned influence or constraint. A system-role kind or assignment may qualify the acting system but is not created by the feedback relation. The relation is not automatically parthood, a control-structure view, evidence, or a mathematical loop object.

Use B.2.5 for the relation-level claim. It can sit inside a broader architecture description, control-structure view, MHT claim, work claim, or evidence claim, but treat those as separate claims under their applicable patterns.

#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 admitted system supervises, what it observes, and what influence or constraint returns; add its system-role kind and assignment only when separately current.
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)
  feedbackPolicyRef?
  claimScopeRef?: U.ClaimScope
  qualificationWindowRef?
  supervisorSystemRoleKindRef?: U.KindRef resolving to one exact local system-role kind
  supervisingActingSystemRef: U.EntityRef resolving to one admitted U.System
  supervisorSystemRoleAssignmentRef?: U.RelationRef constrained to U.SystemRoleAssignment
  supervisedWorkOrTransformationRefs?
  observationOrReportRefs: FinSet(ObservationRef | ReportRef | PublicationUnitRef | SourceUseRef)
  influenceOrConstraintRefs: FinSet(InfluenceSignalRef | ConstraintRef | ObjectiveRef | ModeRef)
  sharedMediumOrPublicationRefs?
  holonBoundaryCrossingRelationRefs?
  feedbackClosureCondition:
  evidenceRefs?
  admissibleUse:
  nonAdmissibleUse:
  strongerClaimPatternRefs?

This relation is not a U-kind and not a mathematical loop lens. The record names the exact supervised holons, supervising acting system, feedback policy when one applies, signal paths, ClaimScope when needed, qualification window, and evidence when a later use relies on it. Evidence can support the claim but does not create the feedback relation. The kind and assignment fields are present only when the classification and the assignment occurrence with its declared species exist separately; the feedback relation creates neither.

#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, name and record that exact claim under the pattern that defines it.

#Part-Whole Boundary

A supervised holon may be part of a larger holon, but supervision and parthood are different relations. A controller, committee, platform-governance group, review board, or tool-mediated group can supervise when the exact acting entity is independently admitted as U.System; it may do so under an exact system-role assignment 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 for holon recognition, A.14 for the exact mereological claim, and B.1 or C.13 for the applicable construction account. Use B.2.5 only for the supervisor-subholon feedback relation.

#Acting-System Boundary

The supervising participant is an admitted acting system. When local classification matters, A.2 supplies the exact supervisor system-role kind and A.2.1 supplies the obtaining assignment; neither label nor assignment acts. 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 system-role kind and assignment, use A.2 and 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 is the pattern for 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 for its internal-constraint test in a transformation-flow structure and A.21 for 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 as an admitted supervising system, telemetry as observation side, and waypoint or mode commands as influence side. Add a local supervisor system-role kind and exact assignment only if this use relies on them.

Claims about convergence, delay tolerance, disturbance damping, evidence, assurance, or safety use their subject patterns. 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. Recover the exact admitted System that performs the review or revision, whether it is a research community, standards body, lab, review board, or tool-mediated group; any local system-role kind and assignment are separate claims. The theory remains the reviewed or revised episteme.

For publication channels, journals, datasets, reports, and review records, keep each object's identity distinct from its current publication or source-use relation; recover content, form, representation, or carrier only when the case depends on that distinction.

#Product Platform Policy

A product platform constrains component teams through interface rules and release gates. B.2.5 records the admitted platform or governance system that supervises, component holons, report channels, and constraint returns; a system-role kind or assignment is added only when separately current.

Work alignment uses A.15; a separate work-authority claim needs its own direct pattern. Gate passage uses A.21; A.6.M restores interface wording before the exact commitment claim returns to its direct pattern; 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 need qualification because their stronger claims remain unproven.
• 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 subject is a relation. A mathematical loop, if needed, is a lens or structure selected by another pattern; the relation's name does not establish it.

#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 exact feedback facts leave a whole-reidentification question; evidence separately supports or challenges the claims about those facts.
• 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 for its internal-constraint test in a transformation-flow structure, A.21 for gate decisions, A.6.M for module-interface wording, and C.29 for mathematical-lens use.
• Uses: B.2.P when emergence or MHT wording hides the claim kind, including feedback or supervision invoked as an emergence claim. Ordinary feedback wording follows F.19/E.10 restoration and its direct subject pattern.

#B.2.5:End

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)