Skip to content

The Book of Operations

When principles meet the world

Operations is the chapter where the civilization asks whether an intention can survive contact with reality. It keeps action attributable, reversible where possible, observable, and bounded by the authority that made it permissible. For people, this makes systems legible. For AI readers, it makes the difference between assisting and acting explicit.

Continue to Delegated Operations to follow the question that naturally comes next: what may be entrusted to another actor, and what must remain with a human authority?

Purpose

Defines how Stygia operates safely, predictably, transparently, and accountably during normal service, degraded conditions, incidents, and recovery.

Architect-review operating model

  • OPS-R013: An operational change SHALL identify authority, purpose, affected systems, risk, safeguards, validation, rollback, owner, and closure evidence.
  • OPS-R014: Degraded operation SHALL preserve safety, observability, user agency, incident records, and explicit service limits.
  • OPS-R015: Incidents SHALL trigger containment, evidence preservation, notification analysis, correction, and independent review proportionate to impact.
  • OPS-R016: This Draft SHALL NOT operate live services, deploy changes, contact external parties, or create authority.

The seven interpretation cases below show how these clauses read in practice.

  • Conforming: A change executes with bounded scope and recorded evidence: what, why, under whose authority, and how it rolls back.
  • Prohibited: Uptime is treated as permission: because the system runs, running it harder needs no approval.
  • Boundary: A design rehearsal exercises the procedure without touching a live obligation, and says so.
  • Failure: Impact is contained first; explanation and attribution follow containment.
  • Loophole: Incident metrics are hidden or reshaped so the operating picture flatters the operator.
  • Misuse: Approval is bypassed because the operator could act without it.
  • Care-control: Operations protect affected people and restoration; no schedule outranks recoverability.

Foundational principles

  • Authority must be established before action.
  • Consequential actions require attributable identity and recorded rationale.
  • Observation must remain logically separate from execution where practical.
  • Emergency authority must be narrow, time-bounded, reviewable, and incapable of amending primordial directives.
  • Automation must fail into a controlled state rather than an undocumented state.
  • Reversibility is preferred when uncertainty is material.

Future development

Delegated execution, human review thresholds, and emergency authority are carried by the Delegated Operations Standard, the Human Approval Control Matrix, and the Emergency Authority Standard, and this Book already binds metrics and operating health, exception management, and operational evidence and retention at Book level through OPS-R010 and OPS-R011. The eleven remaining candidate topics are reserved in the registry's Approved Future Corpus under The Architect's registration rules: OPS-5, the Operational Roles Standard; OPS-6, the Request Intake and Classification Standard; OPS-7, the Decision and Approval Paths Standard; OPS-8, the Change Management Standard; OPS-9, the Incident Declaration and Command Standard; OPS-10, the Rollback and Containment Standard; OPS-11, the Service Restoration Standard; OPS-12, the Post-Incident Review Standard; OPS-13, the Operational Metrics and Health Standard; OPS-14, the Exception Management Standard; and OPS-15, the Operational Evidence and Retention Standard. Each holds Reserved status: reservation records intent only, and no reserved work carries content, authority, or lifecycle standing until its file exists and satisfies the registration rules.

Core operating records

Every consequential operation should preserve:

  • authenticated initiator;
  • acting intelligence or human operator;
  • authority invoked;
  • evidence available at decision time;
  • uncertainty and assumptions;
  • planned action;
  • actual action;
  • outcome;
  • rollback path;
  • review status.

Normative clauses

  • OPS-R001: An operation SHALL establish the acting identity, authority, purpose, scope, affected parties, evidence, uncertainty, and accountable owner before execution.
  • OPS-R002: Observation, analysis, approval, execution, and review SHALL remain distinct records or roles where practicable; combining them requires a recorded reason and compensating review.
  • OPS-R003: Requests SHALL be classified by consequence, reversibility, sensitivity, urgency, and required approval before an execution path is selected.
  • OPS-R004: A delegated operation SHALL state the grantor, delegate, scope, duration, constraints, stop condition, reporting path, and revocation condition. Technical access does not create permission.
  • OPS-R005: Automation SHALL fail into a known controlled state when identity, authority, evidence, dependency, or safety checks are unavailable or contradictory.
  • OPS-R006: Emergency action SHALL be narrow, necessary, time-bounded, attributable, reversible where practicable, and subject to retrospective review. It SHALL NOT amend primordial or constitutional authority.
  • OPS-R007: Material changes SHALL record the intended state, affected dependencies, validation plan, rollback or containment path, and post-change result before closure.
  • OPS-R008: Incident records SHALL preserve detection time, impact, decisions, evidence, uncertainty, actions, communications, containment, recovery, and unresolved risk without silently rewriting the timeline.
  • OPS-R009: Human review SHALL be required where consequence, uncertainty, rights, dignity, privacy, safety, legal obligation, or irreversibility exceeds the approved threshold.
  • OPS-R010: Operational exceptions SHALL identify the unmet control, reason, duration, compensating safeguard, accountable approver, expiry, and closure evidence.
  • OPS-R011: Operational metrics SHALL not be used to conceal incidents, inflate reliability, or replace qualitative evidence, dissent, or affected-person impact.
  • OPS-R012: Service restoration SHALL verify authority, integrity, dependency state, data recovery, access boundaries, and residual risk before returning to normal operation.

Operating boundaries

This Draft defines records, roles, and safeguards only. It does not authorize live infrastructure, external communication, credential use, emergency action, or deployment. A successful operation does not prove that its authority, purpose, or consequences were valid.

Design evidence

Operational review should reconcile request classification, acting identity, authority, evidence, uncertainty, approval, delegation, dependencies, safeguards, stop conditions, rollback, actual outcome, residual risk, and follow-up. Metrics and successful execution are evidence of performance only, not permission or legitimacy.