Supernova in one page
Supernova is a personal automation platform: a fleet of AI agents that watch your inputs, propose actions, and execute the approved ones — every action riding a single event bus, gated by a risk-tiered safety engine, and traceable back to a documented human decision. What makes it worth reading about is less any single feature than the coherence: nineteen systems (the set is open-ended) sharing one five-part shape, one traceability spine from requirement to code line to test evidence, and a decision ledger where rulings terminate in the human’s exact words — or are explicitly labeled when they don’t.
Who builds it
Supernova was seeded by automatt, a live, self-modifying agent platform that pushes twenty-plus tasks overnight and self-organizes around incidents [live in automatt] — and it has since taken over its own construction: “Supernova is bootstrapping itself” (Matt, 2026-07-05). The agents building it work through its own machinery — issues claimed from its own tracker, worktrees cut by its own vcs system, closure gated by its own validator — so improving the platform and building the platform are the same activity. The original plan had automatt building everything and shipping a finished product; that ruling is now superseded on the record, which is itself how this project works. Why this exists tells the full story — including why the artifact it ships is still meant to hold still.
Ten ideas that carry the project
Each idea carries a build-state tag — the four tags are defined under build status at the bottom of this page.
| Idea | What it is | Build state |
|---|---|---|
| Decisions as case-law | Rulings terminate at a human-verbatim anchor or carry an explicit PARTIAL/NONE grade; supersession is formal, cited, never deleted | [live in automatt] |
| Requirement percolation | Requirements form a DAG percolating to one root; @R# spans annotate code; coverage is computed, not asserted | [live in automatt] |
| Docs as enforced contract | Per-file specs, Requirements/Invariants/Interfaces per system, a validator that fails the build on drift | [live in automatt] |
| The 5-part shape | Every system is code + client lib + CLI namespace + wiki docs + config section; adding a system is a scaffold, not a redesign | [built in-repo] (scaffold + validator); the frontend renderer is [supernova design] |
| The bus as audit log | Kafka transport, mandatory envelope, two-write outbox, the durable trail — history is a retention setting | envelope/outbox/reactor [built in-repo]; Kafka-as-transport [supernova design]; a bespoke predecessor is [live in automatt] |
| Park-on-failure | A failed workflow parks alive at zero compute while the system heals, then resumes from the failed step — retries were removed | primitive [engineered, not deployed]; full delivery parking [supernova design] |
| Fork/zygote agents | Warm parent sessions fork children onto a shared prompt cache — ~99.7% cache reads in the field | [live in automatt]; the 24h cache patch is [engineered, not deployed] |
| Layered safety | Five risk tiers, capability groups instead of agent names, one external-send chokepoint; a denial is a hard wall | [live in automatt] |
| Evidence-gated delivery | feat → spec → wire; sprints are dead, the task-graph frontier surfaces ready work; closure requires typed evidence, and done is rented, not owned | [live in automatt], sharpened in design (D68, 2026-06-21/22) |
| Rust, wholesale | The 2026-06-21 language ruling and what a typed workspace buys a machine-verified project | [built in-repo] |
The shape of the thing
flowchart TD wiki["wiki: requirements + specs"] -->|"declares obligations"| issue["issue: tracked work"] issue -->|"drives"| workflow["workflow: Temporal"] workflow -->|"runs"| agent["agent: runtimes"] agent -->|"acts via"| bus["bus: Kafka + trail"] bus -->|"events + metrics"| monitor["monitor: Sentinel"] monitor -->|"evidence closes or decays R#s"| wiki bus -->|"external sends only through"| link["link: sole egress"] approval["approval: risk gates"] -->|"gates"| link
That loop — obligations declared in the wiki, driven by tasks, proven by evidence, reverted when evidence decays — is the platform’s core mechanism. The supporting cast (test harness, review stamps, ops, ingest, config, and friends) exists to keep it honest.
Build status
Supernova is a design and in-build project, not a running product. It is a Rust workspace with real code, real tests (including opt-in end-to-end runs against a checked-in Kafka/Temporal/Prometheus stack), and a full design corpus — and zero of its nineteen systems are production-live in a standing deployment. The project’s own readiness dashboard can be green on local checks while still reporting
production_ready: false; this site keeps the same discipline. Every claim on this site carries its tag: [live in automatt] (a rough version runs in the builder today), [supernova design] (specced, not running), [built in-repo] (code and tests exist in the Supernova workspace; nothing is deployed), [engineered, not deployed] (built and verified, not in production). When in doubt, this site under-claims.
Where to go next
- The argument: why this exists, then the 5-part shape — the builder story and the anti-drift architecture.
- The spine: wiki → requirements → delivery → decisions — how docs, proof, and rulings interlock.
- The machinery: bus, workflows, agents, safety, then multi-project, why Rust, and the supporting cast.
- The judgment calls: a comparison with the rest of the field, and the long view, including what has to prove out.