📖About

SURFACED BY CAROL-INI-3679 (CLI-229, 2026-08-04) while curing Carol's WhatsApp lane.

MEASURED, all 70 pins in the live LLM config, none sampled. Each was classified by asking the REAL resolver what it returns and comparing it to what the pin asks for:

DEAD -- a lane answers instead, and differently : 54 REDUNDANT -- a lane answers, and agrees : 16 LOAD-BEARING -- the pin actually decides : 0

ZERO. Not one pin changes a single resolution. Every droid that carries a pin also carries a task, and since CAROL-INI-3620/3633 the task lane answers first and never consults the pin. The whole per-droid override layer is vestigial.

WHY IT IS NOT HARMLESS. A pin is a written instruction, and 54 of them currently say something the estate does not do. CAROL-INI-3679 made that VISIBLE (a banner on Carol Intelligence, cookbook 1195) rather than silent -- but visible-and-wrong is a resting state, not a cure. Every reader of that config still has to know a rule it does not state in order to not believe it. And each dead pin is a trap for the next person who edits one expecting it to take effect.

SCOPE. 1. Decide with the operator whether the layer is RETIRED entirely or kept as a declared-but-inert record. Retiring it is the honest reading of a layer with zero load-bearing entries; keeping it needs a stated reason. 2. If retired: remove the overrides from the live config. This edits the protected-core LLM config, so it goes through the core-install lane via Radagast with operator approval -- and OFF-first, because it touches how every lane resolves. 3. Prove NOTHING moved: capture the resolved (provider, model) for every droid in the estate before and after, and assert the two maps are identical. A pin layer that decides nothing must be removable with a zero-diff, and if the diff is not zero the classification was wrong and the change stops. 4. Whatever survives, keep cookbook 1195's audit reporting on it, so the same drift cannot re-accumulate in silence.

NOT URGENT. Nothing is mispriced or misrouted today -- CAROL-INI-3679 proved the lanes resolve correctly. This is the cleanup that stops the records lying to their next reader.

⚖️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] 5 must-have criteria remain pending at bypass_end — delivery has no mechanical re-performance lane; UAT must grade on live evidence, not checklist silence (CAROL-INI-3020): (no detail) (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [status-router] reviewing -> executing | event=bypass_executing | bypass transition (or-bx-01)
• [delivery-check] 5 must-have criteria remain pending at bypass_end — delivery has no mechanical re-performance lane; UAT must grade on live evidence, not checklist silence (CAROL-INI-3020): (no detail) (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [status-router] reviewing -> executing | event=bypass_executing | bypass transition (or-bx-01)
• [delivery-check] 5 must-have criteria remain pending at bypass_end — delivery has no mechanical re-performance lane; UAT must grade on live evidence, not checklist silence (CAROL-INI-3020): (no detail) (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

• Carol Intelligence's Pins Overruled banner reads zero: no droid on any surface names an engine it does not use. (must_have)
• Every droid in the estate resolves to the same provider and model after the change as before it — the captured before/after maps are identical, so no agent's behaviour moves. (must_have)
• Carol still replies on WhatsApp and every agent chat still answers after the change, proven by real calls in the ledger, not by reading the config. (must_have)
• The live LLM config contains no per-droid override that the resolver ignores. (must_have)
• The pin-honoured audit still runs and still reports on whatever remains, so a reader can tell honoured from overruled at a glance. (must_have)
• Carol's helper identities (pa-c3, pa-c4, pa-c6, pa-c9, pa-c10, carol-server) are shown from the registry to resolve to a lane Ninad chose for CAROL, not to whatever the fleet is running. Measured 2026-08-06 (CLI-233): in the three days prior they made 142 calls on the fleet's bulk lane because they sit on the sales-core track -- exactly what cookbook 589 forbids. CLI-229 cured Carol's serving engine this way; her helper tier was left behind. (must_have)
• Cookbook 589 no longer states a protection that has no mechanism. It names no_fleet_net in the per-droid overrides map, and that map is EMPTY -- so 'Carol never uses the fleet lane' is currently law that cannot be applied or broken. Amend it to name whatever enforces it today, or supersede it. (must_have)