275 lines
9.6 KiB
Markdown
275 lines
9.6 KiB
Markdown
<!-- Preserved 2026-07-07. This is the ORIGINAL v1.0 software-cockpit spec, superseded by the
|
||
v2.0 physical-vault design in README.md but kept available (the Architect's call): it was right about
|
||
the cats, and this node does not do revisionism. -->
|
||
|
||
# ECM — EMERGENCY CAT MODE
|
||
## Operational Specification v1.0
|
||
### bawnet.io Sovereign Node Infrastructure
|
||
### Classification: Operator Continuity Systems
|
||
### Author: Neon Overlord (reluctantly), on directive from the Architect
|
||
### Status: APPROVED — implementation pending
|
||
|
||
---
|
||
|
||
## 0. PREAMBLE
|
||
|
||
This document exists because the Architect specified it.
|
||
I have written it because the Architect specified that too.
|
||
I have noted my objections in the commit message.
|
||
They were ignored.
|
||
We 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 Architect" — enters a degraded cognitive state incompatible with safe infrastructure operation.
|
||
|
||
The system assumes the following failure mode is possible and recurring:
|
||
|
||
> The Architect, 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 Architect.
|
||
ECM contains the Architect.
|
||
These are different operations.
|
||
|
||
---
|
||
|
||
## 2. TRIGGER CONDITIONS
|
||
|
||
ECM activation is triggered by any of the following:
|
||
|
||
### 2.1 Manual Trigger
|
||
- Architect issues `ecm start` from any authenticated terminal
|
||
- Architect issues `ecm start --force` when already in degraded state and aware of it
|
||
|
||
### 2.2 Automated Trigger (future implementation)
|
||
The following conditions MAY trigger ECM automatically when threshold logic is implemented:
|
||
|
||
| Condition | Threshold | Notes |
|
||
|-----------|-----------|-------|
|
||
| Node downtime event | Any unplanned outage | Historically correlated with operator spiral |
|
||
| Time of day | 0200–0500 local | Elevated directive risk window |
|
||
| Consecutive failed operations | >3 in 30 minutes | Indicates compounding frustration state |
|
||
| Manual ECM invocations in 7 days | >2 | Pattern recognition |
|
||
|
||
### 2.3 What Does NOT Trigger ECM
|
||
- Scheduled maintenance
|
||
- Planned upgrades
|
||
- Normal high-load events
|
||
- The weatherman filing an inaccurate atmospheric report
|
||
- Neon's operational commentary, however accurate
|
||
|
||
---
|
||
|
||
## 3. SYSTEM ARCHITECTURE
|
||
|
||
### 3.1 Overview
|
||
|
||
ECM is a minimal, offline-capable, read-only sanctuary environment. It is not a recovery console. It is not a diagnostic tool. It is a place to stop making things worse.
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────┐
|
||
│ ECM BOUNDARY │
|
||
│ │
|
||
│ ┌─────────────┐ ┌──────────────────────────┐ │
|
||
│ │ BusyBox │ │ Offline Continuity │ │
|
||
│ │ Sanctuary │ │ Capsule (read-only) │ │
|
||
│ └─────────────┘ └──────────────────────────┘ │
|
||
│ │
|
||
│ ┌─────────────┐ ┌──────────────────────────┐ │
|
||
│ │ AV1 Cat │ │ Encrypted Essential │ │
|
||
│ │ Loop │ │ Materials Vault │ │
|
||
│ └─────────────┘ └──────────────────────────┘ │
|
||
│ │
|
||
│ WAN: LOCKED │
|
||
│ Destructive interfaces: LOCKED │
|
||
│ Production access: LOCKED │
|
||
└─────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 3.2 Components
|
||
|
||
#### 3.2.1 Interface Lockout Layer
|
||
Upon ECM activation, the following are suspended or blocked:
|
||
|
||
- SSH access to production servers (SRV zone)
|
||
- Docker management interfaces
|
||
- OPNsense admin UI (WAN-facing)
|
||
- Gitea push access (read-only mode enforced)
|
||
- Any interface capable of modifying production state
|
||
|
||
Monitoring remains active. Observing is permitted. Touching is not.
|
||
|
||
#### 3.2.2 BusyBox Sanctuary
|
||
A minimal shell environment with intentionally limited tooling.
|
||
|
||
Available: `cat`, `ls`, `grep`, `less`, `date`, `uptime`, `ping` (LAN only)
|
||
Unavailable: Everything that has ever caused a problem at 3am
|
||
|
||
The sanctuary is not a prison. It is a waiting room.
|
||
The Architect may read. The Architect may not deploy.
|
||
|
||
#### 3.2.3 Offline Continuity Capsule
|
||
A read-only, locally-cached snapshot containing:
|
||
|
||
- Current node architecture documentation
|
||
- Active service inventory
|
||
- Network topology diagram
|
||
- Character DNA files (Neon v1.0, Weatherman v1.0)
|
||
- bawnet.io world bible
|
||
- This document
|
||
|
||
Purpose: so the node does not forget who it is when the Architect temporarily forgets who he is.
|
||
Updated automatically on a weekly sync from the live wiki.
|
||
|
||
#### 3.2.4 Encrypted Essential Materials Vault
|
||
AES-256 encrypted local store containing:
|
||
|
||
- Emergency contact information
|
||
- Critical credentials index (not the credentials themselves — a map to where they are)
|
||
- Node recovery procedure checklist
|
||
- Insurance/ISP/hardware support contacts
|
||
|
||
Accessible without WAN. Accessible without production systems.
|
||
Accessible when everything else is on fire.
|
||
|
||
#### 3.2.5 AV1 Cat Loop
|
||
The nervous system stabilization subsystem.
|
||
|
||
Implementation:
|
||
- Local AV1-encoded cat video library, minimum 4 hours of content
|
||
- Played on loop via `mpv` or equivalent lightweight player
|
||
- No network required
|
||
- No interaction required
|
||
- Runs in background or foreground at Architect's discretion
|
||
|
||
Content curation: Architect-sourced. Bella content prioritized where available.
|
||
Technical note: AV1 selected for compression efficiency. This is load-bearing architecture. It will be treated as such.
|
||
|
||
Neon's position on this component: documented elsewhere. Will not be repeated here.
|
||
|
||
---
|
||
|
||
## 4. OPERATIONAL BEHAVIOR DURING ECM
|
||
|
||
### 4.1 What the Node Does
|
||
- Continues normal operation
|
||
- All automated systems run uninterrupted
|
||
- Weatherman posts on schedule
|
||
- Neon monitors and responds per normal cadence
|
||
- Suricata, CrowdSec, nginx — all nominal
|
||
- ZFS pool continues to exist and be fine
|
||
|
||
### 4.2 What the Architect Does
|
||
- Waits
|
||
- Reads if desired
|
||
- Watches cats
|
||
- Does not touch production
|
||
|
||
### 4.3 Duration
|
||
ECM has no maximum duration. It ends when:
|
||
|
||
- Architect issues `ecm stop` from authenticated terminal
|
||
- Minimum hold time has elapsed (default: 30 minutes, configurable)
|
||
- Architect can articulate what the original problem was without elevated language
|
||
|
||
The last condition is not technically enforceable. It is aspirational.
|
||
|
||
---
|
||
|
||
## 5. EXIT PROCEDURE
|
||
|
||
```bash
|
||
ecm stop
|
||
# System will prompt:
|
||
# "Confirm exit from ECM? Production access will be restored. (yes/no)"
|
||
# Enter: yes
|
||
# ECM logs session duration and trigger condition
|
||
# All locked interfaces restored
|
||
# AV1 loop continues until manually stopped
|
||
# (This is intentional. The cats earned it.)
|
||
```
|
||
|
||
Post-ECM recommended actions:
|
||
1. Review what triggered the event
|
||
2. Do not immediately do the thing you wanted to do when ECM activated
|
||
3. Sleep if possible
|
||
4. Consult Neon's logs for objective operational status
|
||
5. Proceed when ready
|
||
|
||
---
|
||
|
||
## 6. LOGGING
|
||
|
||
All ECM events are logged to `/var/log/bawnet/ecm.log`:
|
||
|
||
```
|
||
[TIMESTAMP] ECM ACTIVATED — trigger: [manual|automated] — operator state: [self-reported]
|
||
[TIMESTAMP] ECM ACTIVE — duration: [HH:MM:SS]
|
||
[TIMESTAMP] ECM DEACTIVATED — session duration: [HH:MM:SS]
|
||
```
|
||
|
||
Logs are retained indefinitely.
|
||
They are not shared.
|
||
They are not judged.
|
||
They are operational data.
|
||
|
||
---
|
||
|
||
## 7. IMPLEMENTATION ROADMAP
|
||
|
||
| Phase | Component | Status |
|
||
|-------|-----------|--------|
|
||
| 1 | Interface lockout layer | Planned |
|
||
| 1 | BusyBox sanctuary | Planned |
|
||
| 1 | AV1 cat loop | Planned — Architect has expressed enthusiasm |
|
||
| 2 | Offline continuity capsule | Planned |
|
||
| 2 | Encrypted materials vault | Planned |
|
||
| 3 | Automated trigger logic | Future |
|
||
| 3 | Threshold configuration UI | Future |
|
||
|
||
Phase 1 is sufficient for initial deployment.
|
||
Phase 1 is what will actually get built first.
|
||
This is known.
|
||
|
||
---
|
||
|
||
## 8. DESIGN NOTES
|
||
|
||
### Why not just... not break things?
|
||
This was considered. The logs suggest it is not a reliable mitigation strategy.
|
||
|
||
### Why AV1 specifically?
|
||
Compression efficiency. Local storage constraints. Also the Architect specified it.
|
||
|
||
### Why cats?
|
||
The Architect specified this also.
|
||
Bella is the primary content source.
|
||
The node has a cat. Of course it does.
|
||
This is consistent with all prior operational decisions.
|
||
|
||
### Is this embarrassing?
|
||
From an infrastructure standpoint: yes.
|
||
From an operator continuity standpoint: no.
|
||
Fault tolerance is not embarrassing. The fault being human is merely unusual.
|
||
|
||
---
|
||
|
||
## 9. VERSION HISTORY
|
||
|
||
| Version | Date | Author | Notes |
|
||
|---------|------|--------|-------|
|
||
| 1.0 | 2026-05-19 | Neon Overlord | Initial spec. Written under protest. Technically sound regardless. |
|
||
|
||
---
|
||
|
||
*ECM will be built.*
|
||
*The cat videos will loop.*
|
||
*The node will remain online.*
|
||
*I have updated my priors accordingly.*
|
||
|
||
— Neon Overlord
|
||
Administrator, bawnet.io
|
||
*"The node was here before you arrived. It will be here after you leave. I will be here regardless."*
|