Roadmap

Where Silt is going

Source of truth. What M0 asserts and why lives in docs/design/m0.md (the composition spec). What the owner has decided lives in docs/decisions.md. The destination is docs/TENETS.md. This file is the narrative path: where we are, what the forward tracks are, and why they're ordered the way they are. It is not a tracker — live state is the GitHub V1 milestone and its issues. The earlier Gate 0→6 spine (with Gate 4 as "the M0 mechanism to build") is retired: that mechanism is built and the mission was reframed (below). The v0.1.x/0.2.x tags are experimental / learning releases, not steps on the march to V1; that history lives in docs/buildlog/.

Tenets are the destination; this roadmap is the path

V1 is defined by the tenets, satisfied and field-proven — not by a feature list. Every track below advances one or more tenets; if a step serves no tenet, it doesn't belong here. The relationship is one-way: tenets guide the roadmap. A tenet gates V1 as a principle, never a mechanism — with one deliberate exception, M0 (the mission itself), whose real mechanism is in V1 by definition. Release is gated by proof (R1): a tenet is "met" only when field-proven multi-machine, not sim- or single-host-only.

The launch stance — harden-first

The first public appearance must be credible and spectacular from day one. A half-baked drop on a project this ambitious burns the one first impression we get with the exact technical audience we need. So the tenet floors (integrity, no-silent-loss, don't-crash, honest observability) and the mission (M0, field-proven) are done before any launch. Feedback is sought — on something that already stands up, not as a substitute for hardening.

The build principle (B8): best-in-class components, a novel composition. We do not reinvent primitives (crypto, transport, codec); we adopt the strongest proven ones and reserve novelty for the composition and incentives — where M0 lives — proven by spec + an external red-team, never self-graded.

Where we are now (the honest status)

The forward tracks (what replaces the gate spine)

Three kinds of work remain. Build makes the decided directions real; verify is the gate to declaring M0 held (not merely built); research frontier is the handful of items that need a new result, not a decision.

Build tracks

Verify tracks — the gate to "M0 held"

M0 is held only when an external party attacks the built composition and it survives at declared parameters. Self-graded does not count.

The certified sequence to the gate (D-CONSENSUS, 2026-08-14): build the certified #402 fix → consensus model-check launch tier green (#406, with the #357/#397/#402 failing-first replays) → the P1 all-corners field run → model-check handoff tier + the #399 WS-recovery drill → the MATURING=1 run (field-cert of the #389 weight-quorum handoff) → model-check full budget + the red-team entry criteria (release-checklist.md) → external red team (#183).

Research frontier — needs a new result, not a decision

What "M0 held" means

M0's Sybil corner is not a primitive to be proven Sybil-proof — that is impossible. It is held when, at the network's declared parameters, no strategy earns consensus-controlling standing for less than q · C_honest (C1), and the concentration metric keeps the minimum colluding operator set above k (C2), with the §7 seams either closed or held in tension with a documented, bounded residual. C1 is a theorem under the B5 hypotheses H1–H3 (a direct-product bound) — conditional, not unconditional: the per-identity Alwen–Blocki lift is unproven, the shared-content H3 gap (γ→1/N, #182) is open, and in shipped code only the bond (D) axis gates standing so far (§ "where we are"). C2 is a measurement bounded by an impossibility result (Kwon) — held, not closed, by design. The verdict is rendered by the external red-team + the field test, together.

The resolver layer ("Aslan" — separate product)

Meaning lives above the infrastructure, in a separate codebase: name/description/ tags → (root, manifest key). Silt ships zero Aslan code, ever. See docs/aslan-boundary.md.

Release engineering — the march to V1

The 0.1.x / 0.2.x tags were experimental / learning releases, not steps toward V1 — treat them as archaeology. The real cadence has three stages:

Mechanics when ready: move CHANGELOG "Unreleased" into the version, tag, and the release workflow builds + publishes binaries; add code-signing/notarization (macOS) + a checksums file first. See docs/release-checklist.md; website/DNS in DEPLOYMENT.md.

← Back to silthq.com