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 deixis ontos logos horos archon thesmos stele ← deixis — pointing, showing ← ontos — of that which is ← logos — the account of what is ← horos — the bound that defines ← archon — the officeholder; the one who bears the office ← thesmos — the law laid down ← stele — the inscribed public record design · atlas orthogonal infrastructure — under the whole stack, not in it
WHERE IT SITS deixis ontos logos horos archon thesmos stele ← deixis — pointing, showing ← ontos — of that which is ← logos — the account of what is ← horos — the bound that defines ← archon — the officeholder; the one who bears the office ← thesmos — the law laid down ← stele — the inscribed public record 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 — each write admitted 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 → stele) 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