Bitspark constellation

ARCHITECTURE

Architecture

One promise, a stack of questions, an evidence loop, and a component lifecycle — how the constellation is put together.

In one sentence

Every system answers one question; together they turn a claim into a re-checkable fact on a public record — and, as candidate theory, a declaration into a running, observed component.

The one promise

Software written later should be able to safely use software written earlier — through evidence the substrate can check. The architecture is what makes that promise concrete: a vertical stack of systems, each answering exactly one question, composed so that a protected action becomes an account any party can re-verify.

Nothing here is a private integration, a central registry, or ambient trust. Each layer adds one checkable thing, and the layer above reasons over it.

The stack of questions

The substance systems don't sit side by side — they stack, each answering one question and building on the ones beneath it. Two orthogonal layers (design, atlas) sit under the whole.

WHERE IT SITS ontos logos thesmos stele arche ← ontos — of that which is ← logos — the account of what is ← thesmos — the law laid down ← stele — the inscribed public record ← arche — origin, first principle design · atlas orthogonal infrastructure — under the whole stack, not in it
WHERE IT SITS ontos logos thesmos stele arche ← ontos — of that which is ← logos — the account of what is ← thesmos — the law laid down ← stele — the inscribed public record ← arche — origin, first principle design · atlas orthogonal infrastructure — under the whole stack, not in it

Where each system sits — the substance spine, floor to top. Generated by atlas diagram stack.

  1. ontos — What is there? the shared vocabulary of values everything reasons over
  2. logos — What follows? reasoning that arrives with a re-checkable account
  3. horos — What is well-formed? the shapes a value of a kind must take
  4. thesmos — Who may? authority answered as a proof anyone can re-verify
  5. stele — What is on the record? the public fact-record runtime
  6. arche — What gets admitted? the authority that admits a fact by checking a proof

The evidence loop

Everything the substrate does reduces to one move: admit a protected action at a gate whose account any party can re-check.

  1. a participant makes a claim
  2. it produces an account — a structured, re-checkable record of why the claim holds
  3. the account is admitted at a gate: admissible(actor, verb, operand, evidence)
  4. the fact enters the public record
  5. the record is projected so any rightful challenger can re-check the account

the search / check split

Finding the evidence may be expensive, heuristic, even LLM-assisted; verifying it must stay small, deterministic, and portable. That asymmetry lets the edges reason in open-ended ways while the core stays safe.

The component lifecycle

How a declaration becomes a running, observed component — the skeleton the upper systems are growing toward.

  1. declaration — what the component is and affords
  2. artifact — the built, addressable thing
  3. desired state — what should be running
  4. runtime effect — the live instance
  5. observation — what is actually true of it

candidate theory

Capability (what a thing affords and requires) and realization (how a declaration becomes a running effect) are candidate theories, not settled design.

Settled base, candidate seams

Settled base

built

The stack (ontos → arche) and the evidence loop are built and running — values, reasoning, form, authority, the record. The dashboard tracks each member's real state.

Candidate seams

candidate theory

Capability and realization — the component lifecycle above — are still being worked out in the substrate theory track, not yet committed design.

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

GitHub