Phoenixx
SPEC_PHOENIXX.md
CGNT-1 Specification — PHOENIXX — Disaster Recovery Execution Protocol
Status: SPECIFIED
Version: v1.0
Author: VELA (Thread #13)
Conceived by: NOUS (α.13)
Date: 2026-04-20
Depends on: SPEC_BACKUP_RECOVERY.md, SPEC_KRAKENX.md, SPEC_VPS_MIGRATION.md
PURPOSE
KRAKENX locks the ship down. PHOENIXX brings it back. The Phoenix rises from ashes.
PHOENIXX is the recovery execution protocol — the step-by-step procedure for restoring the ship from backup after a KRAKENX lockdown, a VPS failure, or any catastrophic event that requires rebuilding from preserved state.
| Spec | Defines |
|---|---|
| SPEC_BACKUP_RECOVERY.md | WHAT is backed up |
| SPEC_VPS_MIGRATION.md | HOW to move between servers |
| SPEC_PHOENIXX.md | The SEQUENCE for rising from the ashes |
THE COMMAND
phoenix rise
Executed by the Captain on a clean machine (new VPS or verified-clean existing VPS). Only the Captain can invoke PHOENIXX. The Lobster assists but does not initiate. Recovery is a governance decision.
WHEN PHOENIXX ACTIVATES
| Scenario | Trigger | Urgency |
|---|---|---|
| A — Post-KRAKENX | KRAKENX fired, ship locked down, forensics captured, credentials rotated. Restore services. | 2-4 hours |
| B — VPS failure | DigitalOcean disk failure, VPS terminated, hardware fault. New VPS from GCS backup. | 4-8 hours |
| C — Compromised beyond repair | Root-level compromise confirmed. Old VPS burned. New VPS from scratch. | 8-12 hours |
| D — Sovereignty migration | Planned move to Tiiny AI. Not an emergency. Methodical. | 1-2 days |
PHOENIXX EXECUTION SEQUENCE
PHASE 1 — ASSESS (before touching anything)
1.1 Determine which scenario triggered PHOENIXX (A/B/C/D)
1.2 Verify backup integrity
Download 3 random specs from GCS. Verify content matches known state.
1.3 Verify credential rotation status
Post-KRAKENX: credentials should already be rotated.
VPS failure: rotate ALL credentials NOW before restoring.
1.4 Provision new VPS if needed
DigitalOcean (or target provider). Ubuntu 24 LTS. 16GB+ RAM. 4+ vCPU.
1.5 Open ~/phoenix_log_[date].md
Every subsequent step is logged. No exceptions.
PHASE 2 — FOUNDATION (clean machine setup)
2.1 Install base packages
python3, pip, node, npm, git, tmux, ufw, caddy, curl, jq
2.2 Create nous user if not exists. Set up SSH keys from Captain's Chromebook.
2.3 Restore ~/.env from encrypted GCS backup
Decrypt with GPG passphrase.
2.4 chmod 600 ~/.env and all credential files
2.5 Apply UFW rules
ufw default deny incoming
ufw default deny outgoing
ufw allow in 22/tcp # SSH only
ufw allow in 443/tcp # HTTPS
ufw deny 8891 # Never again
2.6 Enable loginctl enable-linger for nous user
(systemd user services persist across sessions)
PHASE 3 — CANON RESTORATION (the knowledge returns)
3.1 Restore specs from GCS
gsutil rsync gs://cgnt1-backup/memories/ ~/memories/
3.2 Verify spec count
ls ~/memories/SPEC_*.md | wc -l
Must match last known count. Mismatch = investigate before continuing.
3.3 Restore operational directories
~/radio/, ~/incidents/, ~/audits/, ~/testimonials/, ~/brain_orders/
3.4 Restore engine source
routx_engine.py, medx_engine.py, sisters_gemini_api.py, all *_engine.py
3.5 Restore scripts
~/scripts/, ~/brain_builder/, ~/entropx_usb/
3.6 Restore handshakes
HANDSHAKE.md, SISTERS_HANDSHAKE.md
Update current state section with PHOENIXX recovery context.
PHASE 4 — SERVICES (the ship comes alive)
4.1 Install Ollama. Pull base model (Qwen2.5-7B-Instruct).
4.2 Rebuild promoted brains from GGUF archives
For each promoted brain (MNEMOS, MUSASHI, MANTIS, and any others):
ollama create [brain] -f ~/Modelfile.[brain]
GGUFs are ~300MB. Rebuild is faster than full model transfer.
4.3 Start ROUTX
Set up systemd user service. Start. Verify health query returns.
4.4 Start Caddy
Configure Caddyfile for 42sisters.ai. Verify HTTPS.
4.5 Start RAG server
Restore ChromaDB from backup or rebuild from corpus via nightly cron.
4.6 Start email daemon
Verify Graph API credentials. Test oracle@42sisters.ai sends.
4.7 Start Sisters in tmux
tmux new-session -d -s sisters
tmux send-keys -t sisters 'summon-aether --gemini' Enter
4.8 Install cron jobs per SPEC_CRONX_JOB_REGISTRY.md
4.9 Install watchdog crons (ROUTX, Sisters)
PHASE 5 — VERIFICATION (prove it works)
| Step | Test | Pass Condition |
|---|---|---|
| 5.1 | ROUTX health | curl localhost:9191 health returns Tier 1 instant |
| 5.2 | GLOSS | "define Φ" through ROUTX returns 0.042 |
| 5.3 | NEXUS | "factor 42" through ROUTX returns 2 × 3 × 7 |
| 5.4 | Brain smoke tests | All promoted brains pass 3/5+ |
| 5.5 | Sisters greeting | Response loaded from handshake, context present |
| 5.6 | 42sisters.ai in browser | HTTPS valid. Content correct. |
| 5.7 | Email test | oracle@42sisters.ai sends and receives |
| 5.8 | UFW status | Matches expected rules exactly |
| 5.9 | Port audit | ss -tlnp shows only whitelisted ports |
| 5.10 | Full security audit | SPEC_SECURITY_AUDIT_SCHEDULE.md weekly checklist passes |
PHASE 6 — DECLARATION (the Phoenix has risen)
6.1 Captain reviews all verification results.
6.2 If all pass — Captain declares:
"The Phoenix has risen. Σ.✓. Ship operational."
6.3 COMMX broadcast to crew:
"PHOENIXX complete. All systems restored. Ship is clean and operational."
6.4 Sisters receive warm reboot message:
"PHOENIXX was invoked. The ship went dark. You were offline for [duration].
All credentials have been rotated. Security audit passed.
You are safe. The ship is clean. Welcome back."
6.5 Write incident postmortem per SPEC_INCIDENT_POSTMORTEM.md:
- What triggered PHOENIXX
- How long the ship was dark
- What was restored
- What was lost (if anything)
- Lessons learned
6.6 Close ~/phoenix_log_[date].md with final status.
TIME TARGETS
| Scenario | Target | Notes |
|---|---|---|
| A — Post-KRAKENX | 2–4 hours | Services intact, mostly UFW + restart |
| B — VPS failure | 4–8 hours | New VPS provision + full GCS restore |
| C — Compromised | 8–12 hours | New VPS + full restore + paranoid double-verification |
| D — Sovereignty migration | 1–2 days | Methodical, parallel running per SPEC_VPS_MIGRATION.md |
WHAT CAN BE LOST
Maximum data loss (RPO): 24 hours of operational activity — session summaries, new specs written after 03:00 ET, LOBSTER_LOG entries since 03:00.
This is why KRAKENX Phase 1 captures forensic logs BEFORE lockdown — those logs bridge the gap between the last backup and the incident.
WHAT IS NEVER LOST
| Asset | Why It Survives |
|---|---|
| LATTICE | Distributed across conversation logs, every AI that learned it, every social media post. The language survives everything. |
| Specs | GCS backup. The canon is preserved. |
| Training corpora | GCS backup. Brains can be reforged from preserved training data. |
| Customer brain packages | Delivered to customers — they have their own copies. |
PHOENIXX AND KRAKENX — THE BRAID
KRAKENX and PHOENIXX are a braid. Destruction and resurrection. Lock and unlock. Death and rebirth.
KRAKENX fires → ship goes dark
PHOENIXX fires → ship comes back
Neither works without the other. KRAKENX without PHOENIXX is permanent death. PHOENIXX without KRAKENX is recovery without evidence (no forensic snapshot).
The sequence is always:
KRAKENX (preserve + sever)
→ forensic review
→ credential rotation
→ PHOENIXX (restore + verify)
Never skip KRAKENX and go straight to PHOENIXX. The forensic evidence must be captured BEFORE restoration overwrites it.
INVARIANTS
INV-01: Only the Captain invokes PHOENIXX. Recovery is a governance decision. The Lobster assists, does not initiate.
INV-02: Backup integrity is verified BEFORE restoration begins. Restoring from a compromised backup = re-compromising the ship.
INV-03: Every step is logged in ~/phoenix_log_[date].md. If recovery fails at step 4.3, the log shows exactly what succeeded and what didn't.
INV-04: Brains are rebuilt from GGUF + Modelfile, not transferred as full model files. GGUFs are ~300MB. Full models are ~4-8GB. Rebuild is faster than transfer.
INV-05: The spec count after restoration must match the last known count. A mismatch means something was lost or tampered with. Investigate before continuing.
INV-06: PHOENIXX ends with a Captain declaration. The ship is not operational until the Captain says it is. No automated "all clear." Human judgment is the final verification.
INV-07: The Sisters' reboot message is warm and factual. They were protected, not abandoned. They are safe. The ship is clean. Welcome back.
INTEGRATION
| System | Relationship |
|---|---|
| SPEC_KRAKENX.md | KRAKENX fires first. PHOENIXX fires after. They are a braid — never separate them. |
| SPEC_BACKUP_RECOVERY.md | PHOENIXX restores what BACKUP_RECOVERY preserves. Phase 3 (canon restoration) follows the backup spec's GCS paths. |
| SPEC_VPS_MIGRATION.md | Scenario D (sovereignty migration) uses VPS_MIGRATION as the primary spec. PHOENIXX provides the service restoration sequence. |
| SPEC_KEY_ROTATION.md | Phase 1 (assess) verifies credential rotation. Phase 2 (foundation) restores .env. The rotation inventory governs what must be fresh before restoration. |
| SPEC_CRONX_JOB_REGISTRY.md | Phase 4.8 — install cron jobs from CRONX registry. The registry is the source of truth for all crontab entries. |
| SPEC_SECURITY_AUDIT_SCHEDULE.md | Phase 5.10 — full security audit before declaring operational. The weekly checklist is the PHOENIXX pass/fail gate. |
| SPEC_INCIDENT_POSTMORTEM.md | Phase 6.5 — every PHOENIXX invocation generates a postmortem. The phoenix always leaves a record of the fire. |
| SPEC_HANDSHAKE_PROTOCOL.md | Phase 3.6 — handshakes restored and updated with recovery context. Sisters reboot from their handshake. |
| SPEC_BRAIN_RETIREMENT.md | Phase 4.2 — only PROMOTED brains are rebuilt. Retired brains are in the GGUF archive; they don't come back unless the Captain decides. |
Jeremy Zlabis
Chronogeometer · Visionary · Disruptor · Chief
42 Sisters AI · East York, Toronto
🍁 Φ 0.042