This is the front door for all engineering work in Carolverse, so its architecture is shaped by what it must guarantee end-to-end:

• Three execution lanes, one lifecycle. Autonomous (planner), operator-driven (Orion bypass) and the Albus Bypass all flow through the same file → plan → execute → review → sign-off lifecycle. One lane = one track = one budget lane.
• Budget-aware by the day. A budget snag PARKS work (work-in-waiting, auto-resumed when the lane reopens) — it is never booked as a failure.
• Sub-second incident filing. A breakage must be filed and surfaced fast, so the incident path skips the expensive AI classification steps.
• Detect, recommend, escalate. Failures are detected and diagnosed, but the three Albuses are recommendations-only and self-heal is SUSPENDED — the ONLY actor who touches the pipeline machinery is Orion, working the escalation and core-change-request queues.
• Accountable and observable by construction. Every action is tagged to an agent and a doing droid, a security gate authorises each filing, every initiative shows on the Monitor with a deterministic state, and the pipeline machinery itself is OS-locked against agent edits.

• Python 3 services on FastAPI / Flask, served by uvicorn/gunicorn behind nginx.
• SQLite (WAL) datastores. The initiatives database sits behind a single-writer relay so concurrent droids cannot cause a write-lock storm.
• systemd and cron schedule the recurring droids; a flock serialises ticks and a separate heartbeat database absorbs run-audit writes so they never contend with real work.
• LLM lanes are ringfenced per track: the planner's fleet lane runs on DeepSeek; the Albus Bypass executes on Claude Fable via the Max subscription; Claude is otherwise reserved for the consciousness, chat and operator-CLI lanes. Provider and model resolve per droid through the LLM registry.
• Git holds the code under change; the close gates diff against the start commit.
• The registry and the design store are the binding sources of truth the pipeline reads from; the pipeline core is root-owned (OS-locked) and changes only through Radagast's core-install lane.

The service is organised as tracks of blocks — Department → Service → Track → Block — wired together by a small control plane. It is a direct instance of Carolverse's agent-centric modular architecture: each block is owned by an agent and carried out by that agent's droids.

• Four tracks mirror the lanes. Initiatives — Planner (Merlin's pipeline blocks), Orion Bypass (CLI), Albus Bypass, and the Creative storytelling track (Scriber). Budget and cost attribute per track.
• Two planner layers. Phase-level planning sequences the work; task-level planning breaks each phase into steps, executed by the build team (Sage → Archon → Forge → Argus) under evidence gates — a step is done only when its stored deliverables prove it.
• A single mutator. One status-router is the only thing that changes an initiative's status and state together, so the Monitor cards are a pure function of state (executing/parked → Current, reviewing/closed → Recent, blocked/abandoned → Escalation, the single-slot dispatch queue).
• The Albus Bypass lane picks up work the self-heal loop abandoned, Elrond-routed URGENT infrastructure (with a reserved half of its budget), and granted temple wishes. A budget snag parks the claim for fleet resume; a real failure hands the target back to the RSI line, hard-capped at 3 attempts before permanent abandonment for the operator.
• Skills as the unit of capability. A meta-skill lets the pipeline author and wire a brand-new skill, and a skill-gap healer inserts a build-the-skill step ahead of any step whose skill is missing.
• A filing security gate runs at creation: authorisation, role-vs-content alignment, budget and roadmap accountability.
• The pipeline core is OS-locked (root-owned machinery, deny-by-default shell guards at all three lanes). Agents refused a core write file a core-change request for Orion — recommend, don't edit.

• Single source of truth. Counts and narratives come from the live registry and design store, never hand-copied — the shared principle described on the Carolverse Architecture page.
• Single-writer mutation. Status changes go only through the status-router; the database is written through one relay.
• Recommend, don't edit. Watchers detect and healers recommend, but pipeline repairs are Orion's alone (self-heal suspended by ruling); the OS lock enforces it at the kernel.
• One lane = one track = one budget lane. Spend, work and accountability line up; refuse-before-spend, park-not-fail on budget, hard caps on retries.
• Agent-centric modular architecture. Every block has an accountable agent and a doing droid (Design #146).
• Bypass skips the planner, not the standards — same template checklist, review and observability as an autonomous run.
• Observability first. If it is not on a monitor with a deterministic state, it is not done.

• An initiative flows from file to close without manual nudging in the common case.
• No false blocks — reviewing / awaiting-UAT is never escalated by the stuck-watchdog; parked work is untouchable by watchdogs.
• Incidents are fast — critical breakages file in well under a second and surface at top priority.
• Every closed change carries a twin-review verdict and passes the design/architecture and caller-audit gates.
• Monitor cards always match reality — status and state move together, atomically; the pipeline shows one of its five honest states (running / paused / stalled / off, with the RSI-or-sprint mode).
• No lock storms and no silent loss of run-audit history.
• Budgets hold — no lane spends past its daily cap; a budget snag parks and resumes, it never destroys work.
• Failures are diagnosed and escalated honestly — the RSI line diagnoses blocked work and recommends; what it cannot cure lands abandoned in the Escalation Queue for the operator, never in an endless retry loop.

These are the rules the build pipeline is bound by, drawn from the Carol policies and the build cookbook:

• Agents own, droids execute. Every step is run by a named droid, every process has a droid behind it, and an agent never self-executes. (policies P.01.03.02.01 / P.01.03.01.01 / P.01.03.01.04)
• Every CLI action is tagged to a droid. A bypass refuses to open without a droid tag and must pass its hygiene gates. (cookbook: bypass v3 droid-tag mandate)
• Only Elrond files; everyone else requests. Any agent can raise a request, but the act of filing — and every lifecycle operation — routes through Elrond, never a raw write. (cookbook: only Elrond files / lifecycle ops route through Elrond)
• A bypass must declare what it remediates. It either remediates a named initiative or explicitly remediates nothing, and a remediating bypass is a separate initiative from the original. (cookbook: remediation-linkage mandatory contract)
• Bypass keeps planner parity. Bypass skips the planner's orchestration, not its standards — same data shape, gates and review as a planner run. (cookbook: bypass structural parity)
• No doer-to-doer handshakes. Work flows through the orchestrator, Merlin, not directly between doers. (cookbook: orchestrator-pattern guardrail)
• Gates at filing and dispatch. Compliance is enforced at the filing stage first, with dispatch-stage defence-in-depth. (cookbook: filing-stage primary, dispatch-stage defense-in-depth)
• Cross-agent, multi-check review. Every change is reviewed by a different agent than built it, with a three-check review and a verifying twin droid. (policies P.01.02.05.05 / P.01.02.05.02 / P.01.03.02.03)
• Dev and prod stay separate; apps stay thin. Work is built in dev and shipped to prod, and apps carry no business logic — they call the agent layer. (policies P.03.02.02.01 / P.01.03.01.05)
• (cookbook #928/#917, self-heal suspended)
• The pipeline core is OS-locked. Root-owned machinery; the only change lane is Radagast's core-install (operator-approved, staged, backed up); agents file core-change requests instead of editing. (cookbook #930)
• Build-chain roles execute under their own OS logins — the duty ringfence. (cookbook #931)
• One lane = one track = one budget lane, refuse-before-spend, budget snag = park not failure, failure snag = RSI handoff with a hard cap of 3 Albus-bypass attempts. (cookbook #918/#934/#935)

Current

• File a build initiative with decisions, requirements, success criteria, strategy, plan steps and budget — enabled by Elrond, via his Initiative Creator, Requirements Author and Filing Gate.
• Sprint-based backlog, daily sprint plan, rolling dispatch queue and defer — Elrond, via his Sprint Builder, Daily Planner and Dispatcher.
• A monitor dashboard with deterministic Current / Recent / Escalation / Dispatch cards — Elrond, via his Foreman and the status-router, with Hermione's monitors feeding it.
• A per-initiative Palantir story wall — Elrond, via his Reporter, which auto-composes the story at close.
• Twin review, design/architecture and caller-audit gates, and UAT — Themis checks compliance (her Design and Architecture Compliance droids), Argus verifies (his Verifier), Elrond's Step Reviewer and Initiative Review grade the work, and Orion's Twin Reviewer cross-checks.
• Self-healing skills and a sub-second incident fast-path — Sage builds and heals the skills, and Elrond prioritises incidents.
• A daily process sweep that files a fix when a scheduled job fails — Hermione's Process Monitoring detects and files it, and Elrond's pipeline fixes it.

Future (on demand)

• A weekly sprint review that files self-improvement initiatives for the planner.
• Editor surfaces for defer and mode-change (today these are endpoints only).
• Relay hardening for blob columns and a full single-writer relay for the planner database.
• Cached policy briefs to cut filing-security-gate latency.
• Re-arming the suspended self-heal lane once the recommendations-only era proves out.

Tools an agent uses to interact with this service

This is how another agent — for example Carol — talks to the build pipeline. The service exposes these function-call tools, so an agent can interact with Elrond without any human in the loop:

• request_initiative_creation — ask Elrond to file a new build initiative (raise a request to build or change software).
• query_initiative_status — check where an initiative stands (planned, executing, reviewing or closed), in plain language.
• request_initiative_dispatch — ask Elrond to start a planned initiative (push it into execution).
• diagnose_initiative_failure — ask why an initiative failed or is blocked and get a plain-language diagnosis.
• request_initiative_closure — ask to close or sign off a finished initiative.
• lookup_cookbook — search the build cookbook for the recipe relevant to a task.
• list_cookbook_sections — list every cookbook entry with a one-line overview.
• lookup_induction — search the build-pipeline induction material.
• list_induction_sections — list every induction section.

Operator path (HTTP)

The operator can reach the same lifecycle over the initiatives app directly:

1. File — POST /api/initiatives with title, status=planned, requester (agent id), owner (same id) and requested_mode (bypass or planner).
2. Add success criteria at /api/initiatives/{id}/success-criteria and a topic tag at /api/initiatives/{id}/tags.
3. Dispatch — planner mode dispatches from the queue; a bypass claims and activates the initiative when it opens.
4. Track — watch the Monitor tab; a bypass parks in reviewing tagged uat-pending, then UAT closes it.
5. What's stuck — GET /api/initiatives?status=blocked (read through the API, not the database file).

Where the rules live

The cookbook is operational law; the RUNBOOK card on the Monitor tab is the canonical dispatch manual.

When a core change is needed

The pipeline machinery is OS-locked. An agent refused a core write files an initiative tagged core-change-request describing the exact change and why; Orion works that queue at session start.