Why one operator can run thousands of Solutions on it
In plain language
The thing that makes Solution number 1,000 as safe and as cheap to run as Solution number 1 is that the properties that matter — isolation, cost truth, ceilings, idempotency, versioned configuration, operations, governed change — are properties of the substrate, not per-Solution work. Each line below is shipped code, and where it has a production event behind it, that is said.
Tenancy is enforced at the read path, fail-closed
Every Solution, corpus, grant and run carries its owning tenant. Retrieval computes the allowed source set from pure authority and refuses outside it; an empty allowed set is an honest empty answer, never a leak. Leak rigs run in CI; the isolation suite blocks deploys. The thousandth tenant is isolated by the same rows and the same filter as the first.
→ Per-tenant knowledge · INV-KNOW-01…08, INV-TEN-01…05
Every run is attributed and costed exactly
Run → Solution → configuration version → tenant, resolved server-side and stamped on the run record, the cost record and the ledger entry; cost is bound to the rate in effect at write time. Per-Solution economics are read off the ledger, not estimated. Production events: single runs attributed end-to-end at sub-cent precision on both buffered and streamed lanes; a 105-second durable job reconciled to the exact dollar.
→ Solutions · Trust & operations · I-11…I-18, I-25, ADR-0041
Ceilings are per tenant and per capability
Cost ceilings and rate quotas are typed refusals decided before a provider is called, scoped globally, per tenant or per workflow, per run, day or month, idempotency-aware so a redrive cannot burn through a quota twice. Ingestion has a per-document and a per-tenant daily ceiling. API quotas are per credential. Recipient allow-lists and review gates bound outward actions. A runaway Solution stops itself, and the refusal is on its ledger row.
→ The AI runtime · ADR-0022, INV-CST-01…05
Idempotency and durable jobs
Every outward effect has an idempotency key computed by the framework; event handlers, ledger writes, jobs, webhooks, timers and reconciliation share one primitive with one state machine. Long work runs as durable jobs with declared retry, timeout and dead-letter targets; drift is detected and repaired with recovery evidence. Retries are safe by construction, which is what lets a small team run many Solutions without watching each one.
→ Execution primitives · ADR-0015
Versioned, pinned configuration
A Solution pins its Capabilities to explicit published versions; a Capability version is immutable; activation is a pointer move with a ledger row and evidence. Platform upgrades ship beside running Solutions, never under them: lockstep substrate releases, exact version pins, forward-only migrations that cannot touch replay truth, and consumer mirror suites gating every upgrade.
→ Release governance · I-3…I-5, ADR-0016, ADR-0033, ADR-0041
Operations are built in
Dead-letter queues with alarms, per-function error alarms, error-log alarms, every alarm mirrored into the ledger, permanent-failure marking, poison-message drills, quarterly recovery drills with ledgered evidence, WAF at the edge, least privilege per function, structured correlated logs. Offboarding is a rehearsed operation that erases fifteen categories in a fail-closed order and retains the ledger. Production events: a poison drill that caught and fixed a real defect; offboarding rehearsed before the first client corpus.
Change is governed by a kernel, not by people remembering
Every production write — provision, suspend, restore, retire, grant, revoke, publish — is a registered operation: pure plan, dry-run envelope with a plan hash, approval class enforced by the kernel, execute that refuses stale plans, mandatory verify, one ledger entry. Machine actors may plan; only humans approve. The CLI and our API are the same implementation. This is the mechanism that turns "a human running a script per Solution" into an operation any authorised client can invoke safely.
→ The Governed Operation Kernel · ADR-0040
One contract for the first-party product and every client
The Front Door and every client's software run on the same published v1 contract of our API; a Solution is composition over published packages, not new infrastructure. Tenant-relative knowledge binding means one authored Capability serves many clients against each client's own corpus. Adding a Solution is a governed provision, not a deployment.
→ Our API · mag-composition · ADR-0028, INV-KNOW-04
Why this is the right foundation
Everything on this page is a property of the platform that a Solution inherits by existing on it. Matter & Gas does not re-solve isolation, cost, audit, retries, ceilings or change control per client; it composes a Solution from published parts and provisions it through the kernel. That is what "the boring foundational work is done" means in code: the next thousand Solutions are built on top of it, not beside it.