Proof, memory, and decisions

An autonomous system becomes hard to trust when it cannot answer three questions: Why does this behavior exist? Where is it implemented? What proves it still works? Supernova makes those questions part of the project model.

A two-way trace

Each requirement carries two complementary fields:

• Origin points backward to the decision, defect, or product claim that created it.
• Evidence points forward to the proof required before the claim is satisfied.

Requirements form a directed acyclic graph that rolls from implementation details toward project outcomes. Source files have matching file-level specifications; Rust code uses active @R# annotation spans to bind implementation lines to those specifications. Tests and coverage artifacts bind back to the same requirements.

flowchart TD
    decision["Decision or product claim"] --> requirement["Requirement + evidence obligation"]
    requirement --> filespec["Per-file specification"]
    filespec --> code["Annotated implementation"]
    code --> evidence["Test, review, metric, or attestation"]
    evidence --> requirement

This enables queries in both directions: from a code line to its reason and proof, or from a changed requirement to the code, tests, and dependent outcomes it may affect.

Evidence is typed

Different claims need different proof. Supernova distinguishes unit and integration results, coverage, field metrics, critical-user-journey exercises, human approvals, external correspondence, documents, and independent agent attestations.

The kind, producer, subject, revision, freshness, and trust level matter. A passing local stub cannot satisfy an obligation for a provider-network result. A whole-suite coverage hit cannot prove that the specific declared test exercised a requirement’s lines.

Satisfaction is a derived rollup over the required evidence. It is not a status word someone may set by hand.

Proof can expire without erasing history

Isolated evidence can turn red after a code change. Field evidence can degrade with real usage. Attestations can expire or be revoked. When a required input decays, the satisfaction reading changes and the control loop rechecks affected parents.

The original feature or issue remains closed as a historical delivery record. New remediation work is filed at the most concrete useful level after scoped judgment. This avoids reopening the past while still refusing to call stale behavior healthy.

Decisions behave like case law

Architecture decisions live in a ledger with source authority, affected contracts, and formal supersession. A newer ruling cites and overrules the older one; the old record remains visible but no longer authoritative.

Routine analogous cases can apply precedent. Security, authority, system-boundary, founding-property, and genuinely ambiguous changes escalate. Accepted decisions name a propagation owner and a closure query so stale operational prose does not quietly survive beside the new rule.

Memory has owners

Supernova does not put every useful fact in one database:

• the wiki owns requirements and evidence obligations;
• monitor owns current evidence claims;
• issues own imperative work history;
• Kafka owns the correlated event trail;
• VCS owns code history;
• agents own disposable personal memory and derived indexes.

These stores can reference each other without competing for authority. Wiping an agent’s memory does not erase product truth; rebuilding a client library does not destroy state.

The validator is part of the build

The repository validator checks document contracts, requirement graph integrity, spec/source path mapping, annotations, evidence references, test symbols, and coverage joins. Broken traceability is a build failure, not a documentation task deferred until after shipping.

What is working now

The trace validator, requirement graph, per-file specifications, source annotations, decision ledger, and broad test mapping are active in the Supernova repository today. Production evidence collection and long-window freshness are less complete than in-repository trace proof. See project state.