ADR 0030 — authority is fact-derived and decided once by the runtime; a provider is a pure realizer

• Status: accepted
• Date: 2026-06-18
• Builds on: 0029 (the adstrate is the integration runtime — who that runtime authorizes is what this ADR fixes), 0028 (custody-vs-truth; power-of-agency, never power-over-truth)
• Relates: 0021 / 0022 / 0024 (provider access/storage/write mechanics this places under one decider), 0013 / theory/0003 (the theories this generalizes over, incl. the open resource outsider), 0017 (the adstrate "interface in facts, payload off-record" this completes)
• Elaborated by: kosmos docs/authorization.md (the runtime-side draft) + its refinement punch-list

Every theory judgment about a provider's surface — authority (may), form (well-formed), and any future theory — is derived once, by the fact-derived lens, from the record. For a write, the substrate checks its own facts (non-delegable — it is the facts). For a provider's surface, the integration runtime (0029; kosmos) is that lens. A connected provider does not re-decide: it authenticates the runtime, serves on the verdict, and renders no theory judgment of its own — it is a pure realizer, doing only the non-theory remainder (the effect, physical conditions, peer-authentication). The runtime is the single execution site of a re-checkable judgment, not a sovereign: authority stays the facts under the law, re-runnable by anyone — centralizing where the check runs is not centralizing who decides what is true. Forcing providers to delegate forces all access policy onto the record — the one-authority model enforced by construction. Custody mode and byte-relay confidentiality are recorded open.

Context

0029 made the adstrate the integration runtime (kosmos) and the realizers (corpus, …) providers — but left unstated who authorizes a provider's surface. The built system answers it twice: corpus re-derives the read verdict itself (its MayReadWithGrants gate), and kosmos's model.md §6 explicitly allows a provider to "re-enforce … as a backstop." So one action is authorized at two fact-based sites. The open question:

• (A) the provider re-checks the subject's authority against the record itself; or
• (B) the runtime decides, and the provider serves on its verdict.

This ADR ratifies (B) — with the qualification that the runtime's decision is fact-derived: the deterministic, re-checkable judgment over the record under the law (thesmos/horos via logos), never the runtime's opinion. The reasoning, and the worked-out model, live in kosmos's docs/authorization.md; this record is the cross-cutting decision (it spans the runtime and the providers, so its seat is atlas).

Decision

1. One fact-derived judgment per action, at the fact-lens. A theory judgment is performed exactly once, from the record, by whoever owns the truth it depends on: the substrate for its own facts (a write carries a proof and stele checks it — non-delegable), the runtime for a provider's surface ("may this subject use this surface" is a pure function of the record's facts, and the runtime is the fact-lens for it).

2. A provider is a pure realizer; it delegates. A connected provider authenticates the runtime (peer authentication — §5), serves on the runtime's verdict, and renders no theory judgment of its own. It does not establish the acting principal, does not evaluate grants, does not impose form rules. corpus's own MayReadWithGrants site moves into the runtime.

3. The line is theory vs non-theory, not permission vs not. The provider renders no theory judgment of any kind — thesmos (may), horos (well-formed), and the candidate theories (capability, realization) alike; the runtime's "judge" already spans logos + horos. The provider's residual is the dynamic non-theory remainder: it shrinks as theories crystallize (resource → quota-as-policy moves to the lens, physical exhaustion stays; integrity → the fact-free content-hash may stay mechanical, attested integrity is the theory candidate). Permanently the provider's: the effect and physical conditions only. Litmus: "may P do A?" → fact-lens; "can I correctly/safely do A now?" → provider.

4. Why delegation, and why a provider must not re-decide. In increasing weight:

• (a) consumer/provider is a per-request role, not a per-entity type (the same entity is a consumer on one call, a provider on the next), so no provider has a separate policy model;
• (b) a second check derives the same verdict from the same facts — no new boundary, and it stops nothing it could be guarding against, since the runtime is the custodian and a compromised one would forge the very facts a re-check reads;
• (c) (load-bearing) sole delegation forces fact-based policy. The only thing a self-authorizing provider can add is imperative, off-record policy — a second authority that is not re-checkable and silently shadows the fact-based one. Routing every provider through the one layer that evaluates only facts forces each provider's access policy to become facts on the record. This is the constellation's one-authority model enforced by construction, not by discipline. Trust in a runtime is chosen by deployment (run your own for your subtree — 0029, 0028), never by re-checking.

5. The runtime is an execution site, not a sovereign — and authentication splits. The verdict is a deterministic, re-checkable function of (facts + law); the runtime merely runs it in one place so providers need not re-implement it, and anyone may re-run it and reach the same verdict. Power-of-agency, never power-over-truth (0028). The runtime derives and enforces the decision; it never authors policy absent from the record. Establishing the acting principal is the runtime's (authenticate → principal); a provider performs only peer authentication (verify it is talking to its accepted runtime), never principal authentication.

6. Two planes inside the runtime, kept mechanically separate. The runtime co-locates a stateful administration plane (accounts, custodied keys, grant issuance, quotas/resource policy — its own state) and a stateless fact-derived authorization switchboard. They are one binary for pragmatic reasons only: the switchboard authorizes from facts alone, never from administration state, and the separation is enforced as a dependency rule (authority ↛ accounts), not a convention.

7. Retire the backstop allowance. A provider may not "re-enforce as a backstop" (kosmos model.md §6). Re-enforcement is exactly the seam through which imperative, off-record policy re-enters; under this model a provider trusts the verdict of the runtime it was given.

Consequences

• The substrate-write path is unchanged. stele still checks its own facts; that authority is non-delegable and is not what this ADR moves.
• corpus becomes a pure content realizer. Its read-authorization (MayReadWithGrants) moves into the runtime; it keeps challenge-response, but as peer authentication only. (Implementation in kosmos + corpus.)
• kosmos model.md invariants 1 and 2 are superseded (runtime-side): "trusted by everyone" → trusted by its clients; providers delegate the re-checkable verdict; "full mediator / never-meet" → the fact-driven switchboard, with byte-relay an opt-in mode decoupled from authorization.
• Implementation roadmap lives in kosmos (docs/authorization.md + its punch-list): retire the account-derived enforce.WithinSpace, the /users/<id> home-space convention, the root-only resolver branch, and the serviceSeed mediated-write provenance bug (the record must attribute content to the principal, not the runtime); add a Principal/Signer abstraction; land the lint-enforced module boundary.
• Open — recorded, not decided:
  • Custody mode — custodial | self-custodial | hybrid. The runtime is custody-agnostic behind a Principal/Signer abstraction; which to support, and the default, is open.
  • Byte-relay confidentiality — whether the runtime reads the bytes (enforce theories on the data) or relays opaque (E2E), as an opt-in mode decoupled from authorization.
• The dynamic residual tracks the theory frontier. As resource/integrity (or others) crystallize as theories (0013 / theory/0003), their decisions migrate from "provider does it" to "the lens derives it" — no change to this ADR; it is the rule that predicts the move.
• No topology or repo change. kosmos and the providers are already registered; this ADR decides the authorization model and mints nothing.