Why a thin centre
The 2026-04-29 control-plane decision was the architectural choice that shaped everything since. This page is the readable companion: why the system has a thin centre, and what “thin” concretely means.
Three pains the system addresses
Section titled “Three pains the system addresses”- Duplication. Methodology files (META-RULES, agent-fleet shape, prompt conventions) were bootstrapped into each consumer repo and then drifted — same content in N places, edited inconsistently.
- No cross-repo visibility. No aggregate view of phase status, open decisions, or in-flight milestones across the fleet of consumer repos.
- No agent-fleet write path. KAHN-style fleets could diagnose and plan in a consumer repo but had no disciplined, MR-compliant way to act on changes across the fleet.
These three were addressed in one architectural move, not three.
The three options weighed
Section titled “The three options weighed”The decision document considered three:
- Status quo (template line only). Each consumer repo continues to receive bootstrapped copies of methodology files. Rejected — the duplication pain is real and growing, and there is no path to fleet-level agentic action without a verb layer.
- Central database (Postgres) as source-of-truth for guidance.
All north-star content, decisions, milestones moved to a central
store with consumer repos pulling on demand. Rejected —
violates MR-7 (decisions decouple from the code they govern, lose
git blame, lose branch protection as the human gate) and MR-12 (consumer CLAUDE.md would project from a remote source not grounded in local spec). See no central database. - Petrova as a versioned package only (no control plane). Publish PETROVA as an installable CLI used locally inside each consumer repo, no central registry, no aggregator. Rejected — works for solo low-volume use but provides no path for cross-repo orchestration by KAHN fleets.
The chosen option is a control plane with a deliberately thin centre.
What “thin” means concretely
Section titled “What “thin” means concretely”| Centralised in PETROVA-HQ | Stays in each consumer repo |
|---|---|
| Methodology (META-RULES, agent-fleet shape, prompts) | Project intent (docs/north-star/) |
Action verb specifications (spec/verbs/) | Project decisions (docs/decisions/) |
Registry of governed repos (registry.yaml) | Project milestones (MILESTONES.md) |
Read-only cross-repo aggregation (dashboard, status) | Project subagent roster (AGENTS.xml) |
| The CLI and skills that drive the verb surface | Project requirements (docs/spec/) |
The asymmetry is the point: methodology is portable, project truth isn’t. Centralising the first eliminates duplication; not centralising the second preserves MR-7 and MR-12.
What we accepted in exchange
Section titled “What we accepted in exchange”- Latency. Verbs round-trip through GitHub’s API (~30s for an apply). A central database would be milliseconds. We chose audit trail and review checkpoint over speed. See trade-offs.
- Narrow surface. Nine verbs — that’s it. No “petrova update whatever you want.” Fleets operating outside the verb catalogue must surface gaps to humans rather than improvise.
- Human-in-the-loop persistence. Profiles default to strict. Auto-merge requires explicit profile + fleet allowance. We chose this over speed-of-iteration.
These trades are intentional. The system is meant to be boring — the same operation produces the same shape every time, with the same audit trail, regardless of who initiated it.
See also
Section titled “See also”- Control-plane decision — the formal record.
- Three concentric rings — the topology this decision produced.
- Trade-offs accepted — what we gave up to get here.