Bitspark constellation

THEORY · EXPLORATORY

0003 — the candidate theories

exploratory

2026-06-07

  • Status: exploratory
  • Date: 2026-06-07
  • Governed-by: ADR 0013
  • Builds on: 0001, 0002

The settled base is two theories — authority and form. The strongest candidates beyond them are two more — capability and realization — and they are not the same as "an artifact theory." Three further concerns (resource, federation, time) keep surfacing and are recorded here as open, not adopted.

The modal heuristic

Each theory answers a distinct modal question about an admission. This is a search heuristic for missing theories, not a proof of completeness (0004): ask which modal questions safe late-bound use needs, and which are not yet answered.

Theory Modal question Judgment Status
ontos what is the value? structural identity medium (not a theory — the value floor)
logos what follows, re-checkably? account / check medium (not a theory — the proof floor)
thesmos may this actor do this? authorized(actor, request) base · settled
horos does this value have this form? v : T, wf(T) base · settled
capability what does this entity afford / require? provides / requires / operation candidate
realization how does a declaration become a running effect? realizes(obs, desired, host, manifest) candidate

The Greek the family might use: dynamis (capability — potential, what a thing can do) and energeia (realization — actualization, potential brought into effect). Names are deferred to repo-creation time (0004 §1); they are placeholders here.

The settled base — authority and form

thesmos answers may and owns the authority vocabulary (is_root, signed_fact, grant, authorized, coverage); horos answers is and owns the form judgments (wf(T), v : T) with descriptors that are themselves ordinary ontos values carrying their own accounts. Neither defines the other (0002, Test 2). These are not in question; they are the proof that the pattern — small reserved vocabulary, checkable judgments, declarative extension — works.

Candidate A — capability (affordance / interface)

What can this entity be used for, and what does it need? — the actual integration surface.

This is the most important missing layer for late binding, and the one most easily overlooked, because it hides in the seam between form and authority. horos tells you the shape of a value; it does not tell you that an entity offers an operation, requires a cell, emits on a wire, consumes a protocol, or needs authority to read a secret. thesmos tells you whether an actor may perform a request; it does not tell you which requests are meaningful for an entity. Affordance is neither shape nor permission — it is irreducible over both (a non-conservative extension; 0002).

Sketched judgments:

interface(I)                         capability(C)
provides(Entity, C)                  requires(Entity, C)
operation(C, Op, InputType, OutputType, Effect)
message(C, WireProfile, PayloadType) state(C, CellProfile, ValueType)
requires_authority(C, ReqPattern)    compatible(C1, C2)

It depends on horos for the type slots and thesmos for the authority patterns, and replaces neither. Its job is to make "what this thing can do" substrate-visible and checkable enough for an unknown future participant to bind to it without prior private knowledge.

Candidate B — realization (declaration → running reality)

How does an immutable declaration become an effectful, running, or produced thing?

arche RFC 0004 already names the common skeleton, which the browser app-shell and the service runner grew independently:

declaration → immutable artifact → desired state → runtime effect → observation

That repeated, independently-rediscovered shape is the tell of a real theory. Sketched judgments:

artifact(A)                          program(A, InterpreterOrRuntime)
manifest(M)                          manifest_artifact(M, A)
manifest_requires(M, Requirement)    manifest_provides(M, Capability)
build_plan(P)                        builds(P, Inputs, OutputArtifact)
runtime_kind(K)                      host_supports(Host, K, Profile)
realizable(Host, M)                  deployment_plan(P, Desired, Host, M)
realizes(Observation, Desired, Host, M)

The theory defines the checkable claims around running; it does not run anything. This boundary is load-bearing and matches the RFCs: the runner is not a primitive — it is a fact-driven occupant (arche RFC 0001); a runtime host is an occupant that composes facts + CAS + grants + a local runtime, not a new effect surface (arche RFC 0004). The implementation is an occupant; the instantiation semantics may still be constitutional. A realization theory makes a runner's actions interpretable and accountable without moving the runner into the core.

"Artifact" is not the irreducible semantic — realization is

The hesitation around the word "artifact" is justified, and it is diagnostic of the seam. Lay out three distinct things:

  • CAS is the byte mechanism — hash-indexed, space-agnostic.
  • An artifact is the immutable content as a fact-mediated, space-scoped concept (arche RFC 0002: CAS is global, the artifact binding is fact-mediated). Necessary, but passive — bytes plus facts can already say "these bytes exist."
  • A program is an artifact under an interpretation relation; an instance is a program realized in an environment.

So the irreducible thing a program adds over "a formed value" is not its shape (horos already has that) and not its bytes (CAS already has those) — it is behavior brought into effect: the realization of potential into actuality. That is why artifact is not yet proven irreducible as its own theory (a noun, not a judgment): for now there is no standalone "artifact theory" — artifact is the immutable object that the realization theory reasons over, with build plan and deployment plan folded in. A later pass may split it back out if its judgments prove non-definable from realization's (see open edges).

The open outsiders — recorded, not adopted

The challenge test (0002) surfaces three more candidates. None is adopted; each is logged so the next pass starts here.

  • Resource / scarcity"you may, but you can't afford it." Capacity is not permission and is not definable from thesmos. Quotas, leases, backpressure, CAS GC, runner admission. A serious candidate for an irreducible core theory; currently unowned.
  • Federation / translation"your proof bottoms out in a root I don't accept." thesmos assumes a root; mapping authority between polities (trust bundles, imports, cross-space proofs) is a different judgment. Needed the moment "global" is meant literally — and since the constellation's thesis is no central authority, this is the most consequential open outsider, the leading open question for "global" rather than a peripheral maybe.
  • Temporality / freshness"your grant was valid; it no longer is." Current lean: this is a mechanism / tier below the logical layer, not a general theory. Time is non-monotone (now, expiry, latest, absence) and would poison the monotone query/proof layer; thesmos already treats non-revocation as a freshness tier over an active-set accumulator, with the producer in stele. Freshness is required; a free-standing "time theory" is probably not. Flagged, not closed — it may instead be a modifier on every judgment (every account time-indexed) rather than a peer theory.

Two independent analysis passes each surfaced different outsiders — one found capability, the other found resource and federation. That divergence is itself mild evidence the candidate set is not yet closed (0004 §2).

Where this goes

Each candidate is gated by the two tests (0002) and the promotion path (0004 §1). No repos exist yet. ADR 0013 records capability and realization as the leading candidates and the artifact-vs-program clarification; the outsiders stay open.

Open edges

  • Capability vs realization may share a boundary: provides(Entity, C) (capability) vs manifest_provides(M, C) (realization) look alike. The working split: capability is the abstract affordance (the type), realization is the instantiation witness (the term) — dynamis vs energeia. Thin, and worth pressure-testing.
  • Whether capability needs its own descriptor language or can ride entirely on horos descriptors is unresolved.
  • Resource is the most likely next core theory; the first job is to test whether admissible can be written without a capacity premise at all.
  • Production / derivation vs runtime realization may split later: realization currently folds making (build / derivation, poiesis) and running together; if their central judgments prove non-definable from each other, artifact / production could re-emerge as its own theory.

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

GitHub