Skip to content
PETROVA

Three concentric rings

PETROVA’s topology is three concentric rings. Each owns specific responsibilities; each crosses its inward boundary only through a narrow contract. The same diagram appears in /concepts/boundary-diagram/ — this page goes deeper on what each ring does.

%%{init: {'flowchart': {'htmlLabels': false, 'curve': 'linear', 'nodeSpacing': 60, 'rankSpacing': 70, 'padding': 14}}}%%
flowchart TD
    subgraph ring2["Ring 2 — Agent fleets"]
        F["KAHN-style fleets
diagnose · plan · draft"]
    end

    subgraph ring0["Ring 0 — PETROVA-HQ"]
        P["control plane
methodology · verbs · registry
skills · read aggregation"]
    end

    subgraph ring1["Ring 1 — Consumer repos"]
        R["kahn-hq, smo1-io, …
project intent · decisions
milestones · code"]
    end

    F == "verbs" ==> P
    P == "PRs" ==> R
    R -. "read-only state" .-> P
    P -. "envelopes" .-> F

    classDef peer fill:transparent,stroke-width:1px;
    classDef gate fill:#c8631f,stroke:#7a3a10,color:#fffaf2,font-weight:600;
    class F,R peer;
    class P gate;

Ring 0 — the control plane

Section titled “Ring 0 — the control plane”

Lives at: petrova-codes itself.

Owns: methodology that’s identical across the petrova line — META-RULES, agent fleet shape, prompts, verb schemas, the registry, the CLI, the skills, the integration contracts, the shared docs/site/.

Doesn’t own: project intent, project decisions, project milestones. None of these appear in Ring 0 except as references.

Ring 0 is intentionally narrow. It contains how to do work; the what of any specific project lives elsewhere.

Ring 1 — consumer repos

Section titled “Ring 1 — consumer repos”

Lives at: each registered repo (kahn-hq, smo1-io, future additions).

Owns: the project itself. North-star intent, decision ledger, milestones, findings, code. Subagent roster (each consumer’s AGENTS.xml is its own).

Doesn’t own: the verb surface, the registry, the methodology prompts. It receives those by reference (via submodule, vendor, or documentation projection).

Each Ring 1 repo is sovereign over its content; PETROVA-HQ never reaches into Ring 1 unsolicited.

Ring 2 — agent fleets

Section titled “Ring 2 — agent fleets”

Lives at: wherever the fleet runs (a CI job, a local agent session, a long-running agent service).

Owns: diagnostic capability, planning, drafting proposed changes. The fleet’s judgment lives here — what to fix, how to sequence, when to escalate.

Doesn’t own: the action surface. A fleet that wants to act calls a verb; it does not edit Ring 1 directly.

Ring 2 is the ring most likely to be plural — you might have one fleet for diagnostics, another for implementation, another for review. Each gets its own fleet:<id> actor identity.

Why three rings and not two?

Section titled “Why three rings and not two?”

A fleet calling GitHub’s API directly would be a two-ring shape (fleet, repo). Ring 0 sits between them because:

  • The verb surface is narrower than the GitHub API. Nine verbs vs hundreds of endpoints. The narrowness is the audit trail.
  • The same verb surface serves humans + fleets identically. Without Ring 0, humans would shell out to gh and fleets would call Octokit, and the discipline would diverge. With Ring 0, both go through the same typed pipeline.
  • Cross-repo visibility lives somewhere. Aggregation (dashboard, status) is read-only Ring 0 functionality that doesn’t fit cleanly in either Ring 1 or Ring 2.

See also

Section titled “See also”