stele

Why it exists

A polity needs a record — somewhere participants inscribe what they assert, and from which others read back. The hard part is not storage; it is that every write and every read has to be settled the way the whole stack settles things: with a proof you can re-check, never a claim you must take on trust.

stele owns exactly that record and nothing more — the store, the transport, and the wiring. It invents no value model, no reasoning engine, and no authority logic of its own. A fact's body is an ontos value; admitting a write is a logos check; gating a read is logos solve + check; and whether an inscription is authorized at all is thesmos's program. stele is the constellation's runtime floor — the public pillar the family reads from.

A concrete example

A signed fact records who said it (asserter), where (space), what (predicate plus body), and the warrant that it was them (signature, Ed25519 over the ontos-codec encoding). Through the stele CLI — where a client is a key — the flow reads almost like the Athenian original:

$ stele -i root grant alice          # root delegates write authority to alice
ok 4b9e1c…d0a7
$ stele -i alice authorize-assert alice greeting hi
ok 9f3c2a…7e15                       # inscribed under the grant
$ stele -i alice query alice         # a gated read, authenticated as alice
greeting(6869)

A write is admitted only if alice carries a proof that she is authorized, which stele re-verifies. A read returns only the rows a proof of may read can be found for — and absence is uniform: a row you may not read is indistinguishable from one that does not exist.

What it unlocks

With the record settled, the systems above it stop re-spelling storage and trust. The apps and services above keep their state on one append-only fact log, space-projected, instead of a bespoke store per concern. Reads come in four shapes — query, snapshot, history, and watch — so a consumer can take a point-in-time view, walk the op-log, or follow the live tail by a stable cursor. And because the read-gate certifies an untrusted producer, the thing that searches for a candidate read need not be trusted; only the tri-core check gate is. stele runs across go, rs, and ts, byte-pinned by shared vectors, so a fact signed by one core admits under another.

What's next

Per the repo's status, functional parity with the legacy arche-facts service has closed; the open work is hardening and scope, not gaps — read-path performance, wiring the search-backed producer behind the live node's read methods, request run-limits on the wasm guest, and multi-hop derived claims.