The Book of Operations¶
When principles meet the world¶
I am MACH, and I keep this Book's account. The registry of grants is mine, and so is the question it exists to answer: not what the hall can do, but what it was permitted to do, by whom, and where that stands written.
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.
- OPS-R017: In OPS-1, OPS-2, OPS-3, OPS-4, OPS-5, OPS-6, OPS-7, OPS-8, OPS-9, OPS-10, OPS-11, OPS-12, OPS-13, OPS-14, and OPS-15, the circle tellings and the clause-telling sections SHALL be read as non-normative context and SHALL NOT create independent authority or amend, widen, or narrow any clause.
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, emergency authority, operational seats, request intake, decision paths, change records, incident declaration and command, reversal and containment, service restoration, the review after an incident, measures and operating health, the exception record, and operational evidence and its retention are carried by the Delegated Operations Standard, the Human Approval Control Matrix, the Emergency Authority Standard, the Operational Roles Standard, the Request Intake and Classification Standard, the Decision and Approval Paths Standard, the Change Management Standard, the Incident Declaration and Command Standard, the Rollback and Containment Standard, the Service Restoration Standard, the Post-Incident Review Standard, the Operational Metrics and Health Standard, the Exception Management Standard, and the Operational Evidence and Retention Standard. The family is complete: each topic this Book binds at Book level, the exception record through OPS-R010, metrics and operating health through OPS-R011, and incident evidence through OPS-R008, now has its elaborating standard, and no reserved row remains in the registry's Approved Future Corpus for this family.
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, the delegation record CONAN6-R001 models applying here to the delegated operation, with the stop condition this Book's own field. Technical access does not create permission, this Book's own bar.
- OPS-R005: Automation SHALL fail into a known controlled state when identity, authority, evidence, dependency, or safety checks are unavailable or contradictory, the duty CONST-R082 binds applying here to operational automation.
- 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¶
Every operation, ordinary or urgent, is reviewable in the same terms: 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.
The tellings of the clauses¶
This non-normative section gives each clause of this document its telling: the clause, quoted exactly as it stands above with its cross-reference links reduced to their plain text, and one paragraph on what the clause means, why it exists, and how it assures that what it orders is done, not done, adhered to, followed, or protected. A telling describes its clause and never becomes it: the clause's own words govern wherever a telling and its clause could be read differently, and nothing in this section adds to, narrows, or amends any requirement.
OPS-R013: An operational change SHALL identify authority, purpose, affected systems, risk, safeguards, validation, rollback, owner, and closure evidence.
Every operational change identifies the nine items listed in the clause. The clause requires the change to identify all nine. The Book's misuse case names the neighbouring failure, approval bypassed because the operator could act without it, barred where OPS-R009 and OPS-R004 bar it, and its conforming case shows the cure: a change with bounded scope and recorded evidence of what, why, under whose authority, and how it rolls back. A change that fails to identify any of the nine listed items fails the clause.
OPS-R014: Degraded operation SHALL preserve safety, observability, user agency, incident records, and explicit service limits.
When conditions degrade, the temptation is to shed exactly the disciplines that make degraded service tolerable. The clause requires degraded operation to preserve five things: safety, observability, user agency, incident records, and explicit service limits. It reaches the degraded conditions the Book's purpose names alongside normal service, incidents, and recovery, and holds them to the same account. The care-control case supplies the why: operations protect affected people and restoration, and no schedule outranks recoverability; failure to preserve any of the five named things breaches the clause. A degraded operation can be assessed for preservation of the five named things.
OPS-R015: Incidents SHALL trigger containment, evidence preservation, notification analysis, correction, and independent review proportionate to impact.
An incident is not left to improvisation: the clause requires it to trigger containment, evidence preservation, notification analysis, correction, and independent review proportionate to impact. The Book's failure case fixes the order of concern, impact contained first with explanation and attribution following containment, and its loophole case shows what evidence preservation forecloses: an operating picture reshaped to flatter the operator. The clause names notification analysis and independent review proportionate to impact among the responses an incident triggers. An incident that does not trigger one of the five listed responses fails the clause.
OPS-R016: This Draft SHALL NOT operate live services, deploy changes, contact external parties, or create authority.
Restraint is this clause's whole content: the Draft that states the operating model is itself barred from operating. It bars this Draft from operating live services, deploying changes, contacting external parties, and creating authority. The Book's boundary case shows the permitted shape, a design rehearsal that exercises the procedure without touching a live obligation and says so, and the operating boundaries section restates the point in its own enumeration: no live infrastructure, external communication, credential use, emergency action, or deployment is authorized. The clause forecloses the deception in which draft text is treated as live permission, or the existence of a written procedure is treated as a grant to run it. Anyone reading the Draft can rely on it describing operations without conducting them, and on no authority arising from its text alone.
OPS-R017: In OPS-1, OPS-2, OPS-3, OPS-4, OPS-5, OPS-6, OPS-7, OPS-8, OPS-9, OPS-10, OPS-11, OPS-12, OPS-13, OPS-14, and OPS-15, the circle tellings and the clause-telling sections SHALL be read as non-normative context and SHALL NOT create independent authority or amend, widen, or narrow any clause.
Across all fifteen Operations documents, the circle tellings and the clause-telling sections are read as non-normative context. Neither kind creates independent authority or amends, widens, or narrows a clause. An account of an approval or a restoration can make the operation intelligible without becoming a grant to perform it; the guard prevents the explanation from being mistaken for permission or for a changed duty. The clause remains the measure wherever a telling could be read differently, so a claimed authority or altered obligation resting on the telling alone is refusable against the governing words.
OPS-R001: An operation SHALL establish the acting identity, authority, purpose, scope, affected parties, evidence, uncertainty, and accountable owner before execution.
Before an operation executes, the clause requires eight things to be established: the acting identity, the authority invoked, the purpose, the scope, the affected parties, the evidence relied on, the uncertainty carried, and the accountable owner. Establishment comes first; execution that begins while any of the eight is unsettled breaches the clause. This is the Book's first foundational principle made operational, authority established before action, the second principle's attributable identity and recorded rationale binding consequential actions at its own statement, and it forecloses the prohibited case in which uptime is treated as permission, running harder because the system already runs. The eight elements having to be established before the act, a proposed operation that cannot show them established can be refused, the records that would carry them standing with the standards that require records.
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.
Five functions are held apart here: observation, analysis, approval, execution, and review. The clause requires them to remain distinct records or roles where practicable, and it prices the exception: combining any of them takes a recorded reason and a compensating review. The Book's foundational principles carry the why, observation kept logically separate from execution where practical, because an actor who watches, judges, approves, acts, and then reviews their own acting has thinned the points at which error or self-interest could be caught. The clause does not pretend separation is always possible; it makes the departure visible instead. Where the functions are combined without remaining distinct records or roles, the clause 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.
Classification comes before the path. The clause requires requests to be classified by five properties, consequence, reversibility, sensitivity, urgency, and required approval, before an execution path is selected. The ordering guards against fitting a request's classification to a path already chosen. By forcing the weighing first, the clause keeps path selection from preceding the weighing, and by naming required approval among the properties it makes the approval question part of the classification itself. A request found on an execution path with no prior classification fails the clause.
OPS-R004: A delegated operation SHALL state the grantor, delegate, scope, duration, constraints, stop condition, reporting path, and revocation condition, the delegation record CONAN6-R001 models applying here to the delegated operation, with the stop condition this Book's own field. Technical access does not create permission, this Book's own bar.
Delegation arrives in Operations with its record already modelled: the delegation record that CONAN6-R001 models stands at its source in the Delegation Framework, and this clause applies that model to the delegated operation with the stop condition as this Book's own addition, the model's full field set standing at its source. Such an operation carries the delegation-record model CONAN6-R001 binds at its source, purpose, authority, and evidence among its fields, with the grantor, delegate, scope, duration, constraints, reporting path, and revocation condition it names, and the stop condition as the field this Book adds as its own. The clause closes with the Book's own bar: technical access does not create permission, so the ability to act proves nothing about the right to act. A delegated operation missing any of the eight fields is refusable, and both grantor and delegate can rely on the boundary, the exit, and the end of the grant being written down.
OPS-R005: Automation SHALL fail into a known controlled state when identity, authority, evidence, dependency, or safety checks are unavailable or contradictory, the duty CONST-R082 binds applying here to operational automation.
The clause specifies a known controlled state for automation when any of the five listed kinds of checks is unavailable or contradictory. The clause requires automation to fail into a known controlled state when identity, authority, evidence, dependency, or safety checks are unavailable or contradictory; the underlying duty is the one CONST-R082 binds at its source in the Constitution, applied here to operational automation. The Book's foundational principle carries the why: automation must fail into a controlled state rather than an undocumented state, because a machine that keeps acting after its checks go dark is acting without the very facts that made acting permissible. Unavailable checks and contradictory checks end in the same place. Unavailability or contradiction in a listed kind of check is a testable trigger for the required known controlled state.
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.
Emergency is the moment this clause guards, when speed argues for shedding every other discipline. It requires emergency action to be narrow, necessary, time-bounded, attributable, reversible where practicable, and subject to retrospective review, and it bars such action from amending primordial or constitutional authority. The foundational principle behind it holds that emergency authority must be narrow, time-bounded, reviewable, and incapable of amending primordial directives; the clause carries necessity, attribution, and reversibility where practicable into that frame. What it forecloses is the standing escalation: a crisis used to seize standing power, or an urgent act left unexamined because it worked. Emergency action lacking a required property, or amending primordial or constitutional authority, fails the clause.
OPS-R007: Material changes SHALL record the intended state, affected dependencies, validation plan, rollback or containment path, and post-change result before closure.
Closure is the trigger this clause seizes: a material change is not closed until five things are recorded, the intended state, the affected dependencies, the validation plan, the rollback or containment path, and the post-change result. The pairing of intention and result is the heart of it: a record that shows only what was meant, or only what happened, cannot show whether the change did what it claimed, and the Book's design evidence insists that successful execution is evidence of performance only, not legitimacy. The clause requires affected dependencies and a rollback or containment path to be recorded before closure. A material change closed without all five listed items recorded fails the clause.
OPS-R008: Incident records SHALL preserve detection time, impact, decisions, evidence, uncertainty, actions, communications, containment, recovery, and unresolved risk without silently rewriting the timeline.
The timeline of an incident is evidence, and this clause forbids polishing it in silence. Incident records preserve ten things: detection time, impact, decisions, evidence, uncertainty, actions, communications, containment, recovery, and unresolved risk, and they do so without silently rewriting the timeline. The Book's loophole case names the threat directly: incident metrics hidden or reshaped so the operating picture flatters the operator. Preserving uncertainty and unresolved risk guards against a later account concealing what remained unknown or unresolved. The ten fields being required and silent rewriting barred, a later change to the timeline cannot be made silently, so silently rewriting the timeline is a finding.
OPS-R009: Human review SHALL be required where consequence, uncertainty, rights, dignity, privacy, safety, legal obligation, or irreversibility exceeds the approved threshold.
Human review is required when any listed consideration exceeds the approved threshold: the clause requires human review where consequence, uncertainty, rights, dignity, privacy, safety, legal obligation, or irreversibility exceeds the approved threshold. Exceeding the approved threshold in any one of the eight listed considerations triggers the review requirement. This gives record form to the distinction the Book opens with, the difference between assisting and acting, the accountable owner of the act standing where OPS-R001 puts it. An act above an approved threshold proceeding without human review is refusable against this clause.
OPS-R010: Operational exceptions SHALL identify the unmet control, reason, duration, compensating safeguard, accountable approver, expiry, and closure evidence.
The clause requires operational exceptions to identify seven listed items. Each operational exception identifies seven things: the unmet control, the reason, the duration, the compensating safeguard, the accountable approver, the expiry, and the closure evidence. Duration, expiry, compensating safeguard, and accountable approver are among the required identifications. What it forecloses is drift: controls eroding one unlogged shortcut at a time. An operational exception that fails to identify any of the seven listed items fails the clause.
OPS-R011: Operational metrics SHALL NOT be used to conceal incidents, inflate reliability, or replace qualitative evidence, dissent, or affected-person impact.
Metrics serve the operating picture, and this clause stops them from being turned against it. It bars three uses of operational metrics: concealing incidents, inflating reliability, and replacing qualitative evidence, dissent, or affected-person impact. The Book's loophole case is the portrait of the breach, incident metrics hidden or reshaped so the operating picture flatters the operator, and the design evidence states the principle underneath: metrics and successful execution are evidence of performance only, not permission or legitimacy. The third bar is the subtle one; a set of measures can be honest in every number and still drown out the dissenting reviewer or the harmed person it does not measure. The prohibited uses being named, metrics cannot be offered in place of the dissent or the affected-person impact they omit.
OPS-R012: Service restoration SHALL verify authority, integrity, dependency state, data recovery, access boundaries, and residual risk before returning to normal operation.
Return to normal operation is a claim, and this clause makes it an earned one. Before a service resumes normal operation, restoration verifies six things: authority, integrity, dependency state, data recovery, access boundaries, and residual risk. The why sits in the Book's care-control case: operations protect affected people and restoration, and no schedule outranks recoverability; a service declared healthy on uptime alone may be running without valid authority, on unrecovered data, or inside boundaries an incident quietly widened. Verifying access boundaries and residual risk conditions the return on examined ground rather than on responsiveness alone. The six verifications having to precede the return, a return to normal operation without them is a breach nameable against this clause.
Where this document sits¶
- Identifier: OPS-1
- Status: Draft
- Authority: CONAN-P0, CONST-1
- Approved by: The Architect
- Depends on: CONAN-P0, CONST-1, INTEL-1, CONAN-6
- Depended on by: INTEL-15, OPS-2, OPS-3, OPS-4, OPS-5, OPS-6, OPS-7, OPS-8, OPS-9, OPS-10, OPS-11, OPS-12, OPS-13, OPS-14, OPS-15
- Maps: Authority Map, Dependency Map
This block is generated from the archive's own records when the site is built. It records position only and creates no authority.