Autonomy with constitutional limits

Supernova does not ask one safety mechanism to answer every question. It separates identity, capability, exceptional authority, correctness, and external execution so that each decision has a clear owner and an auditable boundary.

Five different questions

Passing one layer never implies passing another. A capable agent may still need approval. An approved change may still fail review. A correct result does not grant the implementer more authority.

Capabilities, not special names

Policy refers to capability groups such as review, approval, VCS, operations, or external-link authority—not to a favored agent name. Ephemeral agents begin with no capabilities and receive only the project-scoped grants their job requires.

The operating system and container boundary enforce the floor beneath the application-level checks. A denial is a real branch, not an invitation for the system to auto-request a bypass. The agent may adapt its plan or explicitly request a narrowly scoped elevation.

Approval is constitutional

Approval governs exceptions and protected changes. Routine, reversible judgment can be delegated to the configured capability holder or established precedent. Irreversible actions, safety-policy changes, founding architecture changes, and other protected cases route to the primary human principal.

Requests cannot lower the operation owner’s minimum risk classification. A one-shot elevation grants exactly the approved command and is consumed on use.

Roles cannot judge themselves

• Implementers do not review or approve their own work.
• Reviewers certify correctness but cannot authorize protected execution.
• Approvers authorize the exception; they do not replace review evidence.
• CUJ stewards maintain outcome definitions but do not implement or close the work they govern.
• A candidate Supernova version cannot change the policy used to admit that candidate.

This separation is more important than any model’s promise to be careful. The incentives and powers remain distinct even when every role happens to be filled by an agent.

One external door

All outbound actions—messages, email, provider mutations, infrastructure changes, and other third- party effects—flow through link. The link system verifies identity, capability, approval scope, credential materialization, and provider receipts before reporting success.

Inbound material follows the reverse trust boundary. Verified trusted events may enter normal chat or bus flows. Unknown external content goes through ingest, where capability-stripped readers classify it and two separate gates judge intent and output quality. Raw hostile text is never treated as an instruction merely because an agent can read it.

flowchart TD
    agent["Agent proposes action"] --> permission["Permission check"]
    permission --> approval["Approval when required"]
    approval --> link["Single egress owner"]
    auth["Auth + scoped credentials"] --> link
    link --> outside["External system"]
    outside --> ingest["Trust-tiered intake"]
    ingest --> bus["Internal event trail"]

What is working now

The repository contains working identity, permission, approval, external-action, encrypted-secret, and ingest slices with fail-closed tests and local provider exercises. Broader live provider-network coverage and some production materialization paths remain open. See project state.