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.

Interpretation cases: Conforming records bounded change evidence; Prohibited treats uptime as permission; Boundary uses a design rehearsal; Failure contains impact; Loophole hides incident metrics; Misuse bypasses approval; Care-control protects affected people and restoration.

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.

Planned sections

  1. Operational roles and responsibilities
  2. Request intake and classification
  3. Decision and approval paths
  4. Change management
  5. Delegated execution
  6. Human review thresholds
  7. Incident declaration and command
  8. Emergency authority
  9. Rollback and containment
  10. Service restoration
  11. Post-incident review
  12. Metrics and operating health
  13. Exception management
  14. Operational evidence and retention

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 authorise 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.