Diagnostic Mode¶

An operating mode — instantiates Safe Mode Operation

Keeps inspection, testing, and instrumentation alive while blocking production, actuation, and public-facing output, so a fault can be understood before it is touched.

Diagnostic Mode is the restricted state whose whole purpose is understanding the fault, not surviving it. It keeps alive exactly the functions needed to inspect, test, and read internal state — sensors, self-tests, log access, single-step actuation under supervision — while cutting off everything that acts on the outside world: production runs, real deliveries, patient-facing or customer-facing output. Where a sibling like Limited Service Mode keeps a slice of service running for users, Diagnostic Mode keeps a slice of visibility running for a technician, and deliberately serves no one else. The defining move is that the only capability preserved is the capability to look inside; the system stops doing its job so someone can find out why it stopped doing it well.

Example¶

A hospital infusion pump detects an occlusion-sensor reading that doesn't reconcile with its flow calculation — it can no longer trust its own delivery. Rather than keep pumping (which could over- or under-dose) or go fully dark (which hides the fault and strands the ward), it drops into a diagnostic state. Medication delivery is blocked entirely. What stays live is the biomedical technician's path: the pump runs its built-in self-test, replays the last hour of sensor traces, exposes the pressure and flow logs over the service port, and will step the actuator through a dry test cycle with no cartridge loaded so the tech can watch the mechanism without any drug reaching a patient.^[1]

The tech reads the traces, sees the occlusion sensor drifting, swaps it, and re-runs the self-test — all without the pump ever delivering a dose it couldn't vouch for. The mode gave up the one thing that mattered clinically (delivery) precisely to preserve the one thing that mattered for repair (a trustworthy view of the internals).

How it works¶

Diagnostic Mode inverts the usual allowlist. Instead of naming the minimal service that stays up, it names the minimal inspection surface that stays up — read access to state, self-tests, and instrumented, no-effect versions of otherwise-dangerous actions — and blocks the acting surface completely. Any actuation that survives is deliberately declawed: dry runs, single-step-under-confirmation, loopback tests that exercise the mechanism without letting it reach the real world. The distinguishing discipline is that no diagnostic action may have a production side effect; if a test could actually dose a patient, ship an order, or move a robot into an occupied cell, it is gated behind a physical or logical decoupling first.

Tuning parameters¶

Inspection breadth — how much internal state the mode exposes. Wider access speeds diagnosis but enlarges what a mistaken or malicious technician can see or trigger.
Actuation allowance — from pure read-only to supervised single-step dry runs. More live actuation makes some faults reproducible that are invisible at rest, at the cost of reintroducing the very risk the mode exists to hold off.
Decoupling depth — whether "dry" is enforced logically (a software guard) or physically (no cartridge, robot arm locked out). Physical decoupling is safer and slower to set up.
Access authentication — how tightly the diagnostic path is gated to authorized service staff, trading repair speed against exposure of a powerful inspection surface.

When it helps, and when it misleads¶

Its strength is that it makes a fault legible without letting the faulty system act — the single most useful state when you know something is wrong but not what. It preserves evidence a full shutdown would freeze or lose, and it gives repair a foothold that "keep running" would make unsafe.

The classic failure mode is the diagnostic surface becoming a bypass: because the mode exposes powerful internals and can single-step actuators, it is tempting to stay in diagnostic mode to keep operating with the safety interlocks defeated "just until the part arrives." That turns an inspection state into an unmonitored production state with its guards off. A subtler misuse is running a "diagnostic" test that quietly has a real side effect — a test order that actually ships. The discipline that guards against both is the no-side-effect rule: every preserved action must be provably decoupled from the real world, and exit from diagnostic mode must be an explicit, logged event, never a silent drift back to full operation.

How it implements the components¶

Diagnostic Mode fills the inspect-the-fault subset of the archetype's machinery:

diagnostic_access_path — its reason for existing: the authenticated path by which a technician or tool reads internal state, runs self-tests, and inspects logs while risky capability stays blocked.
essential_function_allowlist — the allowlist here is an inspection allowlist: self-tests, state read-out, and decoupled dry runs are the only functions permitted to continue.
capability_limit — all production, actuation, and outward-facing output are disabled; anything that could act on the real world is cut.

It does not detect the fault (anomaly_or_failure_signal — see Quarantine Mode), announce status to users (mode_status_communication — see Safe-Mode Banner or Indicator), or govern how normal capability comes back (recovery_or_reentry_policy — see Staged Capability Restore).

Instantiates: Safe Mode Operation — Diagnostic Mode is the variant that preserves visibility for repair while blocking action.
Sibling mechanisms: Limited Service Mode · Quarantine Mode · Read-Only Mode · Maintenance Mode · Manual Supervision Mode · Limp-Home Mode · Feature-Flag Disablement · Privilege Scope Restriction · Safe-Mode Banner or Indicator · Staged Capability Restore

Notes¶

Diagnostic Mode is where a fault is understood; it says nothing about how normal service comes back. Once the cause is found, the handoff to repair and staged return belongs to Maintenance Mode and Staged Capability Restore. Keeping "look at it" and "turn it back on" as separate modes is what stops a technician's inspection session from silently becoming live production with the guards still off.

References¶

[1] Many safety-critical devices ship a built-in self-test (BIST / power-on self-test) precisely so the system can exercise and report on its own internals without operating for real — the standing engineering pattern this mechanism generalizes. ↩