Minimum Credible Substrate (MCS)
Minimum Credible Substrate (MCS)
Section titled “Minimum Credible Substrate (MCS)”Status: Strategic concept. The Q2 2026 ship target. Date locked: 2026-04-28 (TapPass Strategy Memo v3 §12). Why this concept exists: prevents scope creep. Without an MCS gate, every component conversation drifts toward "let's also ship X." With it, four pieces are non-negotiable; everything else is post-MCS broadening.
What it is
Section titled “What it is”Four pieces. If these ship together, the central architectural claim — "author once in Rego, render to any target, distribute by push or pull, reconcile continuously" — is provable end-to-end.
╔══════════════════════════════════════════════════╗ ║ THE MINIMUM CREDIBLE SUBSTRATE (Q2 2026) ║ ║ ║ ║ 1. Canonical Compiled Policy ║ ║ (schema-versioned, signed, stable contract) ║ ║ ║ ║ 2. At least two providers across two rings ║ ║ (e.g. Claude Code harness + ║ ║ OpenShell or nono kernel) ║ ║ ║ ║ 3. Push / pull / reconcile control loop ║ ║ (live update + boot-fetch + drift catch) ║ ║ ║ ║ 4. Agent registry / state store ║ ║ (knows desired vs. applied per agent) ║ ╚══════════════════════════════════════════════════╝Why exactly these four
Section titled “Why exactly these four”Each closes a specific gap that, individually, makes the architecture incomplete:
| Piece | Without it… |
|---|---|
| 1. Compiled Policy | "One source, many targets" is a marketing claim, not a technical reality. The Compiled Policy is what providers consume — without a stable canonical IR, every provider drifts. |
| 2. Two providers across two rings | We can't prove the substrate generalizes. One provider could be a coincidence; two across rings shows composition. |
| 3. Push / pull / reconcile | Live policy updates aren't actually live. Without reconcile, drift goes undetected and enforcement decays. |
| 4. State store | Push and pull are blind broadcasts. The control plane has no idea what's actually running. Drift detection becomes impossible. |
The MCS is intentionally minimal. Everything else (the nine scaling vectors, the dozens of additional providers, the compliance packs, the evaluation harness) layers on top — but only after MCS is provable.
Why this is the prioritization gate
Section titled “Why this is the prioritization gate”Every roadmap conversation should begin with: "is this needed for MCS or comes after?"
If a proposed feature can't answer that — that's a sign the conversation is unfocused.
If it's MCS-needed, it's Q2 priority. Drop everything else for it.
If it's post-MCS, it parallel-ships in Q3/Q4 after MCS is provable, never before.
Status of each piece
Section titled “Status of each piece”| Piece | Current state | Path to MCS |
|---|---|---|
| Canonical Compiled Policy | concept; schema in design | Lock schema Q2 W1-2; ship Q2 W3 |
| Provider 1: Claude Code (harness ring) | concept | Q2 W3-4 |
| Provider 2: OpenShell or nono (kernel ring) | OpenShell primitive shipped; provider wrapper concept | Q2 W5-6 |
| Push channel (SSE) | concept | Q2 W7-8 (after providers exist) |
| Pull endpoint (HTTP fetch + heartbeat) | concept | Q2 W7-8 (parallel) |
| Reconciler | concept | Q2 W11 |
| Agent registry / state store | concept | Q2 W7-8 |
| End-to-end demo with 3 reference customers | concept | Q2 W13 (launch) |
Target launch: end of Q2 2026 with three reference customers running governed Claude Code in three-ring + gateway mode.
What's gated against MCS
Section titled “What's gated against MCS”These are explicitly post-MCS — not shipped before MCS is provable, no matter how exciting they look:
| Post-MCS work | Quarter |
|---|---|
| Additional CLI providers (Codex, Cursor, Cline, Aider, Gemini CLI) | Q3 |
| LLM gateway expansion (Vertex AI / Gemini upstream) | Q3 |
| LibreChat plugin (server-shape harness provider) | Q3 |
| Compliance pack v1 (EU AI Act / OWASP LLM Top 10) | Q3 (parallel; not gating) |
| Authoring UX (GitOps, shadow mode, simulation) | Q3 |
| MCP broker (vector 06, parallel workstream) | Q4 |
| Element / Slack / Discord / Teams bot providers | Q4 |
| Kernel providers (gVisor, Firecracker, K8s NetworkPolicy + Gatekeeper) | Q4 |
| Pre-deployment evaluation harness + probe libraries | Q4 |
| Drift detection | Q4 |
| Marketplace v1 (3 certified policy packs) | Q4 |
| Compliance v2 (EU AI Act detail, NIST AI RMF) | Q4 |
| Cross-customer Intelligence | 2027 |
| Federation (multi-tenant cascade) | 2027 |
The MCP broker workstream is explicitly parallel per Strategy Memo §21 (Decision 2). It can start before MCS ships — but it doesn't gate MCS.
What MCS unlocks
Section titled “What MCS unlocks”Once MCS ships:
- End-to-end demo works. Policy authored in Rego → Compiled Policy derived → 2 providers + LLM gateway enforce → agent registry shows applied versions → policy change propagates within seconds. The substrate claim is no longer a slide; it's a live demo.
- Three reference customers signed with end-to-end governance. Public reference logos.
- The architectural moat is unambiguous. Every adjacent vendor has at most one ring; we have two + control loop + state store.
- Post-MCS expansion becomes parallel. Adding Codex / Cursor / gVisor / Firecracker each becomes a 2-week provider project, not architecture work. Different sub-teams can ship in parallel without coupling.
- Procurement conversations have a now answer, not a promise. "We ship governance today for Claude Code on laptops + servers, with manifest + push + reconcile." Not "we will ship..."
The first 30 / 60 / 90 days (illustrative)
Section titled “The first 30 / 60 / 90 days (illustrative)”Day 0–30 — foundation
Section titled “Day 0–30 — foundation”- Lock the Canonical Compiled Policy schema. Forward-compat guaranteed; versioned.
- Refactor OPA cascade to emit the Compiled Policy as its sole output.
- Design partner signup: 3–5 customers committed to running MCS behind an NDA.
- Internal dogfood: TapPass team itself runs every
claudeinvocation through MCS-in-progress.
Success criterion: Compiled Policy schema shipped, cascade produces it. Every TapPass engineer uses it daily.
Day 31–60 — providers and rings
Section titled “Day 31–60 — providers and rings”- Provider 1: Claude Code managed
settings.json. Round-trip tested end-to-end. - Provider 2: OpenShell YAML — refactor existing integration to consume the Compiled Policy.
- Provider 3 (parallel): macOS App Sandbox profile for laptop use without a container.
- SSE push extended to cover all rings (not just network).
- Dashboard stub showing per-agent ring status and live policy version.
Success criterion: tappass run --rings=harness,kernel claude works on macOS and Linux. A policy change propagates to both rings within 2 seconds.
Day 61–90 — interpreter ring + design-partner launch
Section titled “Day 61–90 — interpreter ring + design-partner launch”- Provider 4: monty host-function manifest.
- Codemode demo: agent writes Python, monty executes it with ring-derived capabilities.
- Reconciler closing on the state store.
- Design-partner launch: 3 customers in production with MCS, three rings, central policy.
- Post-launch: publish architecture post; announce design-partner case studies.
Success criterion: Public launch end of Q2 with three reference customers and a demo that goes end-to-end: Rego → signed manifest → three rings of enforcement → denial trace → live policy update propagates.
Why MCS deserves first-class status
Section titled “Why MCS deserves first-class status”Strategy Memo v3 §12 names MCS as the Q2 ship target. It deserves its own concept page (this file) so:
- Every prioritization conversation references it.
- Every component conversation can be measured against it ("does this ship MCS or comes after?").
- Investors / partners / new colleagues see "this is what gets shipped first" — not buried in a roadmap.
- Engineering knows what to drop everything else for.
If the team can't say "this is on the MCS critical path" — it's not on the MCS critical path. Promote it accordingly.
Where this fits in the repo
Section titled “Where this fits in the repo”| File | What |
|---|---|
| This file | MCS as concept (the four pieces, why they're load-bearing) |
../roadmap/2026-h2.md | Week-by-week MCS sequencing in Q2 + post-MCS roadmap |
../OVERVIEW.md | MCS as one of the headline moves |
../concept-cards/ | The concepts MCS depends on (Compiled Policy, Provider, Sync, Cascade) |
tappass-strategy-memo-v3.md | The strategic source-of-truth (§12 lays out MCS) |
References
Section titled “References”- TapPass Strategy Memo v3 (2026-04-28) §12 — "The four-piece MCS"
- TapPass Strategy Memo v3 (2026-04-28) §20 — "30 / 60 / 90 day sequencing"
governed-agents-architecture.md§6 (rings) and §10 (Compiled Policy)../concept-cards/keyring.md— Compiled Policy schema + provider rendering