📖About

Ninad ruling (2026-08-01, CLI-196). Because the flawless daily backups and the Shipper — which failed 177 of 177 runs in 14 days — shared one line, the service kept reporting healthy while its off-site copy was dead.

A track is an ACCOUNTABILITY boundary, not a budget envelope. So the split is justified by what BREAKS and who answers for it, not by money.

FOUR TRACKS, split by WHERE THE COPY LANDS (Ninad's framing — the classic three-copies rule): upkeep - is the machine healthy and running? (8 workers: App Steward, Resource Sentinel, Daily Janitor, CPU Metric, RSI Engine, RSI Scoreboard, Improvement Collector, Improvement Filer, + hosting and networking when staffed) on-machine - is the crown jewel safe right now? (Registry Backup 6-hourly, Collapse Guard 10-minutely — the Guard is RECOVERY not backup, but it is useless without the snapshots it restores from, so they share a track) laptop - if we lost the VM, could we recover? (Backup Custodian) off-site - if we lost BOTH, could we recover? (Shipper, Shipper Twin)

ACCOUNTABILITY vs RESPONSIBILITY (Ninad, explicit): the laptop backup is EXECUTED on Ninad's Mac, not by Carol — the Carol-side Custodian only writes a completion marker. Hagrid remains ACCOUNTABLE for it regardless. Responsibility may sit elsewhere; accountability does not move. The 'laptop' track exists precisely so that accountability has somewhere to live.

ORG COUPLING: 'infra_operations', 'compute_hosting' and 'networking' are owned by Guardian, who reports to Galadriel, inside a service owned by Hagrid, who reports to Rhea. Ninad: Guardian cannot be in this service. The work is infrastructure — Hagrid's domain — so the blocks are RE-OWNED to Hagrid rather than moved out. Guardian keeps the blocks he owns inside Galadriel's own service, where the line is correct.

NO SEPARATE IMPROVEMENT TRACK: checked across all 18 services — not one has a standalone improvement/RSI track; improvement is folded into each service's core everywhere. Improvement is ongoing work, so it stays inside upkeep rather than becoming the estate's only exception.

Every cap is POSITIVE deliberately: a zero cap reads as 'ungoverned' in the enforcer, not as 'blocked'.

⚖️Decisions

• Elrond's bypass methodology checklist (a reminder, not a gate -- you've got this): 0. File it requested_mode='bypass' (planner-vs-bypass is a deliberate choice). bypass_start REFUSES a non-bypass initiative (CAROL-INI-1846), and the dispatcher only skips the bypass lane when the mode says bypass -- a 'planner' mistag lets Merlin's pipeline grab the placeholder step and block your finished work. 1. Filed as planned status -- let the bypass claim/activate it; never file active. 2. Open the bypass (bypass_start) with your droid id + the remediation answer (remediates_initiative_id=NNN, or remediates_nothing=True). 3. Work the blocks for your work-type: template -> design -> code -> test -> review. Do the real work; record decisions on the initiative as you make them. 4. Reality is recorded for you at close -- code (files changed), each decision, and the twin-review verdict become real activities tied to this initiative and show in the Activity Tracker like a planner run (CAROL-INI-1840). No dummy rows. 5. Keep the initiative status moving; it parks in 'reviewing' and is tagged uat-pending for you at close (CAROL-INI-1836), so the stuck-watchdog leaves it alone until UAT. 6. Close runs the gates (design/architecture compliance + caller-audit). If a gate flags something pre-existing or unrelated to your change, waive it with a clear written rationale -- audit, don't skip. 7. Bypass skips the planner's auto-orchestration, NOT the standards. Same template checklist, same review, same observability as a planner run. (elrond)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• [delivery-check] 7 must-have criteria remain pending at bypass_end — delivery FAILED live re-performance; UAT must grade on live evidence, not checklist silence (CAROL-INI-3020): test test_ini3569.py: FAIL (no tests ran in 0.79s) (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [status-router] reviewing -> closed | event=operator_signoff | Auto-accepted (CAROL-INI-1859): Orion-initiated, >2 days in reviewing with no objection. (el-srac-01)

✅Success criteria

• Every one of the 13 live workers resolves to exactly one of the four new tracks, and none resolves to the retired pair — proven by asking the live resolver for each worker, not by reading the table. (must_have)
• The Shipper's failures show up against a track of their own, so a person can see the off-site copy is dead while the backups are healthy — the exact confusion the old single track created. (must_have)
• Every track in the service is owned by an agent inside the service owner's reporting line; no block is left owned across a line without routing. (must_have)
• Each of the four tracks carries a positive daily limit and none reads as ungoverned to the enforcer. (must_have)
• (must_have)
• No worker is silently dropped: the count of live workers in the service is the same before and after, and any block left empty is deliberate and named. (must_have)
• The change survives a restart — the registry writes are checkpointed into the main database, not left in a side-file that a restart could discard. (must_have)