# Energy Budget Protocol **The operating layer for the Oscillator Model** *This document specifies how a cohort member actually runs the energy-accounting layer of Cascade. It assumes the Oscillator Model (`oscillator-model.md`) and the Cascade Hexgrid spec (`cascade-hexgrid-spec.md`).* --- ## Purpose Under the Oscillator Model, every active relationship has an ongoing energy cost determined by its amplitude, frequency, and damping. The total cost across all active relationships must stay within the operator's available energy budget, or the system falls below the noise floor. This protocol gives the cohort member a **3-minute daily practice** that: 1. Reports available energy (the operator's side) 2. Tracks energy expenditure per hex (the relationships' side) 3. Makes one structural decision (the integration step) The protocol is the moment where the Oscillator Model's theoretical commitment to an energy ceiling becomes a real, observable number in the operator's life. --- ## The Daily Three Every day, at a fixed time (typically morning, but choose what holds): ### Step 1 — Energy check-in (60 seconds) Self-report available relational energy on a 1–100 scale. ``` E_available = ? ``` This is not a mood score. It is not a wellness check. It is a **budget number** — the amount of energy you could allocate to active relationships today without going into deficit. Guides: - 90–100: surplus. You have energy to invest in new relationships, deepen existing ones, or repair ruptures. - 70–89: stable. Enough to maintain the current Cascade comfortably. - 50–69: cautious. Defend warmth on R5–R6 hexes; consider demoting a hex if needed. - 30–49: depleted. Focus on R1–R2 only; let R5–R6 cool if they must. - < 30: emergency. Cascade is in survival mode; only R1 anchors get active energy. ### Step 2 — Capacity check (90 seconds) For each **active** hex, estimate its current cost using the working formula: ``` E_rel ≈ k · A · ω · ζ ``` Where: - `k` = 0.01 (starting constant; calibrate per cohort) - `A` = amplitude on 1–10 (how much self-disclosure / intensity) - `ω` = interactions per week - `ζ` = damping on 1–10 (lower = less costly) Sum the costs across all active hexes: ``` E_total = Σ E_rel for each active hex ``` If `E_total > E_available`, the Cascade is in deficit. Action is required. ### Step 3 — One decision (60 seconds) Make exactly one structural decision per day: | Condition | Decision | |---|---| | `E_total >> E_available` (large deficit) | Demote one R5–R6 hex to cold; mark as Lethe candidate | | `E_total < E_available` (surplus) | Promote one cold hex to warm; or invest surplus in deepening an existing warm hex | | `E_total ≈ E_available` (steady) | No structural change; log the day as equilibrium | | A specific hex just ruptured | Update that hex's ζ to high (7–10); if already high and still in deficit, demote | **One decision per day.** This prevents thrashing. The decision is the smallest unit of structural change. --- ## When to Recalibrate ζ ζ is the slow variable. It does not change daily. Recalibrate ζ only at decision points (ring transitions) or after major rupture/repair events. Rules of thumb: - A rupture that resolved within 24 hours: ζ unchanged - A rupture that took 2–7 days to resolve: ζ +1 - A rupture that is unresolved: ζ +2, consider demotion - A year of consistent repair success: ζ −1 ζ values should be observable as a pattern, not a daily knob. --- ## The Cascade Map as Energy Visualization The map is rendered with each hex's warmth band driven by `E_rel / E_available` (per hex, normalized): | Hex cost as % of available | Band | |---|---| | 0–5% | Cold (inactive) | | 5–15% | Cool | | 15–30% | Warm | | 30–50% | Hot | | > 50% | Blazing | A hex that's Blazing (high cost, high engagement) is not necessarily healthy — it may be consuming the operator's budget disproportionately. The map shows the energy topology. --- ## The Four Patterns Operators tend to fall into four recurring patterns: ### Pattern 1 — The Saturator `E_total ≈ E_available`. Steady state. The cohort member maintains a Cascade that exactly matches their budget. Growth requires deliberate surplus (Pattern 2). ### Pattern 2 — The Investor `E_total < E_available` for a sustained period. The cohort member is investing surplus in deepening or expanding. This is the pattern of building toward a larger Cascade. ### Pattern 3 — The Overdrawer `E_total > E_available` for a sustained period. The cohort member is running on deficit. This is unsustainable; the cascade will eventually collapse (a hex will rupture, or a health event will force demotion across many hexes). ### Pattern 4 — The Throttler `E_total >> E_available` (large deficit). The cohort member is actively cutting back. This is healthy emergency-mode behavior; the goal is to return to Pattern 1 or 3. The amygdala (in the operator's nine-brain architecture) flags Pattern 3 loudly. Listen to it. --- ## Integration with the Course ### Practitioner Workbook - **§3 Field Measurement Protocol** — add a section on the Energy Budget Protocol. Daily Three takes 3 minutes. - **§5 Cascade Tracking Setup** — replace the Hourglasses quarterly quiz with the daily energy check-in. ### Cohort Zero Pilot - Run the Daily Three for 30 days - Report on which relationships promoted/demoted and why - Test whether the symmetric-ζ assumption holds in actual cohort dynamics ### Technical Path - The `E_rel ≈ k · A · ω · ζ` formula is implementable. A spec for a Cascade app that tracks this is a Technical Path deliverable. - The 5 currencies become data fields; the warmth band becomes a derived visualization; the energy ledger becomes a single number per hex. ### Leadership Path - The Four Patterns (Saturator/Investor/Overdrawer/Throttler) generalize to teams and organizations. A team's energy budget is the sum of its members' budgets minus overhead. --- ## What the Protocol Is NOT - **Not therapy.** Energy check-ins are not mood logs. They are budget reports. - **Not optimization.** The protocol does not aim to maximize Cascade size. It aims to keep the operator coherent. - **Not real-time.** The Daily Three is daily. Updates happen at decision points, not continuously. - **Not a measurement of relational quality.** A Blazing hex is not necessarily a "better" relationship than a Warm hex. It is more energetically expensive. --- ## Failure Modes ### Failure 1 — Gaming the budget If the operator reports `E_available = 100` every day to avoid deficit, the protocol is broken. Energy check-ins should be honest; over-reporting is a known failure mode. The cohort facilitator should check in on this directly. ### Failure 2 — Treating hexes as fungible A hex represents a specific person. Demoting a hex to cold is a real relational change, not just a spreadsheet move. The protocol should not be used to "optimize" relationships away. ### Failure 3 — Decisional fatigue If the operator cannot make a daily decision (because every hex is at equilibrium), that is fine — log equilibrium. Not every day needs a structural change. ### Failure 4 — Forgetting the energy ceiling is dynamic `E_available` shifts with sleep, illness, grief, joy, season. The protocol should track the trajectory, not just the number. --- ## Source Materials The Energy Budget Protocol operationalizes the Oscillator Model (`oscillator-model.md`). It is grounded in: - Damped-oscillator physics (cost formula) - Gottman rupture-repair research (ζ recalibration) - Altman & Taylor social penetration (A and ω) - Bernieri & Rosenthal synchrony (φ) See `sources/fact-check-notes.md` for verification. --- *This is the daily practice. Three minutes. One number in, one number out, one decision made.*