Authority is the contract between an algorithm and the equipment it touches.

Authority is the contract, not a slider for tuning trust.

Every action an algorithm takes against customer equipment carries an explicit authority level that names what the action may do unsupervised. Authority is not a confidence threshold and not a vendor's general trustworthiness rating. It is the specific commitment, on the row, that defines the boundary between what the system may execute and what it must escalate.

Authority belongs to the action, not the agent.

A strategy that runs an FCU occupancy setback at Dispatch authority is not a trusted strategy globally. It is a strategy whose specific action (raising the setpoint by up to two degrees when the zone is vacant) is trusted in this entity, on this site, under this configuration. The same strategy on a different entity may sit at Recommend because the consequence of a wrong move differs by orders of magnitude across entities.

The default is Recommend.

Every new action commissions at Recommend. Cases are created for the operator to review; no equipment is touched without explicit approval. Promotion to Adjust or Dispatch is earned by watching cycles match intent at the lower level, not granted by checking a configuration box.

Class-based ceilings exist because consequence is not confidence.

Some actions can be a hundred percent confident and still consequential enough to deserve human review every time. A HACCP-class action (anything that touches temperature in a food-storage boundary) is refused promotion past Recommend by the platform, not by convention. The ceiling reflects the cost of failure, not the algorithm's competence.

Refusal beats degradation.

When an action exceeds the authority granted to it, the platform refuses the action rather than silently downscaling it to a level that would have been allowed. A strategy at Adjust authority whose decision exceeds the registry's guard-rail clamp does not get a clamped version executed. It gets refused and surfaced as a Case for human review, so the gap between what the strategy wanted and what the platform would allow is visible.

Every authority change is on the audit trail.

Promotion, demotion, pause, archive: every transition is a row on the decision stream alongside the decisions themselves. A reviewer reading the trail of a settlement event can see not only what the strategy did but what level of trust it had at the moment it did it.

The BMS-vendor mental model is per-agent

A typical building-management system treats authority as a global property of the algorithm: this optimiser is trusted, that one is not. The model fails the operator on the day the trusted optimiser meets an entity it should not be trusted on, or on the day the partially-trusted one is the only viable choice for a specific zone. Per-agent authority is a coarse instrument for a fine-grained problem.

The operational reality is per-action

Operators do not think 'this algorithm is trustworthy.' They think 'this specific change to this specific equipment is something I am comfortable with the system doing without asking me.' The mental model of authority is local. Per-action authority matches what the operator actually decides, which is also the only place the decision can be defended in audit.

The engineering consequence

Per-action authority lives as a column on the strategy row (or, in the case of one-off actions, on the action itself). The platform reads the column at decision time and gates the side effect. A strategy that emits a hundred decisions in a day may have those hundred decisions evaluated against the same authority value or against different values for different decision classes; the engine does not assume that an algorithm has one authority for everything.

Commission at Recommend

Every new action commissions at Recommend. The operator sees Cases as the strategy makes decisions. Watching the first cycles is the customer's first piece of operational evidence; the verifier's first verification cycle is the second.

Watch cycles match intent

Promotion is earned by the strategy doing what it said it would do at the lower level. An FCU setback that fired forty-two times in the first thirty days at Recommend, with the operator approving forty-one and rejecting one (with the reason recorded), has earned its case for promotion.

Promote one level at a time

The platform refuses jumps. A strategy at Recommend may move to Adjust; not to Dispatch. The intermediate level exists precisely so the operator can see the strategy acting within registered guard-rails before letting it act without them. Skipping the level removes the evidence the next promotion would have relied on.

Demotion is symmetrical

Any operator can move a strategy back down the ladder at any time. Demotion does not require justification; it is reversible. The platform treats authority as a thing the operator decides, full stop.

HACCP class

Any action that touches a temperature, time, or pressure inside a food-safety monitored process. Maximum authority: Recommend. The operator must approve every decision. Reflects the cost of failure (a spoiled batch, a recall, a regulator letter), which is structurally larger than the algorithmic confidence can compensate for.

Life-safety class

Any action that touches a smoke-control damper, an emergency stop, a fire-pump, or an egress-affecting lighting circuit. Maximum authority: Recommend, and only after a human operator has signed the specific entity's safety-class registration. Many entities in this class are simply outside the platform's action scope by registry decision.

Grid-critical class

Any action that participates in a utility demand-response market or an emergency grid event. Maximum authority: Dispatch by default, Emergency only after the program operator has registered the entity into the higher-class queue. Emergency is the rare class that explicitly authorises execution-before-notification.

Comfort and convenience class

Everything else. Most building-controls actions live here: FCU setpoints, lighting schedules, exhaust speeds, BAS occupancy modes. Maximum authority: Dispatch by default. Operator may set lower per strategy.

Promotion above the class ceiling

An operator requesting to promote a HACCP-class strategy from Recommend to Adjust is refused at the request layer. The platform pattern-matches the strategy's safety class against the registry and rejects the transition. The refusal is recorded so a reviewer can see the attempt.

Action outside the registered guard-rails

A strategy at Adjust authority whose decision (raise setpoint by three point five degrees) exceeds the registered guard-rail clamp (maximum two degrees) does not get a clamped two-degree action. It gets refused, the decision lands as 'declined,' and a Case is filed so the operator can decide whether to override or to widen the guard-rail.

Action outside the strategy's authority class entirely

A strategy whose decision would touch a HACCP-class variable does not get to take that action regardless of authority. The platform refuses at action time, because authority alone does not authorise crossing class boundaries; the safety-class registration is a separate dimension.

Demotion below the strategy's safety floor

Some actions are required to be at least Observe (they cannot be silenced entirely). A demotion to a hypothetical 'off' level is refused at the request layer. Policies that have to be watching are watching; the operator can pause the actions, not the observation.

IEC 61508 SIL (Safety Integrity Level) 1-4

The functional-safety standard that classifies safety functions by the rigor required, with higher SIL levels demanding more proof of correctness. The authority ladder is the runtime analogue: graduated trust at action time, with the ceiling reflecting the consequence of failure rather than the algorithm's confidence. SIL is design-time; authority is runtime.

ANSI/ISA 84 (IEC 61511) for process industries

Layered safety: BPCS (basic process control) sits inside SIS (safety instrumented systems) inside ESD (emergency shutdown). The authority ladder operationalises a similar layering for AI-driven control: Recommend sits inside Adjust sits inside Dispatch, with each higher level taking on more autonomous behaviour and the safety-instrumented layer (registry guard-rails, class ceilings) catching what the algorithm should not have done.

ISO 26262 ASIL for automotive

Automotive Safety Integrity Levels A through D, classified by the consequence of failure (severity) times the probability of occurrence times the controllability by the driver. Class-based ceilings in the authority ladder use the same logic: consequence and recoverability dominate the choice of ceiling, not algorithmic accuracy.

Departure from prior art

Industrial-control safety standards classify functions at design time and freeze the classification. The authority ladder is dynamic: the operator's grant is mutable per strategy, per entity, per moment. The standards' insight (consequence drives rigor) is preserved; the implementation acknowledges that AI deployment is iterative in a way classical control commissioning was not.

Beyond building controls

Any deployment of an algorithm onto third-party equipment can use the same ladder. Industrial process control, EV charging dispatch, building-to-grid integration, microgrid orchestration. The seven levels and the class ceilings are domain-agnostic; only the registry of class-to-ceiling mappings is specific to the domain.

Beyond AI

The ladder is also useful for human operators in a multi-tenant context. A facilities manager at a co-tenanted site may have Recommend authority on one tenant's space and Dispatch on another's; the same column on the same row gates both. Authority is more general than algorithmic trust; it is an action-scoped permission contract.

Beyond first deployment

The ladder supports continuous deployment of new algorithm versions onto existing equipment. A new model release commissions at the same level its predecessor reached, and the operator may demote temporarily to observe the new behaviour at Recommend before restoring the prior level. The ladder is how software updates land safely on running equipment.