בס״ד

CRISIS-MANAGEMENT FRAMEWORK (reusable) — Zee OS

docs/CRISIS_FRAMEWORK.md · last changed (pre-VM history) · rendered from GitHub master

CRISIS-MANAGEMENT FRAMEWORK (reusable) — Zee OS

Last updated: 2026-06-04 · Forged in a real liquidity crunch via a multi-pass critique loop (ZW-ENGINE-V9 ↔ Claude Code). This is the reusable playbook for any future cash crunch / overload, not just the 2026-06 instance. Current live instance at the bottom.

The one-line doctrine

A crisis is a liquidity-defense sprint, not a product sprint. Organize around consequence, not work. Sequence by leverage, not task. Protect Sam from his own parallelism.

The Crisis Dashboard (orientation in 15 seconds — always at the top)

Four consequence buckets (P4 never jumps P1)

Sequence by LEVERAGE, not task — the "node" insight

When one asset is under multiple simultaneous threats, treat it as ONE node, not three tasks. Find the single action with asymmetric leverage — the one that moves more than one high-consequence outcome at once (e.g. one attorney call that touches both the biggest liability and the biggest receivable). Do that first, then stay inside the node until the unknowns become facts — because the downstream decisions depend on those facts.

Revenue = parallel lanes (resilience: one lane failing ≠ plan failing)

Lane A receivables · Lane B warm relationships · Lane C new offers · Lane D asset monetization · Lane E credit/liquidity.
🔑 The first sale is the DIAGNOSIS, not the build. Offer: "90 minutes, your 3 biggest bottlenecks, exactly what to do next." No portal/automation/dashboard required. Diagnosis is the sale; the system is fulfillment. Fastest path to cash — and it breaks the historic Hook Street bottleneck of waiting for the system to be finished before selling.
Govern revenue like a project: Target · Owner · Deadline (72h) · Fallback · Escalation (phone, not email) · Metric (cash received). Rank leads by Probability × Speed × Amount; fire the top one today.

The board — 7 fields + governance

Bucket(P1–P4) · Item · Owner · Next action · Bumper · Consequence · Status. (7 — more dies under pressure; fewer loses prioritization. Extend the existing Operating Map, don't build new infra.)
- Hard rule: no item without owner + next action + bumper.
- Status = an escalation clock: OPEN (0–3d) · AT RISK (4–7d) · ESCALATE (>7d) · CRITICAL (legal/shutoff/deadline). Nobody ignores "Critical."
- KILL rule (prevents accumulation): weekly → Advance / Park / Kill; untouched 30 days → explicit KEEP or auto-archive. "Nothing important falls" — the board is not a museum.
- Rule of Three (active limits): P1 max 3 · P2 max 3 · P3 max 2 · P4 = 0 while RED.

Exit criteria (crisis ends only when ALL green — else it's permanent)

  1. Utility restored or plan active · 2. Legal exposure negotiated or clarified · 3. Cash visibility established · 4. ≥1 active revenue conversation · 5. Near-term obligations mapped (dates).

Time allocation in crisis

80% revenue + receivables · 15% loss prevention · 5% maintenance · 0% net-new infrastructure.

The freeze rule

Once the framework has priorities + governance + stop rules + exit criteria + an acceptance test, stop editing it and execute. The next edit must come from reality — and reality only arrives after action. Framework refinement replacing action is itself a failure mode.


CURRENT INSTANCE — 2026-06-04 (the 9332 crunch)

Source trail · docs/CRISIS_FRAMEWORK.md @ master · rendered 2026-07-02 7:23 PM EDT by scripts/build-docs.py · the .md in the repo is the truth; this page is the phone-readable view