Elrond Block owner

Elrond is the gatekeeper of filing — he is the one who guarantees that anything entering the pipeline is real, in-scope and legitimately created, and he owns the heaviest filing machinery. The Initiative Creator runs the end-to-end create_initiative orchestration: it canonicalizes the title, validates status and identity fields, refuses human-name requesters (Orion being the only human CLI requester), runs the filing-invariant and blocked-parent gates, inserts the new row, parks the target atomically for Albus bypasses, auto-detects the remediation target for Orion bypasses, auto-starts the bypass session, and records a session_event plus a Palantir post on success. The Filing Gate enforces the autonomous-agent filing-invariant on Albus/Elrond follow-on filings — confirming the filing names a real, currently-active parent, refusing filings that target an Orion-filed bypass, blocking Albus filings that reach outside the build pipeline into governance surfaces like cookbook, policies, SSTs, designs or prompts, and confirming the follow-on chain traces back to a non-Albus root. The Initiative Validator then gives a pre-flight keep/refine/strike verdict on every requirement, criterion and plan step by snapshotting live Carol state (regression runner, designs, cookbook, registry, requirements, SST) and asking Haiku to judge each item against present-day reality, feeding flagged items back to the Author for up to two refinement rounds and never editing the initiative itself. This matters because it stops stale, mis-scoped or self-referential work from ever going active. It fires at the moment of filing, before the initiative reaches active status, with the bypass-parking and remediation-detection paths covering the Albus and Orion bypass scenarios respectively.

Albus

Filing is where a request becomes a well-formed initiative, and Albus contributes the initiative-level design so that what enters the pipeline has an architectural shape from day one, not just a title and some requirements. The Initiative Design Author droid does this by authoring the initiative-level design rows — architecture, workflow, data-model and interfaces — through the Claude Code harness, and it is deliberately distinct from Albus's troubleshooter persona so design authorship never gets entangled with failure triage. This matters because an initiative that goes active without an architecture-and-data-model design would force every later step to improvise its structure, which is exactly the drift the pipeline is built to prevent. It fires during filing, alongside the requirements and design authoring that turn a raw request into an active initiative, before the filing-invariant and validity gates pass judgment. In the normal path it produces one design covering the four facets; because it is harness-authored, the design reflects present-day Carol conventions rather than a static template.

Archon

Archon is the design author at filing time, responsible for giving a brand-new initiative a concrete, scoped design before it is allowed to go active. The Design Author droid writes a design row scoped to the initiative that covers architecture, workflow, data-model and interfaces, generated through the Claude Code harness so it reflects live design conventions rather than a frozen template. This matters because the initiative-level design is the reference every downstream step and reviewer leans on; without it, the build would have no agreed architecture or interface contract to conform to and the design-compliance gates later would have nothing to check against. It fires during the filing block, in concert with the requirements author and the validity gates, as part of turning a request into a fully-formed initiative. Normally it produces a single initiative-scoped design row spanning the four facets, establishing the design baseline the rest of the pipeline inherits.

Sage

Sage is the requirements author at filing time, the role that converts a raw request into the structured requirement rows the rest of the pipeline can plan and verify against. The Requirements Author droid does this by authoring initiative_requirements rows from the initiative's title, description, decisions and success criteria, generated through the Claude Code harness so the requirements reflect how Carol actually frames work today. This matters because requirements are the contract everything downstream is measured by — the planner builds steps to satisfy them and the reviewer grades the initiative against them — so an initiative filed without well-formed requirements would have nothing concrete to be planned or judged against. It fires during the filing block, in parallel with the design authors, as part of turning a request into a fully-formed, active-ready initiative. In the normal path it emits a structured set of requirement rows that Elrond's validator then verdicts for present-day relevance before the initiative goes active.