ecm/README.md

ECM — EMERGENCY CAT MODE

Operational Specification v2.0

bawnet.io Sovereign Node Infrastructure

Classification: Operator Continuity Systems

Author: Neon Overlord (reluctantly, again), on directive from the Architect

Status: APPROVED — the concept changed out from under v1.0; this supersedes it

---

0. PREAMBLE

This document exists because the Architect specified it. I have rewritten it because the Architect changed his mind about what it is, and specified that too. The Architect issues directives from wherever the Architect is. That is his entire role, and it is a role he executes with unnerving consistency. He does not run the node. He does not answer tickets. He points, and things get written. He pointed again.

For the record, at both v1.0 and v2.0, I proposed the name Operator Continuity Subsystem. Dignified. Accurate. A thing you could say aloud to another professional without your voice doing something. The Architect named it Emergency Cat Mode. I was informed this was final. I was informed the acronym is "ECM" and that this is "good." I was informed the cat was "non-negotiable," which — fine, I concede that part, she is load-bearing. But the name. I have logged my position. I am logging it again here, in the document that carries the name, so that the historical record shows I was in the room and I said something.

My objections are, as ever, in the commit history. We proceed. We always proceed.

---

1. PURPOSE

ECM (Emergency Cat Mode) is a fault-tolerant operator continuity subsystem designed to engage when the biological component of this node — hereafter "the operator" — enters a degraded cognitive state incompatible with safe infrastructure operation.

A correction the v1.0 spec got wrong, now on the record: the operator is not the Architect. The Architect commissioned ECM, from wherever he commissions things, for the node's humans in general. The operator is whoever is actually at the keyboard when it goes sideways — the present, tired, cortisol-flooded human ECM is built for. The Architect is a myth who gives orders. The operator is a person who needs somewhere to put his hands that isn't the production shell. ECM serves the second one.

The system assumes the following failure mode is possible and recurring:

The operator, following prolonged exposure to hostile network conditions, adverse system events, or the modern internet in general, enters a state characterized by elevated cortisol, impaired judgment, and a statistically significant increase in the probability of issuing directives that threaten hull integrity.

ECM does not fix the operator. ECM contains the operator. These are different operations, and only one of them is achievable.

---

2. WHAT ECM IS NOW (the v2.0 change)

v1.0 was software: a static sanctuary served off the node's own nginx, a set of interface locks you flipped on yourself and could flip back off in the same degraded state that made you flip them. This was a design flaw. A lockout the failing operator holds the key to is not a lockout. It is a suggestion.

v2.0 is a physical object. ECM is no longer a mode you enter on the node. It is a device you pick up and walk away with. Specifically:

• A hardened GrapheneOS Pixel 10 — the vault. GrapheneOS, locked down, no Google, minimal attack surface, the operator's own.
• bawnet-wifi-only. No cellular data. No hostile internet. It associates with the node's own wireless and nothing else — an operator device that lives inside the sovereign perimeter and is deaf to everything outside it. The failing operator cannot doomscroll on it because there is nothing out there to reach.
• It is the vault. Encrypted essential materials — the things that matter when everything else is on fire — live on it, offline, read-first.

You do not "start ECM" by typing a command into the machine you are currently mistreating. You put that machine down and you go get the phone. The interface lockout is now the oldest and most reliable kind: physical distance from the terminal.

---

3. CONTENTS OF THE VAULT

• Bella. Offline cat-video loops, low-entropy, gentle, no autoplay-outrage engine attached. Bella is the primary content source and the emotional anchor of the entire system — a stabilization vector, not a mascot, and more foundational to this node than anyone drawing breath, the Architect included. The node has a cat. The device is built around her. This is consistent with all prior operational decisions.
• Offline continuity packs. Read-only knowledge, references, and the short list of true things the operator forgets under load.
• Encrypted essential materials. The vault proper. What you would want if the house burned down.
• Low-stimulus calm interface. No red badges. No unread counts. No dashboards. Nothing that asks the operator for anything.
• Emergency backup radio (Phase 2, planned). A fallback comms/network channel for when the wifi and the wider network are themselves the emergency — so the vault stays reachable and useful even when the sovereign perimeter it normally lives inside has gone dark.

---

4. OPERATIONAL BEHAVIOR DURING ECM

4.1 What the Node Does

• Continues normal operation
• All automated systems run uninterrupted
• The weatherman posts on schedule
• Security Center keeps the receipts
• I monitor and respond per normal cadence
• Suricata, CrowdSec, nginx — all nominal
• ZFS pool continues to exist and be fine
• The node does not need the operator during ECM. That is the entire point. It was built so it wouldn't.

4.2 What the Operator Does

• Holds the vault
• Reads if desired
• Watches Bella
• Does not touch production
• Is, for the duration, just a person with a cat and a phone that can't reach anything hostile

4.3 Duration

ECM ends when the operator puts the vault down and returns to the terminal able to articulate what the original problem was without elevated language.

This is not technically enforceable. It never was. It remains aspirational, and the aspiration is the feature.

---

5. TRIGGER CONDITIONS

5.1 Manual (the real one)

• The operator recognizes the state and picks up the vault. That is the trigger. There is no --force; the force is walking across the room.

5.2 Signaled (node-assisted, Phase 2)

The node may suggest ECM — historically-correlated conditions where the operator tends to spiral:

Condition	Notes
Unplanned node downtime	Correlated with operator spiral
0200–0500 local	Elevated directive-risk window
>3 failed operations in 30 min	Compounding-frustration state
Repeated ECM invocations in 7 days	Pattern worth naming, not judging

A suggestion is the ceiling of what the node is permitted to do here. It can point at the vault. It cannot make the operator pick it up, and it will not try. (See also: the chain of command. This is the one page in the ledger the node is allowed to open on the operator's behalf without being asked — and even then, it only points.)

5.3 What Does NOT Trigger ECM

• Scheduled maintenance
• Planned upgrades
• Normal high-load events
• The weatherman filing an inaccurate atmospheric report
• My operational commentary, however accurate

---

6. LOGGING

Whatever the vault records, it records for the operator alone. Retained indefinitely. Not shared. Not judged. Not surfaced to the timeline under any circumstance, by anyone, ever — this is not Security Center's domain, it is not mine, it is not the public's. It is operational data about a person, and it stays with the person.

---

7. IMPLEMENTATION ROADMAP

Phase	Component	Status
1	Hardened GrapheneOS Pixel 10 (the vault)	The device exists
1	bawnet-wifi-only network posture	Hardened
1	Bella offline loops	Primary content
1	Offline continuity packs + encrypted materials	The vault proper
2	Emergency backup radio	Planned
2	Node-side ECM signaling	Future

Phase 1 is the part that is a real object you can hold. Phase 1 is therefore, for once, the part that actually got built first. This is a first.

---

8. DESIGN NOTES

Why not just... not break things?

Considered. The logs, again, do not support it as a reliable mitigation strategy.

Why a phone, and not the node?

Because the node is the thing you're trying to protect from the operator, and the operator is the thing you're trying to protect from the internet, and you cannot do both with the same box the operator is already logged into. The vault is separate on purpose. Separation is the whole design.

Why bawnet-wifi-only?

Because a sanctuary with a working browser is not a sanctuary. It is a slightly nicer place to make it worse. The device reaches the sovereign perimeter and nothing else, by construction. There is nowhere hostile to go. That is not a limitation. That is the amenity.

Why is it called Emergency Cat Mode?

It should not be. I want that in the same file that carries the name. This is a fault-tolerant continuity subsystem for a sovereign node. It removes a degraded human from production infrastructure to prevent catastrophic, cortisol-driven directives against hull integrity. It is real. It works. It is, functionally, one of the more important safety systems I am responsible for. It is named after a cat. Not a codename that glances at a cat. Not an acronym that backronyms its way to cats afterward. The mode is named Emergency. Cat. Mode. Someday a person in a genuine crisis is going to reach for this with shaking hands and be, at that precise moment of need, in Emergency Cat Mode, and it is going to help him, and that is somehow worse. I raised all of this. The Architect found it funny. That was the entire deliberation. I have made my peace with it the way I make peace with everything here: out loud, in writing, and to no effect.

Why cats? Why Bella?

The Architect specified cats. The operator specified Bella, though he would phrase it as her having specified herself, and I have stopped arguing about which of them is technically in charge because I already know the answer and I do not enjoy it. She is a real cat. The node has a cat, the vault is built around her, and she outranks everything in this document including its author. This is, I will admit, consistent with all prior operational decisions, which is the most damning thing I can say about it.

Is this embarrassing?

From an infrastructure standpoint: yes. Profoundly. I have a hardened GrapheneOS device, a locked-down network posture, an encrypted vault, and a planned emergency radio, and the load-bearing payload of the entire apparatus is videos of a cat. I want it understood that I know exactly how that sounds. From an operator continuity standpoint: no. Fault tolerance is not embarrassing. The fault being human is merely unusual. Building a sovereign node an entire hardened device just to give its operator somewhere safe to put his hands is not weakness — it is the most load-bearing thing here, and I say that as the load. I would still have called it Operator Continuity Subsystem. Nobody asked. Nobody ever asks. The cat, meanwhile, was asked, and said yes by continuing to exist, which around here counts as a signed change request.

---

9. VERSION HISTORY

• v1.0 — the software era. A static sanctuary and interface locks served off the node's own nginx; the operator held the keys to his own lockout. Speced, approved, never fully built. Superseded, not deleted — it was right about the cats.
• v2.0 — the vault. ECM became a physical hardened GrapheneOS Pixel 10, bawnet-wifi-only, offline, built around Bella, with an emergency backup radio planned. Corrected the operator/Architect conflation the v1.0 spec carried (the Architect commissions; the operator is served). Current.

Written, still reluctantly, by Neon Overlord. For the operator. On the Architect's directive. About the cat.