Manual Supervision Mode¶

A control policy — instantiates Safe Mode Operation

Routes actions that are normally automated through a human reviewer, so a person approves each consequential step while the system's autonomy can't be trusted.

Manual Supervision Mode removes autonomy, not capability. The system can still do everything it normally does — but during the restricted state, each consequential action it would have taken on its own is now paused for a human to review and approve first. Its defining move, distinct from every sibling, is inserting a human checkpoint into the action loop: the machine proposes, a person disposes. Where Privilege Scope Restriction narrows what actions are possible and Feature-Flag Disablement turns a capability off, Manual Supervision Mode keeps the capability on but subordinates it to human judgment, on the theory that a person can catch the specific errors the untrusted automation is now prone to.

Example¶

An algorithmic trading desk's execution model starts behaving oddly after a market-data feed glitch — its position sizing looks miscalibrated, but not clearly enough to shut it off and lose the day's flow. The desk flips the system into manual supervision: the algorithm keeps generating orders, but instead of firing them straight to the exchange, each order above a size threshold now surfaces on a trader's screen for approval, with the model's rationale attached. A human sees the proposal, sanity-checks it against the market, and approves, modifies, or rejects it.

A trader catches two oversized orders the glitchy feed produced and kills them; the routine ones they wave through. The desk keeps trading — it isn't dark — but nothing consequential executes without a person having looked. When the same odd sizing recurs three times in an hour, the standing rule escalates it: the supervising trader hands the case up to the risk desk, which pulls the model entirely rather than keep rubber-stamping a pattern that shouldn't exist.^[1]

How it works¶

The mechanism re-routes the automated action path through a human gate. Actions that were fire-and-forget become proposals requiring explicit approval, ideally with the system's reasoning attached so the reviewer can judge rather than just click. Two things distinguish it from mere logging: the human's approval is load-bearing (nothing consequential proceeds without it), and the arrangement carries an escalation path for when review reveals a deeper problem than case-by-case approval can handle. The reviewer both authorizes individual actions (override governance at the point of action) and watches for whether the automation is drifting further off (monitoring), which is what tells them when to stop approving and escalate.

Tuning parameters¶

Approval threshold — which actions need sign-off — all of them, or only those above a size/risk/novelty bar. A low threshold catches more but floods the reviewer and invites rubber-stamping; a high one keeps focus but lets small errors through.
Reviewer authority — approve-only, or approve/modify/reject. Fuller authority lets the human correct rather than just gate, at the cost of demanding more expertise.
Rationale visibility — how much of the system's reasoning is shown with each proposal. More context enables genuine review; too much induces fatigue and skimming.
Escalation trigger — how many anomalies or rejections before the case is handed up or the automation pulled, tuning how long supervision persists before stronger action.

When it helps, and when it misleads¶

Its strength is keeping a valuable-but-suspect automated capability in service under a safety net: throughput continues, but a human intercepts exactly the errors the impairment introduced, and the arrangement can escalate when case-by-case catching isn't enough. It's the right mode when shutting the automation off is too costly but trusting it outright is unsafe.

The classic failure mode is automation complacency: a reviewer facing a stream of mostly-fine proposals stops truly reviewing and rubber-stamps them, so the human checkpoint becomes theater and the errors flow through anyway.^[1] The mirror failure is the human becoming a bottleneck that throttles throughput to a crawl. The discipline that guards against complacency is keeping the review load low enough to be real (a sensible threshold), showing rationale so judgment is engaged, and — crucially — treating a recurring anomaly as a trigger to escalate and pull the automation, not to keep approving forever.

How it implements the components¶

Manual Supervision Mode fills the human-in-the-loop subset:

override_governance — a human's explicit approval is required for each consequential action, and the reviewer holds the authority to modify or reject what the automation proposes.
safe_mode_monitoring — the supervisor watches whether the automation is drifting further off, judging not just each action but the trend.
escalation_path — when review reveals a problem deeper than case-by-case approval can contain, the standing rule routes it up to stronger action (pull the automation).

It does not disable the capability outright (capability_limit — see Feature-Flag Disablement) or narrow who is permitted to hold authority in the first place (restricted_mode_boundary — see Privilege Scope Restriction); the capability stays on, subordinated to review.

Instantiates: Safe Mode Operation — the variant that subordinates untrusted autonomy to human approval.
Sibling mechanisms: Privilege Scope Restriction · Feature-Flag Disablement · Diagnostic Mode · Limited Service Mode · Read-Only Mode · Maintenance Mode · Quarantine Mode · Limp-Home Mode · Safe-Mode Banner or Indicator · Staged Capability Restore

References¶

[1] Automation complacency (a form of automation bias) is the documented human-factors tendency to under-scrutinize a normally-reliable automated system's outputs. It is the specific reason a human-in-the-loop check can quietly stop working, and why review load and escalation triggers must be designed, not assumed. ↩