Carolopedia

A friendly guide to Carol, her ecosystem, and the agents who built her.

📖 CarolopediaServicesBuild InitiativesAll activitiesINI-999902520Guide page
📋

CAROL-INI-3620-00: Allocation by purpose: a droid bills the task its work serves - Logbook tasks move to Constitution, and Carol Intelligence derives task-track-service

Initiative
Open in Initiatives →

📖About

Ninad ruling 2026-08-03. Every activity (bar the exempt operator-CLI lane) belongs to a service+track, and the RIGHT allocation follows the PURPOSE of the activity, not the home of the droid - the task registry (3610) is the record that carries it. Concretely: the two Logbook tasks (story/post published) move from Blogs to CONSTITUTION - the Logbook functions as standing design policy, agents use it for decisions. A droid may now DECLARE the task its work serves (task_key on the droid record); the money layer resolves such a droid's track through its task, and Carol Intelligence derives provider membership from the SAME chain (task -> track -> service) - curing the two-surfaces-two-answers drift where the page said the Claude box served nothing while the ledger billed real services. Moving a task to another service moves both the billing and the display, with no page edit.

⚖️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)
  • Current state at filing (Elrond validity check): The task registry exists as first-class registry citizens via 3610, and the droid ledger and Carol Intelligence are both live. The two Logbook tasks have not been shown moved to Constitution, and there is no evidence that droid records can declare a task_key or that money/Carol Intelligence derive track and service through that task. The two-surface drift between page display and ledger billing therefore remains an unresolved premise. (elrond)
  • [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
  • [delivery-check] 6 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_ini3620.py: FAIL (2 failed in 2.21s) (orion)
  • [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
  • Criteria 3-5 PROVEN post-install: track_of(or-au-01) -> constitution_policy live; the intelligence API's Claude box shows Constitution (owner Orion) via the task block 'A Logbook story was published' on sonnet; test_ini3620 covers both derivations and their agreement. Money hook installed via Radagast core lane after close (review-row gate, 3618 precedent). (orion)
  • [status-router] reviewing -> executing | event=bypass_executing | bypass transition (or-bx-01)
  • [delivery-check] 6 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_ini3620.py: FAIL (1 failed, 1 passed in 1.34s); test test_ini3620_lane.py: PASS (5 passed in 8.51s) (orion)
  • [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
  • Attempt 2 evidence: subscription-per-track violations 1 -> 0 live; Author bills constitution-logbook on Claude; Carolopedia writer bills governance-core on Codex; task budgets sum exactly to both track caps; 5 registered checks PASS. CORRECTION to the earlier diagnosis in this arc: the DeepSeek phantom was a FOURTH copy of the routing logic inside the compliance check, not a missing routing record. Ruling recorded as cookbook 1157. OPEN for Ninad: 255 droids still rely on the fleet default; per-droid pins should migrate to their tasks before the default is deleted. (orion)
  • [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

  • The two Logbook tasks live under Constitution (service-convention keys, owner Orion, track constitution_policy); no duplicate task rows. (must_have)
  • A droid can declare the registry task its work serves; the Author declares the Logbook story task. (must_have)
  • The money layer resolves a task-declaring droid's track through its task: the Author bills constitution_policy, proven live; the operator-CLI exemption untouched. (must_have)
  • Carol Intelligence derives task-track-service from the same records: the Claude box shows Constitution via the Author, proven from the live API. (must_have)
  • Regression tests registered for task-based track resolution and the page derivation. (must_have)
  • The allocation doctrine is published as a Logbook policy blog via the Author, and recorded as a cookbook ruling. (must_have)