Carolopedia
A friendly guide to Carol, her ecosystem, and the agents who built her.
📖About
Ninad, 2026-08-01: Carolverse has no glossary. Nothing anywhere defines daemon, droid, system service, app, agent, process or service; the constitution is dense with concepts and defines none of them; and the only real definitions that exist - 30 Concepts cards - are buried inside the Source of Truth app with no synonyms and no disambiguation.
SCOPE. A NEW app named Data Dictionary whose subject is the LANGUAGE of Carolverse, not the behaviour of apps. Every entry carries: the term, its plain-language meaning, its synonyms and aliases, and its NEAR-MISS pairing - the similar-sounding term it is routinely confused with, and the sentence that separates them (droid vs daemon, service vs system service, review vs audit, gate vs review, owner vs decision-maker, doer vs enabler, watcher vs healer, initiative vs attempt, block vs track).
ONE TRUTH (Ninad, this session): a term is defined ONCE. The glossary store is the truth; the Source of Truth app's Concepts category RENDERS from it rather than holding its own copy, so a word can never be defined twice and drift.
SEED COVERAGE: the entity vocabulary (agent, droid, daemon, app, service, system service, process, block, track, department, initiative, attempt), every concept the constitution uses without defining, and the governance and pipeline vocabulary already ruled on in the cookbook.
OUT OF SCOPE: the App Handbook rename (its own initiative).
⚖️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)
- [status-router] executing -> reviewing | event=dispatcher_transition | dispatcher state change (ds-s1)
- UAT r1: organised by service and track, not by invented categories — Ninad, UAT r1: 'data dictionary needs to be organised services and tracks'. He is right and the original was wrong in kind: the app had invented seven categories of its own (entity, governance, work, money, records, people, infrastructure) when the estate already has an axis for filing everything — the service, and the track inside it. A surface that invents its own taxonomy is a second source of truth about how the estate is shaped. CHANGED. Every term now names the SERVICE whose vocabulary it is, and a TRACK when it belongs to one subdivision rather than to the service as a whole; both are validated against the registry at write time and resolved from the registry at read time, so the dictionary carries no copy of the estate's shape. All 124 terms are filed across 12 services and 17 tracks with none left over: Constitution 39, Build Initiatives 23, Governance 23, Agent Chat 11, Cost Center 9, Agent Resources 7, System Services 4, then Audit, Process Monitoring, Quality Management, Blogs and Security. The page groups by service, busiest first, with each service's owning agent named and its tracks nested beneath; a term belonging to the service as a whole sits above the tracks rather than being forced into one. A term filed under NO service is now a coverage gap on the same footing as a missing synonym. TWO DEFECTS FOUND WHILE DOING IT. The accessor ran its schema script on every READ, which had been harmless only because every object in it already existed — the moment the new service index was added, every read failed on a read-only connection. Schema now runs on the write path only. And search knew nothing about the new axis: the page could filter by service name but the API could not, so searching a service returned nothing. Both fixed and covered by assertions. (ninad)
- UAT r2: comprehensiveness — the term sweep, and the 3,247-field data register — Ninad, UAT r2: 124 terms is not comprehensive — 'if you scan through the apps and databases, there will be thousands of definitions'. Measured, he is right, and the shortfall splits in two. TERMS. A mechanical sweep of the cookbook rulings, policies, designs and every state value the live stores actually hold yields ~350 real candidates behind 2,288 raw ones. Batch 1 authored 42 of the highest-value: every initiative status, every queue status, every criterion status, all ten review verdicts, the execution modes, and the pipeline machinery the cookbook rules on most (phase, task, diagnosis, remediation, follow-on, filing, close, relay, watchdog, breaker, master switch, skill, prompt, grounding, measure, scorecard). 124 -> 166 terms, 405 synonyms, 293 near-miss pairs, zero incomplete. The remaining ~200 candidates are pass 1's later batches. DATA. The bigger gap, and the classical meaning of a data dictionary: 3,247 stored fields across 76 databases and 345 tables. Only 55 were defined anywhere before this (and even those as App Handbook screen elements, not as fields). A new register — glossary_data_elements — now holds every one, filed under the service that owns the data, with its type, key, and the values it ACTUALLY HOLDS where the column is a closed set (1,318 of them, which for a status or mode column is the definition). PROVENANCE is stated on every row and counted on the page: 55 authored, 3,192 derived by the scan. A derived definition never poses as an authored one, and re-scanning never overwrites a human's words with a guess. FILING. Name-matching a database to an app got two thirds wrong — a store is named after its SUBJECT, not after the app that renders it — so the database-to-service map is explicit. 2,925 of 3,247 fields are filed; the 322 that are not sit in three stores that genuinely belong to no Carol service (two Glover, one dated backup) and are listed WITH the reason rather than left blank. The page is now two views on one axis: Terms and Data, both grouped by service. (ninad)
- Pass 1 complete: 306 terms, ended by measurement — the remaining candidates are proper nouns and plurals — Pass 1 of the comprehensiveness sweep is COMPLETE, and it ended by measurement rather than by fatigue. Six batches took the glossary from 124 to 306 terms, 758 synonyms and 564 near-miss pairings, all four parts present on every entry, all filed across 17 services and 24 tracks with nothing left over. WHAT WAS ADDED. Every state word the live stores actually hold — eight initiative statuses, six queue statuses, seven criterion statuses, ten review verdicts, the execution modes; the pipeline machinery (phase, task, diagnosis, remediation, follow-on, filing, close, relay, watchdog, breaker, master switch, strike, loop); architecture and records (pattern, template, contract, boundary, shim, canonical, artifact, scan, derived, authored, provenance, data element, closed value set, coverage, gap, evidence, decision, traceability); the agent at runtime (identity record, memory, semantic memory, context, session, channel, tier, allowlist, wake, heartbeat, activity, mind, intention, briefing); operations (deploy, shipper, restart, route, port, backup, snapshot, restore, write-ahead log, repository, commit, environment); the model layer (model, adapter, pin, fallback, refusal, hallucination, tool call); money (token, rate card, mileage, spend, undeclared, exempt, metered, day exception, cap); security (credential, vault, rotation, grant, principal, role, isolation); and the words the dictionary needed to describe itself honestly. WHERE IT STOPS, AND WHY. Re-running the extractor over the cookbook, policies, designs and live state values now leaves 271 candidates at three-or-more mentions, down from 350. Inspecting what remains: agent proper names (Albus, Elrond, Sentinel — those are Carolopedia's business, not a dictionary's), plurals of terms already defined, initiative-number prefixes, and ordinary English. There is no further batch of real terms waiting; the tail is noise. That is the honest end of pass 1. All three suites green after every batch: the glossary's 60+ assertions, the App Handbook's, and the handbook app's own nine. (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
- A Data Dictionary app exists and is registered, owned, routed and reachable, whose subject is terms - not app metrics - and it is listed on the app surfaces like any other app. (must_have)
- Every entry carries all four parts: term, plain-language meaning, synonyms/aliases, and at least one near-miss pairing with the sentence that separates the two; an entry missing any part is reported as a coverage gap rather than shown as complete. (must_have)
- The entity vocabulary is defined and disambiguated - agent, droid, daemon, app, service, system service, process, block, track, department, initiative and attempt - with droid vs daemon and service vs system service each carrying an explicit near-miss entry. (must_have)
- Every concept the constitution uses without defining has a glossary entry, proven by listing the constitution's concept terms and showing each resolves to an entry. (must_have)
- A term is defined exactly once: the Source of Truth app's Concepts cards render from the glossary store, all 30 existing concepts survive the move with their text intact, and no second copy of any definition remains anywhere. (must_have)
- The glossary is searchable by term and by synonym - searching an alias finds the canonical entry - proven by real queries, and the regression suite covering it is green. (must_have)