Actuation-Scope-Registered Control Loops

also known as Declared Write-Scope Registry, Loop Actuation Registry, Closed-Loop Conflict Declaration

Have every long-lived automated loop declare, in a registry all loops share, the resources it may actuate and the indicator it optimises, so overlapping actuation scope is detectable before any loop runs.

Context

A plant — a mobile network, a cluster, a building, a fleet — is run by several closed loops that each observe, decide and act without waiting for a person. Each loop was specified separately: a different team, a different vendor, a different procurement cycle, each handed one indicator to defend and one set of control handles to defend it with. Every loop is well tuned against its own objective and passes its own tests. Nothing in the way they were commissioned records which control handles two loops both consider theirs, because no artefact spans them.

Problem

When two loops can write the same resource, one loop's corrective action is the next loop's disturbance. Neither loop is faulty and neither raises an error: each observes a deviation it was built to correct, corrects it, and is undone by the other, so the contested parameter oscillates and the indicators every loop was built to protect all degrade together. The conflict is invisible to per-loop monitoring, which is the only monitoring anyone owns. It also resists diagnosis after the fact: with several objectives active at once the same symptom drifts across several indicators, and attributing a degradation to the right one is a separate inference problem rather than a lookup. Central arbitration of every action would remove the conflict by construction, but it is impractical at scale when the control period is short and the loops are many.

Forces

Centralised optimisation avoids conflict by construction but is impractical in large deployments for time-critical work, so coordination has to live in the loops themselves rather than in one global scheduler.
Each loop is individually correct and individually stable, so no loop's own tests, alarms or dashboards show anything wrong; the pathology exists only in the relation between loops.
Loops built by separate teams or vendors have no common owner who could impose an ordering, and each team reasonably believes it owns the handle it was told to control.
A declaration of write scope is cheap to author and cheap to intersect, but a loop that writes outside its declared set makes the check return a false clean, which is worse than no check.
Direct overlap — two loops writing the same parameter — falls out of the declarations by set intersection, while coupling that runs through the physical process rather than through a shared handle does not, so a static check narrows the problem without closing it.
Resolving an overlap costs the losing loop some of its control authority, so a settlement that improves the shared indicators can still reduce how reliably any single loop meets its own target.

When to use

Two or more long-lived automated loops act on the same plant and were specified by different teams, vendors or procurement cycles.
A loop can write a resource that another loop also treats as its own control handle.
Conflicts show up as degraded indicators rather than as errors, so no loop's own monitoring reports a fault.
The plant has no commissioned arbitration layer, such as a selector network or override hierarchy, that already decides which loop wins a contested handle.
Central arbitration of every action is impractical because the control period is short or the number of loops is large.

When not to use

The plant already carries a commissioned selector or override hierarchy that settles contention deterministically, in which case that existing arbitration should be used rather than a second mechanism.
Exactly one loop writes each resource and the loops are otherwise isolated from one another.
The loops genuinely share a single objective, so aligning them on a common goal is simpler than constraining their write scopes.
The coupling runs entirely through the physical process rather than through a shared write target, which an intersection of declared resource sets cannot detect.
The loops are short-lived tasks rather than perpetual controllers, where a transaction or a lock is the cheaper answer.

Example

An office building runs two automated loops. One lowers the blinds when solar gain rises, because it is scored on cooling energy; the other raises them when desk-level light drops, because it is scored on lighting energy. Neither loop's design ever recorded that both write the same blind motor. On a bright afternoon the blinds cycle up and down for hours, both energy figures get worse, and the facilities team finds the cause only after the motors start to fail.

Diagram

flowchart TD A["Loop A declares: resource set + optimised indicator"] --> R["Shared loop registry"] B["Loop B declares: resource set + optimised indicator"] --> R R --> C{"Declared resource sets intersect?"} C -- "no" --> D["Commission both loops unchanged"] C -- "yes" --> E["Contested resource: lease, shared reward, or declared priority"] E --> D D --> M{"Runtime write outside declared scope?"} M -- "yes" --> F["Reject the write, flag the stale declaration"] M -- "no" --> G["Loops run; the overlap was settled before either started"] G --> H["Indicator degrades: reverse lookup finds every loop that can write it"]

Solution

Therefore:

Give every loop a declaration and put the declarations in one place. The declaration names the loop, the resources it is permitted to actuate, the indicator it optimises, and its priority relative to other loops; it is written during preparation, before the loop is commissioned, and it is versioned like any other artefact. Commissioning then becomes a check rather than a hope: intersect the candidate loop's declared write set with the write set of every loop already registered. An empty intersection admits the loop unchanged. A non-empty intersection is a conflict found on paper, and it is settled before either loop starts — by a time-bounded lease over the contested resource, by replacing the two local objectives with a shared reward so the loops cooperate over that resource instead of each chasing a local optimum, or by a declared priority that says which loop yields. Two loops may still share a resource, but never on the terms each would have chosen alone. At runtime a monitor compares observed writes against the declaration and rejects or flags an actuation outside the declared scope, which is what keeps the registry honest as loops are retuned. The declaration is also the diagnostic index: when an indicator degrades, the set of loops that can write the implicated resource is a lookup rather than an investigation.

What it gives you

Overlapping actuation becomes a static property that can be checked at commissioning, so a class of incident is found on paper instead of in production.
Attribution after a degradation is a lookup over declared write sets rather than an inference across several simultaneously active objectives; a benchmark of the multi-intent case reports 9.4% to 45.8% better attribution of a degradation to the correct objective when disambiguation is modelled explicitly, which is the gap a declaration closes by construction for the direct case.
Coordination stays local to the loops that actually share a resource, so nothing has to run at the rate of a global scheduler.
The declaration doubles as documentation of what each automated loop is allowed to touch, which is the artefact a change review or an audit otherwise has to reconstruct.

What it costs you

The check is only as good as the declarations; a loop retuned to write a new handle without updating its entry produces a clean intersection over a stale set.
Coupling through the plant rather than through a shared handle — two loops writing different parameters whose effects meet in the process — is invisible to a set intersection and still needs runtime detection.
Settling a contested resource takes control authority away from at least one loop; a study of conflict mitigation between independently authored radio-access applications reports better network performance from balancing them against a small negative effect on reliability.
Declaring scope for loops that already run means retrofitting entries for systems whose owners have moved on, and the entries most likely to be wrong are exactly the oldest ones.
A registry invites the assumption that a registered overlap has been resolved, when all that is recorded is that someone saw it.

What this pattern forbids. A loop may not actuate any resource it has not declared in the shared registry, and no loop may be commissioned while its declared resource set intersects another loop's without an agreed arrangement for the contested resource; where scopes overlap the loops must not each optimise their own indicator independently.

And the patterns that stand alongside it, or against it —

alternative-toControl-Loop-Mapped Agent Chain·— Give each existing feedback loop in a plant's control chain its own operator agent carrying that loop's control-theoretic context, and resolve their competing proposals with the chain's own deterministic selector logic.
complementsSymptom-Remediation Thrashing✕— Anti-pattern: a stateless auto-remediation agent repeatedly applies symptom-level fixes that hit the target metric while masking the root cause and suppressing the page, so the underlying fault compounds across incidents into a larger outage.
complementsRace Conditions on Shared Tool Resources✕— Anti-pattern: let concurrent agents perform read-modify-write on shared external resources without locking, producing silent data corruption.
complementsHidden State Coupling✕— Anti-pattern: agent workflows read or write undeclared shared state (caches, env vars, process globals) instead of explicit inputs and outputs.
complementsAgent Capability Manifest★— Let each agent publish a standardized self-description — identity, skills, endpoint, and auth needs — at a well-known location, so others discover it and bind by capability at runtime instead of through hardcoded coupling.
complementsPriority Matrix (Conflict Resolution)★— Pre-define how the agent must resolve specific classes of goal conflicts via a human-authored lookup table — transforming the agent from a decision-maker (where it fails on competing objectives) into a decision-implementer.
alternative-toJoint Commitment Team·— A team of agents adopts a shared goal plus the meta-commitment that each member will notify the others as soon as it believes the goal is achieved, impossible, or no longer relevant.