The long view

Supernova has an unusual endgame: a platform bootstrapping itself in order to ship as something stable — self-improving scaffolding around an artifact meant to hold still once it ships.

This page covers where the project is deliberately headed, the control-loop framing that shapes every mechanism on this site, and — because build-state honesty is the house rule — the specific things that have not been proven yet and could still sink it.

Ship mostly finished, then spin off

The destination was fixed by the 2026-06-10 builder ruling, quoted in full on why this exists; the route has since been superseded — development moved onto Supernova’s own systems, and “Supernova is bootstrapping itself” (Matt, 2026-07-05) is the standing word. Builder throughput is still the schedule (finding F15); the builder is increasingly the platform itself. Two clauses of the original plan survive untouched:

• Share the product, not the instance. The origin constraint — you can’t fork a self-improving system — means what gets shared is the git-shippable artifact. A collaborator clones Supernova; nobody gets a login to Matt’s automatt. Multi-tenancy of humans was explicitly dropped (2026-06-20); projects are the only tenants.
• am-on-supernova is a maybe, not a milestone. Whether automatt eventually migrates onto a Supernova instance is, per the bootstrap doc, “evaluated against the shipped product, not a build milestone the schedule depends on.” If the migration never happens, the plan still counts as complete.

The recursive-self-improvement story — the loop is real and now runs through Supernova’s own systems, while the shipped artifact stays deliberately stable — is told on why this exists. What matters for this page is the consequence: the artifact ships clean, and everything below is about keeping a non-self-modifying artifact provably correct.

The platform as a control loop

The deepest framing in the design corpus, and the one this site keeps circling back to, is that the whole platform is a feedback controller. Matt’s keystone phrasing (2026-06-23): “tasks are the imperative part that enforce the declarative part.”

flowchart LR
    R["Requirements DAG: the setpoint"] -->|"unsatisfied gap spawns"| T["Tasks: the actuator"]
    T -->|"completed work produces"| E["Evidence: the sensor"]
    E -->|"satisfies requirements"| R
    E -.->|"decays, reopening them"| R

• Requirements are the setpoint — declarative statements of what must be true, each naming the proof that closes it. The wiki owns them.
• Tasks are the actuator — feat/wire/bug issues that drive declarative state toward satisfied, flowing through the delivery lifecycle. The issue system owns them.
• Evidence is the sensor — typed, observed proof. The monitor system owns the ledger, and self-attestation is prohibited: evidence comes only from real producers such as test runs, review stamps, and field metrics.

The loop’s defining property is that closure is non-monotonic [supernova design]: “done is rented, not owned — you do not finish a requirement, you keep it satisfied.” A done requirement reverts when its evidence decays, and decay is per-evidence-kind (the requirements page owns the mechanics). The set of currently-down requirements is the live defect surface — there is no separate “what’s broken” list. System health becomes a gauge of how proven the DAG is right now, not a checkmark earned once.

The same loop recurs at smaller scale as agent goal loops — one agent, one target, ACT → EMIT → CHECK → PARK → WAKE, parked at zero compute on the exact bus signal that would change the answer. The v1 goal-loop runtime is [built in-repo]: implemented and tested in the Supernova workspace, nothing deployed.

The full platform loop is a different build state. Decay detection, live evidence feeds, the assembled sensor path — that is [supernova design], not something running end to end anywhere today.

What must still prove out

Nothing on this site should be read as a running production system. The readiness dashboard is explicit that the in-repo proof surface can be green while production_ready:false. These are the open questions, stated as falsifiable bets:

The E2E row deserves the verbatim, because it is the project applying its own standard to itself. Matt, in the D82 ruling: “all the waves that follow sort of rely on e2e testing being real, coherent, and enforced, otherwise we’re gonna just need to do this all over again when everything gets fake-closed.” A platform whose central claim is proof-backed closure correctly identified that a fake test harness would re-fictionalize everything, and stopped closing requirements until the harness is real.

What this costs

• Non-monotonic closure is expensive machinery. Decay detection, per-kind volatility, hysteresis to avoid flapping — the requirements page covers the mechanics, but a fair reviewer would call this a lot of moving parts in exchange for “done means still-true.”
• Superseded designs are kept on the books — the self-hosting kernel, human multi-tenancy, smoke tests as closure proof, a fixed system count. The decisions ledger preserves each reversal struck-through with the ruling attached — both a discipline and a record of how often the design has changed its mind.

The builder-model costs — the two-systems window, the corpus-to-code ratio, the metered-model dependency — are enumerated on why this exists.

Strip the framing away and what remains is checkable: a requirements DAG where closure is evidence-backed and reversible, a validator that fails the build when code and spec drift, a decisions ledger where every ruling terminates at a dated human quote, and a builder that already pushes twenty-plus tasks overnight [live in automatt] while the clean rebuild accumulates in a Rust workspace behind it.

The bet is that “done is rented, not owned” is what software maintenance actually looks like when you stop pretending otherwise, and that the first system built around that premise from day one will feel obvious in hindsight. The proving ground is scheduled: a real E2E harness, a standing deployment, and a spin-off. Until those land, the project’s own rule applies — under-claim, and let the evidence close it.