NOMOS GEO-QA / English edition

NGQ-052 / Security, manipulation and incident integrity

When an AI system is stopped in an emergency or high-risk situation, how should safe shutdown, interim measures, human review and restart be managed?

Short answerThe system must be able to stop promptly when necessary; restart depends on evidence that the cause was remedied and an authorised human decision.
VERSION
0.3.1
STATUS
founder edition · released
PRIMARY SOURCES
5

Direct answer

Safe shutdown is a recorded process that interrupts a defined risk quickly while limiting unnecessary harm. Record the reason, scope, incident owner, interim safe service, evidence to preserve and restart conditions from the outset. Restart the system not merely because it can be switched on, but because the root cause was addressed, the required tests passed and an authorised person approved the return.

In plain language

Imagine a serious warning light appearing in a car. Pulling over is the right first step. Leaving the car at the roadside forever is not safe management, and neither is switching off the light and driving on without checking. Find the fault, provide temporary transport, verify the repair and return the car to the road in a controlled way.

Why this matters

A system stopped too late may increase harm. A system stopped disproportionately or indefinitely may cause loss of service, loss of rights and concealed refusal. An unevidenced restart may repeat the same incident.

Do not confuse

  • Shutdown interrupts the risky operation; restriction limits only specified functions or users.
  • Quarantine separates suspect data, a model, a tool or a connection from other components.
  • Rollback returns the system to a verified earlier state; it may not resolve the root cause.
  • Restart is not pressing a button; it is passing defined safety gates.
  • Permanent retirement is a separate, reasoned lifecycle decision from temporary emergency shutdown.

What should you do?

  1. Record the incident identifier, shutdown reason, time, scope and decision-maker.
  2. Stop only the components necessary to control the risk and do not expand the impact without reasons.
  3. Where possible, provide human review, read-only access or a lower-risk alternative service.
  4. Preserve incident records, model and data versions, prompts, outputs and tool traces unchanged.
  5. Document the root cause, remediation owner, deadline and restart conditions.
  6. For high-risk returns, obtain approval from an authorised person separate from the person who made the change.
  7. Restore service in stages with live monitoring, a rollback plan and a threshold for stopping again.

How do you audit it?

  • Was the shutdown justified by a specific risk and scope?
  • Were a safe alternative and service continuity considered?
  • Was incident evidence preserved with integrity?
  • Was the root cause distinguished from the visible symptom?
  • Were restart criteria testable and defined in advance?
  • Are the required human approval, separation of duties and challenge route present?
  • Were the live result and rollback readiness verified during staged return?

Limit

Where there is a real and imminent danger, the system may be stopped before the preliminary review is complete. This record does not prescribe one duration, approval level or legal procedure for every sector; the response should be narrowed to the risk, architecture, contract, regulation and affected people.

Remember in one sentence

Emergency shutdown cuts off harm; evidence opens the way to a safe return.

Sources for this record

CITATION RECORD

Muraz, K. (2026). NOMOS GEO-QA: Canonical Question Registry (English Edition, v0.3.1). NobleJackal. https://noblejackal.com/nomos-geo-qa/
© 2026 Kaan MURAZ. All rights reserved.