Diff: substrate/single-boundary-compute-discipline
From 9d8533d to 9d8533d
+0 / −0 lines
| Before | After |
|---|---|
| --- | --- |
| schema: foundry-doc-v1 | schema: foundry-doc-v1 |
| title: "Single-Boundary Compute Discipline" | title: "Single-Boundary Compute Discipline" |
| slug: single-boundary-compute-discipline | slug: single-boundary-compute-discipline |
| category: substrate | category: substrate |
| type: topic | type: topic |
| quality: published | quality: published |
| short_description: "Every AI inference request in a Foundry deployment routes exclusively through the Doorman, with bypass structurally prevented at the kernel level." | short_description: "Every AI inference request in a Foundry deployment routes exclusively through the Doorman, with bypass structurally prevented at the kernel level." |
| status: active | status: active |
| bcsc_class: public-disclosure-safe | bcsc_class: public-disclosure-safe |
| last_edited: 2026-05-01 | last_edited: 2026-05-01 |
| editor: pointsav-engineering | editor: pointsav-engineering |
| cites: [] | cites: [] |
| paired_with: single-boundary-compute-discipline.es.md | paired_with: single-boundary-compute-discipline.es.md |
| --- | --- |
| The **Single-Boundary Compute Discipline** is the structural rule that all AI inference traffic in a Foundry deployment passes through one and only one boundary point: the Doorman (`service-slm`). No process, session, or service reaches an inference tier — local, GPU burst, or external API — except through this boundary. | The **Single-Boundary Compute Discipline** is the structural rule that all AI inference traffic in a Foundry deployment passes through one and only one boundary point: the Doorman (`service-slm`). No process, session, or service reaches an inference tier — local, GPU burst, or external API — except through this boundary. |
| The discipline encodes Doctrine claim #43. It is not a preferred-path routing convention that allows bypass by configuration; it is enforced at the kernel and secret boundaries so that no other process on the system can reach inference compute. | The discipline encodes Doctrine claim #43. It is not a preferred-path routing convention that allows bypass by configuration; it is enforced at the kernel and secret boundaries so that no other process on the system can reach inference compute. |
| ## Why one boundary | ## Why one boundary |
| A single boundary makes four properties structurally guaranteed rather than policy-dependent: | A single boundary makes four properties structurally guaranteed rather than policy-dependent: |
| **Audit completeness.** The audit ledger records every inference call. An operator asking "did AI touch this record?" inspects the ledger and receives a definitive answer. If bypass were possible, the ledger would have gaps — and a gapped ledger is inadmissible as a compliance record. | **Audit completeness.** The audit ledger records every inference call. An operator asking "did AI touch this record?" inspects the ledger and receives a definitive answer. If bypass were possible, the ledger would have gaps — and a gapped ledger is inadmissible as a compliance record. |
| **Corpus completeness.** The apprenticeship substrate captures every Doorman-mediated call as a training tuple. Bypass produces no shadow brief. The training corpus has gaps, and those gaps permanently degrade the quality of the per-tenant adapter that accumulates from the corpus. | **Corpus completeness.** The apprenticeship substrate captures every Doorman-mediated call as a training tuple. Bypass produces no shadow brief. The training corpus has gaps, and those gaps permanently degrade the quality of the per-tenant adapter that accumulates from the corpus. |
| **Cost control.** Budget caps and kill-switches operate at the Doorman boundary. Bypass routes around the cap. A deployment with a monthly inference budget has no enforceable budget if bypass is possible. | **Cost control.** Budget caps and kill-switches operate at the Doorman boundary. Bypass routes around the cap. A deployment with a monthly inference budget has no enforceable budget if bypass is possible. |
| **Sovereignty.** API keys for external providers and the bearer token for GPU burst capacity live exclusively in the Doorman's environment. No other process holds these credentials. When a key is rotated or revoked, the change happens in one place. | **Sovereignty.** API keys for external providers and the bearer token for GPU burst capacity live exclusively in the Doorman's environment. No other process holds these credentials. When a key is rotated or revoked, the change happens in one place. |
| ## Four enforcement mechanisms | ## Four enforcement mechanisms |
| The single-boundary discipline is structural, not policy: | The single-boundary discipline is structural, not policy: |
| **Bearer-only-in-Doorman.** All inference credentials — the GPU burst bearer token and all external provider API keys — exist only in the Doorman's environment file. No cluster session has read access to them. Without credentials, a bypass attempt fails at the authentication layer. | **Bearer-only-in-Doorman.** All inference credentials — the GPU burst bearer token and all external provider API keys — exist only in the Doorman's environment file. No cluster session has read access to them. Without credentials, a bypass attempt fails at the authentication layer. |
| **Firewall.** The GPU burst instance accepts inbound connections only from the Doorman's host IP. External API provider endpoints have rate limits and audit visibility only at the Doorman. Network-level enforcement is a second structural layer. | **Firewall.** The GPU burst instance accepts inbound connections only from the Doorman's host IP. External API provider endpoints have rate limits and audit visibility only at the Doorman. Network-level enforcement is a second structural layer. |
| **UID-owner iptables on the local tier.** The local inference server binds to a loopback address and accepts connections only from the Doorman process UID, enforced via iptables on the kernel output chain. Any other process on the same machine attempting a direct connection is dropped at the kernel boundary. | **UID-owner iptables on the local tier.** The local inference server binds to a loopback address and accepts connections only from the Doorman process UID, enforced via iptables on the kernel output chain. Any other process on the same machine attempting a direct connection is dropped at the kernel boundary. |
| **Startup verification.** On boot, the Doorman verifies that its GPU burst bearer token is present when a burst endpoint is configured, and refuses to start with an unset bearer. Misconfiguration cannot accidentally allow burst traffic to flow without audit. | **Startup verification.** On boot, the Doorman verifies that its GPU burst bearer token is present when a burst endpoint is configured, and refuses to start with an unset bearer. Misconfiguration cannot accidentally allow burst traffic to flow without audit. |
| ## What callers send | ## What callers send |
| The Doorman exposes a standard OpenAI-compatible HTTP interface. Callers — whether a task session, the operator TUI, or a customer-built agent — send requests to the Doorman's local binding. The Doorman selects the appropriate compute tier, assembles graph-grounded context (see [[knowledge-graph-grounded-apprenticeship]]), routes the request, records the audit entry, and returns the response. | The Doorman exposes a standard OpenAI-compatible HTTP interface. Callers — whether a task session, the operator TUI, or a customer-built agent — send requests to the Doorman's local binding. The Doorman selects the appropriate compute tier, assembles graph-grounded context (see [[knowledge-graph-grounded-apprenticeship]]), routes the request, records the audit entry, and returns the response. |
| This interface is also the MCP gateway endpoint (see [[mcp-substrate-protocol]]). There is no separate path for MCP clients. | This interface is also the MCP gateway endpoint (see [[mcp-substrate-protocol]]). There is no separate path for MCP clients. |
| ## Relationship to the three-ring architecture | ## Relationship to the three-ring architecture |
| The Doorman is the entry point to Ring 3. The [[three-ring-architecture]] makes Ring 3 structurally optional — a deployment may operate without AI inference entirely and the deterministic Ring 1 and Ring 2 services remain fully functional. The single-boundary discipline is what makes that optionality safe: because all inference passes through one point, disabling that point produces a clean degraded state rather than a partially-bypassed one. | The Doorman is the entry point to Ring 3. The [[three-ring-architecture]] makes Ring 3 structurally optional — a deployment may operate without AI inference entirely and the deterministic Ring 1 and Ring 2 services remain fully functional. The single-boundary discipline is what makes that optionality safe: because all inference passes through one point, disabling that point produces a clean degraded state rather than a partially-bypassed one. |
| ## Composition | ## Composition |
| This discipline composes with several other Doctrine claims. The Knowledge-Graph-Grounded Apprenticeship (claim #44) depends on it: graph context is assembled at the Doorman before dispatch; bypass means ungrounded inference. The MCP-as-Substrate-Protocol (claim #46) designates the Doorman as the MCP gateway; bypass breaks the MCP graph. The Two-Bottoms Sovereign Substrate (claim #34) enforces customer sovereignty at the Doorman boundary; bypass is a sovereignty leak. | This discipline composes with several other Doctrine claims. The Knowledge-Graph-Grounded Apprenticeship (claim #44) depends on it: graph context is assembled at the Doorman before dispatch; bypass means ungrounded inference. The MCP-as-Substrate-Protocol (claim #46) designates the Doorman as the MCP gateway; bypass breaks the MCP graph. The Two-Bottoms Sovereign Substrate (claim #34) enforces customer sovereignty at the Doorman boundary; bypass is a sovereignty leak. |
| ## See Also | ## See Also |
| - [[knowledge-graph-grounded-apprenticeship]] — graph grounding assembled at the Doorman before each request | - [[knowledge-graph-grounded-apprenticeship]] — graph grounding assembled at the Doorman before each request |
| - [[mcp-substrate-protocol]] — the Doorman as MCP gateway | - [[mcp-substrate-protocol]] — the Doorman as MCP gateway |
| - [[substrate-without-inference-base-case]] — deterministic-only operation when the Doorman's inference tiers are unavailable | - [[substrate-without-inference-base-case]] — deterministic-only operation when the Doorman's inference tiers are unavailable |
| ## References | ## References |
| 1. Doctrine claim #43 — Single-Boundary Compute Discipline (ratified v0.1.0). | 1. Doctrine claim #43 — Single-Boundary Compute Discipline (ratified v0.1.0). |
| 2. `conventions/three-ring-architecture.md` — Ring 3 structural optionality. | 2. `conventions/three-ring-architecture.md` — Ring 3 structural optionality. |
| 3. SYS-ADR-07 — structured data never routes through AI; the sanitise-outbound discipline. | 3. SYS-ADR-07 — structured data never routes through AI; the sanitise-outbound discipline. |