THEORY · EXPLORATORY
0005 — one system: four strands, one kernel, one substrate
2026-09-23
- Status: exploratory
- Date: 2026-09-23
- Governed-by: ADR 0012, ADR 0013
- Builds on: 0001, 0002, 0003, 0004
- Relates: the conceptual map, the space model
The repositories around the constellation are four strands of one system, each built from a different end. The constellation built meaning from the floor up. The bitnode line built realization from the requirement down. Nightseam and the
bit*family built access and declaration outward. The agent fleet built operations where it stood. The two theories 0003 names as candidates without a repository — capability and realization — have a worked and measured candidate in the second strand: the declarative space model that bitsystem implements. The position of this essay: the whole is one kernel that composes, standing on one substrate it does not contain, with everything else declared.
This essay concerns many systems and has no single-repo owner, so by the
membership test it belongs in
atlas; by this track's house rules it states a position and its open edges, not a decision. It
changes no registry entry. Correspondences between repositories are stated as structural
recurrences with their divergences named, never as identities: of sixteen cross-repository
claims of the form "A's X is B's Y", bitlink's family study (docs/studies/family-concept-map.md)
found fourteen refuted under adversarial checking. Every claim about another repository is
pinned in Sources.
1. One ambition, stated five times
| Where | When | Words |
|---|---|---|
| atlas — the vision, 0001 | 2026-06 | "enable independently authored, future-unknown participants to become safely usable by each other through substrate-visible evidence" |
deixis — docs/VISION.md |
2026-08-07 | "a language-agnostic, hierarchical (spaces) computational model with implementations and runtime instances: one system" |
bn2-system — meta/VISION.md |
2026-09-13 | "one global Bitnode network", "comparable in scale to the internet, one layer above its connectivity" |
bitnode — VISION.md |
2026-09-13 | "The environment can use its capabilities to establish the capabilities it needs." |
bitsystem — docs/ambition/goal.md |
2026-09-18 | "Adding a new kind of work then costs the work itself — an implementation and its declarations — and nothing in the machinery that runs it." |
Asked by bitnode's archaeology whether the enduring ambition was shared computational meaning
or an environment able to establish what it needs, the operator answered: "Spontaneously, I
would say both" (archeology/RECOLLECTIONS.md, R01).
Read together, the five describe one system: a global, addressed hierarchy of spaces in which
- meaning is shared as checkable data — what a value is, what follows from it, what form it has, who may act, what happened, what holds now;
- computation is obtained by stating what must hold — the environment establishes it by composing contributed capabilities, including capabilities that establish further capabilities;
- the builders work inside it — in bitnode-old's words, "developing, running, and governing are one activity on one fabric".
2. Four strands, built from four ends
| Strand | Members | Built from | Strongest | Borrowed or missing |
|---|---|---|---|---|
| The constellation | ontos, logos, horos, thesmos, stele, archon; deixis as material; kosmos, telos, harmos, pharos; atlas, design | the floor, upward | frozen codec (ontos), running certifying kernel (logos), frozen form surface (horos), running law (thesmos), conformance vectors across languages | capability and realization have no repository (0003); kosmos, telos and harmos have had no commit since 2026-07-16 |
| The bitnode line | bn2-system (corpus, spikes), bn3-system, bitnode, bitsystem; ancestors bn-architecture, bn-bytes, bn-cells, bn-trees, bn-values, bn-wires, space-lab, tree-lab, bitnode-old | the requirement, downward | bn2's local-realization spike passed its gate; bitsystem measures a kernel against written criteria at a pinned foundation | meaning is borrowed — bitsystem's kernel matches facts through logos over ontos values; one implementation language |
nightseam and bit* |
nightseam, bitwire, bittree, bitschema, bitlink, bitverse, nightseam-cloud | the declaration, outward | a shipped generator and runtime; bitwire 0.2.0 with eight language bindings; bittree's running kernel | no reasoning: nightseam#345 declines logos and puts its own grant where thesmos stands; execution (bitengine) is planned only |
| The fleet | nightforge (ULab), nighthall, nightshift, nightfall, nightjar, aiscape, weft, llllm, l111m, bb and the bitagent repositories, agent-hub, repo-tool, bitsystem's lab | operations, in place | deployed services | logs, journals, trees and grants re-implemented locally |
The strands are indexed separately. atlas's registry lists
seventeen members, none of them from strands two to four; bitlink's docs/RELATED_REPOS.md
compares nine repositories; bitnode's archaeology pins forty-two; bitverse indexes the
bit*.dev names. No document held the whole; this one tries to, provisionally.
3. They are already meeting
Within the last seven days the strands began to cite one another in accepted text:
- 2026-09-19 — bitsystem's
docs/design/typed-space-wires.md: "An entire space is accessible through the same primitive as any other entry: a typed wire." - 2026-09-21 — bitwire begins. Its decision 0002 cites
"
Bitsystem's original typed-space model"; its README assigns bitsystem "Typed spaces and the kernel/system operations exposed through them." The same day an operator ruling makes archon nightseam 0.7.0's identity layer (nightseam#336), so archon is the first piece both families already share. - 2026-09-22 — bittree's decision 0001:
"
A tree that presents access is what Bitwire's contract calls an origin -- a space, whose paths are positions in data". repo-tool begins, on nightseam, as "the smaller first implementation of the decomposition of bitsystem's repo tool". - 2026-09-23 — deixis ADR 0009 is accepted. It
"
began with Wire as a possible Deixis implementation", moves the node model toNode(.) = Option(.) × (Key ⇀ Node(.)), and assigns bitwire, nightseam and bittree their parts. nightseam'sdocs/theorylands the transparency square (T2, navigation transparency; §19, substitution transparency).
In code, the fleet already crosses the seams by hand. nightforge's ULab pins nightseam v0.6.0
and bitwire v0.2.0 in ulab-runner and builds its Dawn services on archon identity and thesmos
grants; aiscape's @aiscape/auth is "archon envelopes over thesmos grants"; bitsystem's kernel
runs on logos and ontos; nightfall found it had "independently built Bitnode's L0 journal facet"
and proposes to "adopt Tree as a seam". In design, bb2's architecture takes ontos, logos and
logos-db as its substrate, "consumed at pins, never modified".
nightforge's research-docs/0001 states the situation exactly: the two projects are "closer to
two components of one person's system that have been developed independently enough to have
genuinely different models, and are now meeting."
The constellation had already ruled the same architecture: one global space tree in which scope is placement (thesmos ADR 0016; the space model), a single root (ADR 0028), registry-governed top-level spaces (ADR 0035), and "the fact-derived judgment–realization loop" (ADR 0031). The bitnode line reached the same shape in bn2's corpus: one tree, one root, authority descending from parents. That is recurrence, not yet agreement; §8 names where they diverge.
4. The skeleton, and who built each part
bn-architecture's SERVICES.md gives the frame in one line: "Three servers hold what cannot be
derived. Two positions hold what cannot be delegated. Everything else is derivation, and
derivation has no owner." The servers are bytes, cells and wires; the positions are the
acceptance gate ("what counts as true") and the executor ("what can actually happen"). With
material, declaration and operation added, most parts have been built more than once:
| Part | Constellation | bitnode line | nightseam / bit* |
Fleet |
|---|---|---|---|---|
| Material, pointing | deixis (model accepted; codec pending) | bn-trees (laws), tree-lab | bittree (running) | nightfall (proposes Tree as a seam) |
| Bytes | ontos codec (frozen) | bn-bytes (running); bitsystem's blob store | — | nightforge's Bytes; nightmill's receipts |
| Cells: the present | topos (proposed) | bn-cells (scaffold); a space's facts (monotone today) | — | — |
| Wires | deixis WIRES.md (doctrine); kosmos protocol |
bn-wires (scaffold); typed space wires (concept) | bitwire 0.2.0; nightseam's runtime | — |
| Derivation | logos, logos-db; horos judges form by derivation | bitsystem's closure (on logos) | — | weft's and llllm's memoised derivations |
| Acceptance | archon, thesmos, stele | bn2's descending authority; bitsystem's permitted effects | nightseam's own grant over archon | aiscape, nightforge: archon and thesmos |
| Execution | pharos (the ADR 0031 loop); kosmos, telos, harmos | bitsystem; bn2's model-spike-2; bn3-system | bitengine (planned) | ULab's "Kernel 1.0"; nightshift; weft; bitsystem's lab |
| Declaration | horos descriptors | bitsystem's declarations; bn2's corpus | nightseam's families, bitschema, bitlink | — |
The execution row is the finding. 0003 lists realization as a candidate without a repository; outside the constellation, realization machinery has been built at least six times — bitsystem, bn2's model-spike-2, bn3-system, bitnode-old, ULab's "Kernel 1.0" and, earlier, bitmachine — each with its own judgments. 0003 calls exactly this "the tell of a real theory": a "repeated, independently-rediscovered shape".
5. Capability and realization have a worked candidate
The declarative space model (bitsystem, docs/design/declarative-realization.md, adopted
2026-09-21) states its core in three notions — spaces, contracts, realization — and one
property, closure under realization: obtaining a runtime, generating a type description,
producing a compiler, discovering dependencies and creating a provider all leave a world to which
the same mechanism applies. An offer is a realization rule bound to a realizer:
A(u) ⇝[k,w] fresh c . exists v . B(u,c,v)
It has assumptions A, a guarantee B with placement stated in it, fresh identities c, and
witnesses v learned only by running. A demand is a contract to establish. The kernel
composes guarantees with assumptions, realizes prerequisites, executes through an explicit
operational basis and continues through what execution produced.
Set against the sketched judgments of 0003:
| 0003 sketch | Declarative space model | Divergence |
|---|---|---|
provides(Entity, C), requires(Entity, C), operation(C, …) |
an offer's guarantee and assumptions (§8) | the model fuses affordance and realization in one offer; 0003 keeps capability and realization apart |
build_plan(P), deployment_plan(P, …) |
a derived composition: "The logical dependency order follows from assumptions and guarantees" (§17) | 0003 treats a plan as a fact to check; the model derives it and authors none |
realizes(Observation, Desired, Host, Manifest) |
W ⊩ G ⇓ W′, with returned witnesses admitted as results (§7, §11) |
the model's witnesses are observed, never chosen: "Returned witnesses are not planner-controlled inputs" (§11.1) |
| "the runner is not a primitive"; the theory "does not run anything" | the kernel plans and applies | reconciled by the split below |
The split that reconciles them is logos's two directions over one account. The theory is the checkable part: contracts, offers, demands, and the claim that a realization establishes a demand. The model's §19.1 states that claim as conditional soundness — "a completed accepted realization establishes the demanded contract". The kernel is the search side: an untrusted occupant that finds and performs realizations. That keeps bn-architecture's two positions apart. The kernel is the executor; admitting its results stays with the acceptance gate. A planner that also decided what counts as true could make its own conclusions true.
The evidence. bitsystem measures the claim that one unchanged kernel suffices against six
written criteria, with a ledger at a pinned foundation — the hardest rung of the evidence ladder
in bitlink's study. Its standing at foundation fa52e96491ca (docs/ambition/criteria.md):
| Criterion | Standing |
|---|---|
| EXPRESSIBLE | refuted — a fact inside another space cannot be posed as a goal (scenario 011) |
| SUFFICIENT | refuted — 54 cases in 11 scenarios are established from a bare request (a goal and the allowed effects only); one gap stands: a conclusion that installs a capability |
| UNCHANGED-KERNEL | refuted — scenarios 006, 009 and 010 each needed a change to supporting code |
| TRUTHFUL | holds — 71 cases verified independently by bytes, provenance or recomputation; 4 returned spaces refused for an unmet promise |
| BOUNDED-FAILURE | partial |
| SELF-HOSTING | untested |
Of the model's four adoption stages, continuation and plural witnesses have landed (baselines
5031722 and ede59b3). Scoped goals (stage 3, which closes the EXPRESSIBLE gap) and
obtainable implementations (stage 4, which closes the SUFFICIENT gap) are open. Two alignments
stand out:
- The one gap against SUFFICIENT is bitnode's credo. Stage 4 needs stage 3, or "an adoption rule that makes a child's offer usable in the parent, which is an authority question the model must answer first". Realization reaches thesmos exactly where 0003 predicts capability will: it "depends on horos for the type slots and thesmos for the authority patterns".
- bitsystem's unmeasured domains are where the other strands did the work. Its domain sections without a measured scenario are 8 (capacity), 9 (identity, authority and responsibility), 10 (communication and access bindings), 14 (continuing requirements and time) and 17 (bootstrap). Section 9 is archon, thesmos and stele; 10 is bitwire and nightseam; 14 is topos, stele and 0003's time outsider; 17 is the operational basis. Capacity is 0003's resource outsider, unowned in both.
6. One kernel on one substrate — how each repository relates
Above the substrate, the kernel is the only composer: no other repository sequences work. "One kernel" means one semantics every space runs, not one central service. bitnode's target makes the interpreter optional per space, and the model forbids flattening participant scopes into a global database (§5.2). Each repository then stands in one of three relations to the kernel.
It supports the kernel. The kernel is made of these; it consumes them and cannot host them.
- ontos — terms: "Literal data remain terms" (§4.2). Already the kernel's value encoding.
- logos, logos-db — deduction and matching, already the kernel's engine; also the check direction for realization accounts.
- deixis — tree material, and the paths of descriptions and addresses. The divergence: the model's ownership tree is over fresh identities, not values — "A fresh space identity is not the same as a newly learned value" (§8). deixis's proposed topos layer draws the same line between a value and a place.
- archon, thesmos, stele — identity, law and record: the acceptance position. The model puts "authentication, and access control" outside its present scope (§1).
- bitwire and nightseam's runtime — presentations that preserve contracts,
Π(C[ρ]) ≅ Π(C)[Π(ρ)](§4.3, §16). This is the same commuting law as bitwire'satlaws, nightseam's navigation transparency and deixis ADR 0009's "Binding a subtree to an origin and navigating a relative path must commute". - The three stores — bytes (ontos's codec, bn-bytes), cells (topos, bn-cells) and wires (bitwire): the operational basis of §8.2.
- horos — the natural candidate for the contract language of §6, since both treat a type as a predicate judged over values; a mapping to test, not an identity.
It is mapped onto the model. Its concept becomes a concept of the model; its machinery retires or becomes a profile.
- Realization machinery: bn2's model-spike-2, seam-spike (when a foreign assertion may become a premise, which is stage 3's question) and space-spike (the carrier); bn3-system; bitnode-old; space-lab; pharos, whose ADR 0031 loop has the kernel's shape; kosmos, telos and harmos, covering resolution, entity lifecycle and node composition, where the model resolves through the space tree and derives lifecycle states as domain conditions (§8.3, §20); nightforge's ULab "Kernel 1.0".
- Coordination: nightshift and nightseam-flows (work, blockers and readiness as demands, §10, and domain conditions, §20); weft and llllm (their graphs as derived dependencies, §17; memoisation as reuse, §11); bb and its bitagent successors; agent-hub.
- Declaration ancestors: TISL and the
defs-*repositories, bitmachine — constructors that yield constructors, which is the model's closure under realization. - Registries: atlas's topology and bitsystem's knowledge graph, as facts.
It is hosted by the kernel. Providers whose implementation stays and whose orchestration goes:
- nightforge's lift, recover, order and recompose; nighthall's runtimes; nightfall's consultations through nightjar; aiscape's maintainer, as a standing demand (§10.1); repo-tool and bittree, as repository spaces with edit transitions; nightseam's generator, which the model's §17 already decomposes into loader, analyzer, checker, view producer, language generator, compiler and runtime providers; bitsystem's lab processors; l111m's components; CI runners; and language-model agents, whose results are observed afterwards, not promised (§11.1).
Three cases fit none of these rows. nightseam splits: its runtime supports the kernel and its generator is hosted. bitnode is the product, not a tenant: its target leaves exactly the kernel's slot open, an "Optional realization interpreter" for "Intake, meaning, context, checked planning". The slang family, nightglass, nightmill, radial and bitbooks lie outside the design.
7. Why a kernel alone is not the whole
The model says so itself:
- "All operational paths eventually depend on an explicit initial basis … Self-description can explain the basis. It does not create the basis from nothing" (§8.2). Bytes, cells and wires are implemented beneath the kernel.
- "Latency, outages, communication failures, authentication, and access control are outside the present discussion" (§1). Identity and law are not in the model, and carriers handle failure.
- It presupposes terms (§4.2), a deduction procedure (§6, §11) and presentations that preserve contracts (§16). Those are its floor and its interface, not its tenants.
- Its discovery claim is semicomplete only in an additive fragment (§19.2): "General stateful realization therefore needs an appropriate planning or strategy argument" (§19.3). Deployments, repository edits and provisioning are stateful.
So the claim holds in a narrower form: above the substrate, the kernel is all that composes. That is still a large reduction, from half a dozen realization loops, pipelines and runtimes to one kernel over a floor that is largely frozen already.
8. What was built more than once
| Concept | Versions today | Ruling needed |
|---|---|---|
| Tree | deixis, bittree, bn-trees, tree-lab, bitsystem's space tree, nightseam's contract tree | which is the material and which are profiles; ADR 0009 has begun, with bittree and bitwire owning their mappings |
| Space | thesmos's path, where a fact stored at a space is visible from every descendant (the space model); the model's participant with a local scope, where "Referencing another space does not merge its scope with the current one" (§5.2); bitnode's carrier tree | whether an ancestor's facts belong to a descendant's scope; first, because stage 3 turns on it |
| Wire | bitwire, nightseam's runtime, deixis WIRES.md, bn-wires, kosmos, tree-lab |
bitwire as the contract (nightseam adopted it); the rest as profiles or history |
| Form | horos, nightseam's type model and theory, bitschema and bittype, TISL | whether horos is the contract language |
| Authority | thesmos; nightseam's own grant (nightseam#345); bitsystem's permitted effects; bn2's descending authority | the one real fork: nightseam declined thesmos while nightforge and aiscape adopted it |
| Present | topos, bn-cells, telos, a space's facts | who owns atomic current state; the model's transition contracts (§13) |
| Record | stele, logos-db, nightforge's Journal, weft's and llllm's logs, nightfall's journals, bitsystem's ledgers | one record, or declared projections of it |
| Realization kernel | bitsystem, model-spike-2, bn3-system, ULab's "Kernel 1.0", pharos, kosmos with telos and harmos | one line; the others absorbed, profiled or retired |
| Generation stamp | fencing tokens, epochs, leases, rounds, foundation digests | bitlink's study calls it "The single most-reinvented mechanism in the family" |
| Identity | archon | already one |
Each ruling should take ADR 0009's form: one owner per concern, and "Each mapping and its observation laws need their own declaration and evidence."
9. What would follow — proposals, not decisions
- Stages 3 and 4 of the realization candidate, in bitsystem, measured: scenario 011 flips, and a new scenario has a runtime's binding, not only its process, produced by an effect. That is where hierarchy, capability-establishment and authority meet.
- Domains 10 and 9 through the substrate. Spaces are presented through bitwire, as
typed-space-wires.mdproposes and bitwire's role table expects. Realization results are admitted through archon and thesmos: thesmos's law is a logos program, so it is a candidate to run as a space's deductive rules, while archon's signature check stays a primitive of the basis. Stage 4's adoption rule would be its first client. - One ruling per duplicated concept (§8), space first.
- One map. A later ADR could widen atlas's registry beyond the constellation. The membership test already fits, and each strand would need a place in the layer vocabulary. This essay proposes no entries.
- Self-hosting as the acceptance test. bitsystem's SELF-HOSTING criterion and the target in
deixis's
VISION.md§5, "the governance tooling consuming the constellation's own packages", are one criterion, untested in both repositories. The first hosted participants would be the ones already crossing the seams: repo-tool, bitsystem's lab and nightfall. - Promotion by 0004 §1. By that path the candidate stands before the profile stage: one Go implementation, measured by scenarios, with no conformance vectors a second implementation could replay. Before an ADR could call it a theory it needs its judgments separated from its kernel (§5), a second implementation and vectors. Then come the names 0003 set aside, dynamis and energeia, or a single name if the first open edge closes that way.
Open edges
- One theory or two. The model fuses capability and realization in the offer; 0003 separates affordance from actualization. A definability test (0002, Test 2) against the model's offers would decide.
- Space semantics. Downward visibility (thesmos) against local scope (the model); §8's first ruling.
- The kernel's standing. This essay puts the judgments in the substrate and the kernel among the occupants. If every realization is admitted only through a check, does the kernel need any standing beyond an ordinary occupant's?
- State and time. Discovery is semicomplete only in the additive fragment, and stateful realization lacks its strategy argument (§19.3); 0003's time outsider sits here.
- Resource and scarcity. Unowned in both tracks: 0003's outsider and bitsystem's domain 8.
- nightseam#345. Whether the no-logos, no-revocation mandate stands once realization needs checked authority.
- Implementations. The kernel exists in Go only; the constellation's price of promotion is several languages held to shared vectors.
- The second party. By deixis's
VISION.md§5, success is a second organization paying the conformance price; until one does, this is a candidate commons. - This essay's own claims. Every correspondence above is a claim to verify at its pin, not a finding. The refutation rate quoted at the top applies to this essay as well.
Sources
Pinned at the commits read for this essay, 2026-09-23. Section numbers such as §8.2 refer to
bitsystem's docs/design/declarative-realization.md.
| Repository | Commit | Read |
|---|---|---|
| bitsystem | bc60fc149803a44d03260d4baaa9750055cdaece |
docs/design/declarative-realization.md, docs/design/adopting-declarative-realization.md, docs/ambition/goal.md, docs/ambition/criteria.md, docs/design/typed-space-wires.md |
| deixis | b44a97ac607e686d402281965666a0da4dfc5e9d |
docs/VISION.md, docs/WIRES.md, docs/consumers/TOPOS.md, docs/design/0009-optional-node-values.md |
| bitwire | 0f30b515694cb3005403229be0f4e4158baf41b9 |
README.md, docs/decisions/0002-delivery-dispatch-and-ownership.md |
| bittree | 0013fc998af9c271e59da98d9308a3f31b768609 |
docs/decisions/0001-tree-access-over-the-wire.md |
| nightseam | 11e7d2c1dd6cce042f87bf28b4ecddc7e911ee6a |
docs/theory/foundations.md |
| bitnode | 70184430875b31e75ecdd69b00f0340dc802d945 |
VISION.md, TARGET.md, archeology/SYNTHESIS.md, archeology/RECOLLECTIONS.md, archeology/SOURCES.md |
| bn2-system-meta | 34e330f66f17dea8723a2f898491fc1ccb9448ff |
VISION.md, SPIKES.md |
| bitnode-old | b203b750e0805f2fb83ea7dc82851203f517f552 |
VISION.md |
| bn-architecture (local checkout, no remote) | 5426250c0827b1beb573a488429cf91b54e9bb36 |
SERVICES.md |
| bitlink | 804d11452f5532f485c92fc7fc7c94fd11e352e1 |
docs/studies/family-concept-map.md, docs/RELATED_REPOS.md |
| repo-tool | 862ba8173601488011cd51221e5f36ff4eb91d79 |
README.md |
| nightforge | e7056fff5bba46fadae050f7a9f27eff2e4d65ee |
research-docs/0001-bitnode-tree-substrate.md, archive/ulab/README.md, the ulab-runner and ulab-dawn module files |
| nightfall | cd4789686a9a7ee1cb509e90bd80337219e6b784 |
docs/BITNODE-TREE-PROPOSAL.md |
| aiscape | 2536a57f8559b6d48198a3efb72d634b44f67460 |
README.md |
| bb2 | 692360225efe44506cef3bb3d89fd528b203270c |
docs/ARCHITECTURE.md |
| archon | 121655b3971fdf37425447d6aaac884c067eeb88 |
README.md |
| logos | 74a66c95c6009d99cf07bd22e14d165ce3d4ef95 |
README.md |