Bitspark constellation
accepted source ↗

ADR 0029 — the adstrate is the integration runtime (kosmos); providers are connected services

  • Status: accepted
  • Date: 2026-06-18
  • Builds on: 0028 (single root; custody-vs-truth), 0017 / 0018 (the adstrate definition this reframes)
  • Amends: 0017 (adstrate = referent tier → adstrate = integration runtime), 0018 (layer: "adstrate" semantics; flags the Greek/Latin line)
  • Relates: 0016 (kosmos joins as the runtime over stele), 0021 / 0022 / 0024 (corpus, now reframed from "the adstrate" to a provider), kosmos docs/model.md

The "adstrate" is not a tier of off-record referents (corpus · cell · wire) — it is the integration / realization runtime that does what the record only describes. In the constellation that runtime is kosmos: a custodial fluency lens that holds clients' keys and runs all the key/signing/proof/space machinery so clients hold nothing and prove nothing, and that wields real, delegated, law-bounded authority — its own service grant plus every custodied key (never "no authority of its own"). Concrete realizers (content, state, flow) are generic providers / connected services behind surfaces kosmos brokers — kosmos owns the provider contract, not any specific provider, so the model names none. Three backing stores follow, by kind of thing: the record (facts) → stele; kosmos-managed concerns (accounts, keys, policy, sessions) → kosmos's own state; payload (bulk / mutable / moving) → a provider. This reframes 0017 / 0018: corpus becomes a provider, tabula/cursus unbuilt candidates, and adstrate names the runtime.

Context

0017 named the adstrate as a tier of off-record referent categories — content (corpus), state (tabula/cell), flow (cursus/wire) — beside the substrate; 0018 made it a topology layer: "adstrate" and a Latin naming convention. Both are accepted and still drive the topology, glossary, dashboard, and docs/model.md.

Since then kosmos was built, and its model (docs/model.md §8/§11) reframes that tier: the adstrate is the live realization / integration layer (kosmos); corpus is a provider of the content surface; state/flow are open candidate providers, "none is a tier." §11 records the reconciliation as owed to atlas.

Reiterating the model sharpened it further:

  • kosmos is a custodial fluency lens — it absorbs all the key/signing/proof/space work so clients only authenticate and state intent.
  • "user" is a kosmos account, not a substrate entity (the substrate knows only identities, grants, spaces).
  • kosmos holds real, delegated authority — its docs/model.md §7.1 / README line "holds no authority of its own" is wrong (it holds its genesis service grant and every custodied key; what it cannot do is redefine truth — 0028 §3).
  • Providers must stay generic — singling out corpus in the model muddies the concept that kosmos is provider-agnostic.

So 0017's "adstrate = referent tier" is the outdated model; this ADR reconciles atlas to the current one.

Decision

1. The adstrate is the integration/realization runtime, not a referent tier. It is the layer that does what the substrate only describes — resolve → judge → enforce → mediate. This amends 0017 §1: the adstrate is no longer "corpus · cell · wire."

2. That runtime is kosmos — a custodial fluency lens. kosmos holds clients' keys and runs the entire key/signing/proof/space apparatus, so clients hold nothing and prove nothing: a client authenticates and states intent; kosmos resolves ID → Surface, obtains the verdicts, signs, and writes facts to stele on the client's behalf. Builds on 0028.

3. kosmos wields real, delegated, law-bounded authority. Its own genesis service grant (root → service) plus the keys of every account it custodies plus the power to issue and revoke grants. The phrase "kosmos holds no authority of its own" is scrapped wherever it appears (kosmos README invariant 1 / docs/model.md §7.1). The true constraint is 0028 §3's split: power-of-agency, never power-over-truth — kosmos can act, grant, and revoke, but cannot make the law admit a false thing, and every act is an auditable fact.

4. Providers are generic connected services; the model names none. The realizable surfaces are exactly what the immutable-small-fact substrate cannot bebulk, mutable, moving (content / state / flow) — each realized by a provider kosmos brokers as (space, core-service) → global | delegated, materialized on demand. kosmos owns the provider contract, not any specific provider. The constitutional triad of 0017 dissolves: there is no fixed set of named adstrate members, only providers behind surfaces.

5. "user" is a kosmos account, not a substrate entity. The substrate knows only identities (keys), grants, spaces. A kosmos account is account → List<(identity, private key)>; kosmos issues grants to identities, on request, within account policy; an account's identities are substrate-unlinkable. The substrate never gains a "user" concept.

6. Backing store is by kind of thing, not by whose key signs. Three stores:

  • the record — facts (identities, grants, bindings; both lens writes and kosmos's own issuance) → stele;
  • kosmos-managed concerns — accounts, key management, policy/quotas, sessions (secret, unlinkable, policy/resource, or transient) → kosmos's own state;
  • payload — bulk/mutable/moving → a provider. This sharpens kosmos README invariant 3: kosmos is fact-derived/stateless over the record and stateful over its managed concerns. Managing a concern ≠ the facts it emits.

7. Account policy is resource, not authority. Caps like "≤ N top-level subspaces" are not substrate-expressible (monotone authority law can't count — the resource outsider, 0028 consequences) and are account-keyed (the account is invisible to the substrate), so kosmos — the issuer — must enforce them. Permission to create = a substrate grant; how many = kosmos policy.

8. Topology & naming reconciliation.

  • Register kosmos as a member — the integration runtime over stele.
  • Reclassify corpus from an adstrate-tier member to a provider (a connected service); its space-governed access (0021 / 0022 / 0024) is unchanged and is exactly what makes it delegable.
  • Defer / re-tag tabula & cursus — they are unbuilt candidate providers, not standing members; they re-enter only when a concrete need materializes a provider.
  • Re-point layer: "adstrate" and the glossary adstrate entry to the runtime sense.
  • Flag the 0018 Greek/Latin convention (kosmos is Greek but is the adstrate) for a follow-up decision — noted, not forced here.

Consequences

  • corpus: keep the service, drop the crown. It becomes the global default content provider — swappable, delegable per subtree — rather than a constitutional tier member. No code change is implied by this ADR; it is a classification + concept change.
  • tabula / cursus deregister/defer. A true mutable cell and live flow remain genuine doings the substrate can't perform — they are not "reducible to facts" — but nothing needs a provider for them yet, so they are candidates, not members. (Avoids the 0017 §4 trap of conflating immutable-fact-folds with mutable state.)
  • kosmos-repo edits follow (separate PR): scrap "no authority of its own"; elevate the fluency-lens + custodian framing; add the account/identity model and the three-way boundary; remove corpus/tabula/cursus naming → generic "providers / connected services."
  • Topology + diagram regen (register kosmos, reclassify corpus, defer tabula/cursus) is mechanical downstream work; per [[atlas-registry-change-regen-diagrams]] a registry change re-stales the SVGs, so regen against the pinned DESIGN_REF.
  • The Greek/Latin naming convention needs a follow-up (0018) — either kosmos is the named exception, or "Latin = providers/connected services" (not "= adstrate"). Out of scope here.
  • No change to the substrate's space-governed access model. This ADR is about who is the adstrate and where state lives, not how content is reached.

The Bitspark constellation — how the systems are built and relate.

GitHub