ADR 0001 — Rings, not layers
ADR 0001 — Rings, not layers
Section titled “ADR 0001 — Rings, not layers”Date: 2026-05-07 Status: Accepted Strategic frame: TapPass Strategy Memo v3 §06 (Pillar 1: Enforcement Plane)
Context
Section titled “Context”Earlier drafts of the architecture used "5 layers" terminology for the enforcement positions: gateway / mcp / codemode / harness / kernel. A flat list, treated symmetrically.
The strategy memo uses "3 rings + 2 cross-cutting layers" — a more structurally honest split.
The flat "5 layers" model conflated:
- In-process enforcement positions — which sit inside the agent's process and depend on what the surrounding sandbox can enforce.
- Cross-cutting interception layers — which sit between processes and are always compulsory.
These are structurally different and should be named differently:
- Rings are inside the agent's process (harness / kernel / interpreter). Each ring's enforcement depends on what the agent's runtime supports — cooperative for harness (the runtime checks itself), compulsory for kernel (the OS rejects regardless), narrow for interpreter (only protects code the agent writes).
- Cross-cutting layers are between processes (LLM gateway, MCP broker). Always compulsory, always reachable, no runtime-specific cooperation needed.
Decision
Section titled “Decision”Adopt the strategy memo's framing:
- Three rings (in-process): harness, kernel, interpreter.
- Two cross-cutting layers (between processes): LLM gateway, MCP broker.
- Total: 5 enforcement positions organized as 3 + 2 (not flat 5).
Consequences
Section titled “Consequences”- Concept-cards use rings/cross-cutting terminology consistently (already updated).
- Components folder has
q09-rings-and-cross-cutting/— stale folder name. Mechanical fix in next consistency pass. - Vision doc (
governed-agents-architecture.md) uses "5 layers" in many places. Terminology consistency pass pending. - The bypass matrix (defense in depth) is unchanged in substance — same 5 enforcement positions catch the same bypass attempts. Just reorganized as 3+2.
- The "depth" claim sharpens. "We have 3 in-process rings and 2 cross-cutting interception layers" is more precise than "we have 5 layers." Buyers reading either statement now understand the structural distinction.
Alternatives considered
Section titled “Alternatives considered”Keep "5 layers" as flat model
Section titled “Keep "5 layers" as flat model”Rejected. Misses the in-process / between-process distinction. Flat lists hide structural truths.
Use just "3 rings" and treat gateway/MCP as part of harness ring
Section titled “Use just "3 rings" and treat gateway/MCP as part of harness ring”Rejected. Gateway and MCP intercept between processes — a fundamentally different enforcement position from anything happening inside the agent. Folding them into harness loses the compulsory-vs-cooperative distinction the strategy memo's framing makes precise.
Use "3 layers + gateway" (treat gateway as cross-cutting but MCP as part of harness/tool ring)
Section titled “Use "3 layers + gateway" (treat gateway as cross-cutting but MCP as part of harness/tool ring)”Rejected. MCP broker is structurally the same as LLM gateway — it intercepts between processes. The strategy memo's vector 06 (MCP Governance as parallel workstream) confirms MCP broker is not a ring but a cross-cutting concern.
Migration path
Section titled “Migration path”| File | Action | Status |
|---|---|---|
concept-cards/ | Use rings/cross-cutting terminology | ✅ done 2026-05-07 |
components/q09-rings-and-cross-cutting/ | Folder name already aligns with new framing; component cards aligned to per-aspect Compiled Policy | ✅ done 2026-05-08 |
architecture/strategic/governed-agents.md | Replace "5 layers" → "3 rings + 2 cross-cutting" wherever the structural distinction matters | ✅ done 2026-05-08 |
architecture/strategic/enforcement-layers.md | Full rewrite as "Enforcement Positions — 3 Rings + 2 Cross-Cutting Layers" | ✅ done 2026-05-08 |
architecture/strategic/gateway.md | CLI integration tiers Layer 0/1/2 → Tier 0/1/2; §5 reframed as enforcement positions | ✅ done 2026-05-08 |
build/roadmap-2026-h2.md | "Layered keyring" → "Compiled Policy" | ✅ done 2026-05-08 |
References
Section titled “References”- TapPass Strategy Memo v3 §06 — Pillar 1: Enforcement Plane (rings & targets)
../concepts/enforcement-layers-taxonomy.md— original taxonomy concept../concept-cards/keyring.md— manifest aspect → enforcement position mapping0003-manifest-by-aspect.md— related decision (manifest organized by aspect, not by ring)