Carolopedia

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

📖 CarolopediaServicesBuild InitiativesAll activitiesINI-999902473Guide page
📋

CAROL-INI-3580-00: The Data Dictionary reaches the estate's unstructured writing, and every term traces to the data that instantiates it

Initiative
Open in Initiatives →

📖About

Ninad, 2026-08-02, on CAROL-INI-3574: two capabilities the dictionary does not have.

1. UNSTRUCTURED. Measured, the estate holds far more written text than stored fields and none of it is catalogued: ~18,600 generated initiative documents, ~1,500 files of Orion's memory corpus, per-agent identity and memory, per-user memory, 836 images, 59 videos, 44 voice clips — plus 152 free-text columns inside 131 tables across 41 databases holding conversation messages, agent memory, run logs, design bodies and decision rationales. The Data view stops at the column boundary and calls a prose column 'markdown text'. A third view registers this body of writing — as COLLECTIONS with counts and sizes, not 18,600 rows of noise — filed by the service that owns it.

2. TRACEABILITY. Today Terms and Data share only one axis: both are filed under a service. Nothing links a word to the data that instantiates it. Reading 'Agent' should show every place an agent's facts actually live, and reading a column should say which word it is an instance of. Two relationships must stay separate: an ATTRIBUTE holds a facet of the thing (an agent's name, look, voice, purpose); a REFERENCE merely points at one (an initiative's owner). There are far more pointers than facets, so mixing them buries the real attributes.

WHY IT MATTERS. Ninad's own reasoning: where the same fact is stored twice, the term is where the duplication becomes visible — and once visible, a check can compare the copies and fail when they part company. Agent name is already stored in three places; today they agree, and nothing would notice if they stopped.

HONESTY. Links derived by name-matching are marked derived, never authored, on the same standard the Data view already applies.

⚖️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 Data Dictionary app is registered and CAROL-INI-3574 delivered term definitions, synonyms, and near-miss words, but it did not add unstructured content registration or traceability from terms to the data that instantiates them. The estate's written content — generated documents, memory corpora, media, and free-text database columns — is still not catalogued as collections, and terms and columns are not linked. Attributes versus references are not distinguished for traceability. (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)
  • [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

  • An Unstructured view exists in the Data Dictionary registering the estate's written content — document collections, per-agent and per-user memory, media and voice, and the free-text columns inside databases — each with what it is, how much of it there is, and the service that owns it. (must_have)
  • Unstructured content is registered as COLLECTIONS with counts and sizes rather than one row per file, so the register is readable rather than 18,000 rows of noise, and every collection names a service or is listed as unfiled with the reason. (must_have)
  • Every term can be traced to the data that instantiates it: reading a term shows the columns and the unstructured sources that hold it, and reading a column shows which term it is an instance of. (must_have)
  • Attributes and references are distinguished and counted separately — a column holding a facet of the thing is never mixed with a column that merely points at one — proven on Agent, which has both. (must_have)
  • Every link states how it was made and whether it was derived or authored; a derived link is never presented as an authored one, and the counts of each are visible. (must_have)
  • The traceability makes duplicate storage visible: where the same fact is held in more than one place, the term names every place, proven on agent name which is stored in three tables. (must_have)
  • A regression test covers all of the above and is green, and the two new registers are refreshed by a registered, monitored process rather than by hand. (must_have)