Governance is the layer that makes the rest of Carolverse trustworthy, so its architecture is shaped by what it must guarantee across every service:

• A single, readable rulebook. The constitution and policies must be the binding reference any agent or service can point at — one place, not scattered copies.
• One source of truth. Requirements, designs, and the catalog of what exists must be derived from live sources, never hand-maintained, so records match reality.
• Accountability by construction. Every governed action ties back to an accountable agent, so oversight has something concrete to check.
• Continuous oversight. The monitor must keep watch over services and surface where reality drifts from the records or the rules.
• Honest about state. Where a pillar is still being built, that must be visible rather than papered over.

Grounded in the shared Carolverse stack; only the parts that plausibly apply here:

• Python 3 services on FastAPI / Flask behind nginx, where Governance surfaces are served.
• SQLite (WAL) datastores hold the policies, requirements, and design records.
• The registry and the design store are the binding sources of truth that the oversight pillars read from.
• systemd / cron schedule any recurring oversight sweeps as the monitor pillar is built out.
• Claude (Sonnet/Opus) for the reasoning steps where rules or designs must be interpreted.
• Much of the implementation is still intended rather than built — see the roadmap.

Governance is conceived as a small set of oversight pillars rather than a build pipeline, wired into the same agent-centric modular architecture as the rest of Carolverse: every rule and record has an accountable owner, today Orion.

• Constitution + policies — the binding rulebook other services are checked against.
• Requirements + designs — auto-derived from live sources, the reference for what each service is supposed to do and be.
• The source-of-truth catalog — the registry of what actually exists across Carolverse.
• The monitor — continuous oversight that compares running reality to the records and the rules.

These pillars are not yet consolidated into one service; today they live as the stores and conventions that other services already read. The architecture work ahead is to draw them together behind a single Governance control surface.

• Single source of truth. Requirements, designs, and counts are derived from the live registry and design store, never hand-copied — the shared principle described on the Carolverse Architecture page.
• Agent-centric accountability. Every rule, record, and oversight action has an accountable agent owner.
• Observability first. Oversight is only real if drift surfaces on a monitor; if it is not watched, it is not governed.
• Honesty over polish. State what is built and what is still intended, plainly.

• The constitution and policies are the one place every service is checked against, with no conflicting copies.
• Requirements and designs match live reality, because they are derived from sources, not maintained by hand.
• The source-of-truth catalog reflects what actually exists across Carolverse.
• The monitor surfaces drift — where a service diverges from its records or its rules — rather than letting it go unseen.

• One source of truth. Records are auto-derived from live sources; the rulebook is never silently forked into per-service copies.
• Every governed action is tied to an accountable agent — never a human id, never anonymous.
• Lifecycle and record changes route through the owning app and its agent, never by hand-editing a store.
• Bypass skips the planner, not the standards — the same checklists, review, and observability still apply (the org-wide bypass rule this layer enforces).

Current

Governance is wip; what exists today are the pillars as shared stores and conventions that other services read, overseen by Orion:

• The constitution and policies as the binding rulebook of record.
• The requirements and designs stores, derived from live sources.
• The source-of-truth catalog (the registry of what exists).
• Early monitor oversight surfaced through the existing service and registry views.

These are not yet packaged behind a dedicated Governance service — there are no Governance-specific blocks, droids, or agent-facing tools yet.

Future (on demand)

Because the service is early, most of its capability is ahead:

• A single Governance control surface that draws the constitution, policies, requirements, designs, and catalog together in one place.
• A continuous oversight monitor that compares running services to their records and rules and flags drift on its own.
• Policy-compliance gates that any service can check itself against before shipping.
• Doing droids under Orion to run the recurring oversight sweeps, so governance is observable and self-healing rather than manual.

This service has no agent-facing tools yet — it is operated by its owner.

Operator / owner path

• Orion operates Governance directly: the constitution and policies are the reference, and the registry + design store are the sources of truth to read from.
• To check what a service is supposed to be, read its requirements and designs (derived from live sources), not a hand-kept copy.
• To check what actually exists, read the source-of-truth catalog (the registry).

Where the rules live

• The constitution and policies are the binding rulebook. As the service is built out, a dedicated Governance control surface and oversight monitor will replace today's manual, owner-driven path.