Trust domains

A trust domain is defined by what it is permitted to be wrong about, not by which machine it runs on. There are three, and no code belongs to more than one.

sut

Your repository, running. Assumed fully hostile. It holds the checkout and the real services it needs. It never holds a control-plane credential, the signing key, or object-storage credentials, and it reaches the network only through the interceptor, which denies by default.

oracle_synthesis

Where a proof program is written. Assumed persuadable rather than hostile. It can install packages, read documentation and run tools — and it is denied every capability that could record an outcome. It cannot sign anything and it never gets the repository as a working tree.

oracle_runner

Trusted code reading hostile bytes. It holds the validated program and the evidence, addressed by hash. It has no network interface, installs nothing, calls no model, and does not get a clock it was not handed.

The control plane is deliberately not a fourth domain. It issues the grants; it is the party the domains are contained from. Signing is not a capability at all, and is granted to no domain.

The obvious simplification is to let the thing that writes an oracle also run it. That is precisely how a signed PASS gets manufactured without anyone lying.

Synthesis is allowed to install packages, and the package it chooses is influenced by text derived from your repository. A package can execute code at interpreter start, before any oracle runs, and quietly rebind the comparison the oracle depends on. The program is still hashed, still readable, still published — and the comparison performed is not the comparison the hash covers. Every structural check would pass, because every structural check is about the program's source and none is about the interpreter's state.

Separating the two makes that attack require compromising a domain that installs nothing and reaches nothing.

Every capability grant names exactly one domain. There is no grant scoped to “the run”, and nothing is granted to all three. A capability needed in two domains is two grants, budgeted and refused independently.

Grants are derived, not written by hand: they are a function of what the claim permits, the frontier, the environment contract and the oracles in play. The set is recorded in the signed run manifest, so what a run was allowed to do is part of what you can replay.

A refused call is recorded as evidence, not as a log line, with the capability, the domain, a hash of its inputs and a typed reason: not granted, constraint violated, budget exhausted, or wrong domain.

The agents Certus runs inside your sandbox hold sut grants, even though Certus wrote them, because they share a machine with your code. Compromising one of them yields the sut grant set and nothing more.

The Substrate view names the trust domain of each sandbox. In normal operation it is sut on both sides and there is nothing to do about it — the value is there so that a run which somehow had different containment is visible rather than implied.

Domains never call each other. Every hand-off between them is a write into content-addressed storage and a read back by hash. That is why debugging “the oracle did not see the file” is answered from digests rather than by listing a directory: there is no shared filesystem to list.

A refusal with reason “wrong domain”

A Certus derivation fault, not a repository problem. An underivable grant is meant to be caught when the plan is compiled, not when it runs.

Refusals rising run over run

Report it. A settled repository should need very few. The remedy is never to widen a policy locally.

A trust domain you did not expect

Open the run manifest. The grant set is part of what was signed, so what the run could reach is a matter of record.