Bitspark constellation

deixis

δεῖξις
substance

The structure of a tree, and nothing about what a tree holds.

the structure of a finite keyed tree, independent of what its nodes hold

https://github.com/Bitspark/deixis ↗

Why it exists

Every layer of the constellation freezes its law and carries its content as trees — descriptors, derivations, signed facts, records, bindings. If each layer defined its own tree, every boundary between them would be a translation, and translations drift. deixis takes the one thing they all share and defines it once, with nothing else attached:

Node(.) = (.) × (Key ⇀ Node(.))
Key     = Bytes

(.) is the slot: opaque to deixis, supplied by context. Every node has a mandatory own value and a finite map of named children; that is the whole model. deixis is to the constellation what an alphabet is to a body of law — it appears in every statute, governs none of them, and is the reason they can all be read.

A concrete example

What goes in the slot is the consumer's choice, and each choice is an explicit instantiation rather than a feature of deixis: pure shape is Node[Unit], optional values are Node[Option[T]]. Construction and navigation need no comparison at all; identity additionally takes a supplied equivalence, so deixis never decides what it means for two payloads to be equal.

A path points through the tree, and resolving one is the system's namesake — δεῖξις, pointing, showing. Paths do not flatten: a key is bytes, not a string with separators, so no key can smuggle in a second level.

The canonical bytes are deixis-codec-v2, in flat and linked forms, encoding every node's payload and its complete child map. Four cores — Rust, Go, TypeScript, and Python as a validation peer — replay the same hand-authored vectors, judged by one black-box harness. No implementation is the reference; the vectors are.

What it unlocks

deixis is a pure leaf: dependsOn: []. That is what lets it sit beneath ontos without pulling in a value model — and ontos does build on it, through a bridge confined to its projection/deixis directory, pinned by tag on every side. ontos's core, codec and data take no deixis dependency, so consumers of ontos are unaffected by it.

Because structure is separated from content, the same contract serves data and interaction alike: a tree of readable data and a tree of wires expose the same own value, the same complete byte-keyed children, and the same decomposition and reconstruction.

What's next

The codec is a candidate, not frozen: bytes and addresses are not stable identities until its freeze manifest is signed, and the freeze requires a clean-room implementation that none of the four cores is. Until then deixis ships through the substrate as two components, deixis and deixis-pos, and the corpus that judges the cores is itself measured — by planted defects and by differential fuzzing — so that a green harness says something about the contract, not only about the code.

Depends on

Nothing — deixis sits at the floor of its stack.

Depended on by

ontos build

projection/deixis/{rs,go,ts} pin deixis BY TAG — deixis-core and deixis-pos at v0.2.0 (npm 0.2.0), the same revision on every side (#277). v0.2.0 is deixis's mandatory-node-values release, so the bridge's codomain is Node[Option[Bytes]]; Option is the bridge's chosen payload, not a deixis feature. CONFINED to that directory — core, codec and data have no deixis dependency — but projection/deixis/rs IS a default workspace member, so a plain `cargo build` at the root does resolve it. Consumers are unaffected: a git+tag dependency on ontos-core resolves that crate, not the workspace. The bridge has THREE faces (rs #194, go #253, ts #325) and is UNWITNESSED under the ontos#191 maturity ladder because all three are ontos-authored — not because it is single-face (#313 records it as permanently unwitnessed); this edge states a build fact, not a parity claim.

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

GitHub