AGPL-3.0-or-later · forever.

NEP-0000

The NEP Process

Active · **DORMANT until the v1 pre-freeze** (process NEP · never Final) · Process · opened 2026-07-18 · 1105 words

NEP-0000 · The NEP Process #

  • NEP: 0000
  • Title: The NEP Process
  • Author: SuperNovae Studio maintainers
  • Status: Active · DORMANT until the v1 pre-freeze (process NEP · never Final)
  • Type: Process
  • Created: 2026-07-18
Dormant, and this is what wakes it: the pre-freeze of the language at v1. A proposal process only has meaning against something FROZEN. Before the freeze there is nothing to propose against — a new law is written directly into `spec/`, and the deep breaks live inside v1 itself. On 2026-08-13 the twenty Standards-Track drafts were resolved on exactly that reading: eighteen became the language, two were never built and are buried as such, and `README.md` records where each one went.This process becomes load-bearing at the pre-freeze, when every change is a proposal again — the maintainers included. An `Active` status with zero open proposals is not a dead ceremony: it is a mechanism waiting on a named trigger. That sentence is here because a reader concluded the opposite in under an hour, and a clause that says why it sleeps beats a status you have to guess.

Abstract #

A NEP (Nika Enhancement Proposal) is the public, numbered document through which every evolution of the Nika standard is proposed, discussed and decided. This document defines the process itself: the lifecycle, the template, who decides, and how the process evolves.

Pre-ratification clause. Until 1.0.0 ratifies the language, the spec on main is the draft and the draft evolves directly — so this era opens no Standards Track NEP: a law is written into spec/ where it belongs, and the numbers already spent stay load-bearing in engine code and traces (see `README.md` for what each resolves to). From the pre-freeze on, this process is binding: nobody amends the standard directly, the maintainers included.

The lineage is deliberate: PEP 1 governs Python this way, the KEP process governs Kubernetes (itself taken from Rust's RFCs, themselves shaped by PEPs), and the TC39 stages govern JavaScript. A standard earns trust when its evolution has one public door.

Motivation #

Three effects, proven by the processes above:

  1. Credible neutrality. A third-party vendor proposes an evolution through the same door the maintainers use. That is the condition for rival runtimes to adopt the spec at all.
  2. Fork resistance. Fragmentation, relicensing, capture and dialects share one antidote: a public evolution process nobody can confiscate.
  3. A navigable freeze. Post-1.0 the surface is frozen, additive only. Without a proposal process, frozen means dead. With one, frozen means stable and governed: the NEP is the vehicle of every legal addition.

Specification #

Lifecycle #

text
Draft → Discussion → Accepted | Rejected → Implemented → Final
  • Draft: a PR adding governance/nep-NNNN-<slug>.md from the template. The number is the next free integer, claimed by the PR itself.
  • Discussion: public, in the PR and its linked issue. There is no private track.
  • Accepted / Rejected: decided per the Decision authority below. A rejected NEP stays published with its rationale. The record of noes is worth as much as the record of yeses: it prevents relitigating.
  • Implemented: the reference engine ships it behind a green conformance suite, and the spec text is amended by the NEP's cascade.
  • Final: the amendment is part of the frozen surface. Process NEPs (like this one) stay Active instead: they may be amended by a successor NEP.

Types #

  • Standards Track: changes the language surface, the stdlib contract, the conformance suite or the trace format.
  • Process: changes how Nika evolves (this document is one).
  • Informational: records a design position without changing anything.

Decision authority #

Today: the SuperNovae Studio maintainers, by explicit written acceptance in the NEP's PR. Tomorrow: when three to five independent vendors ship conformant runtimes, authority transfers to a technical committee they seat together. That transfer is itself a Process NEP, proposed through this same door.

Numbering and the founding era #

NEP numbering runs through this door from NEP-0000 onward, and a number is spent for good — the twenty folded on 2026-08-13 are not recycled. The pre-1.0 rulings are the founding era: their verbatim record (the RULINGS documents and the ADR line) remains canonical history, not retroactive NEPs. One retroactive exception is reserved: NEP-0001, "the nika: v1 language surface", a Standards Track summary of the constitution as frozen at 1.0, so the language has one readable front door.

Relationship to conformance #

An accepted Standards Track NEP is not Implemented until the conformance suite proves it. The public claim « Nika v1 Conformant — <Level> (spec <commit>) » (the one claim string · spec/07 §Claiming conformance) is earned by passing the suite, never by declaration. A NEP that cannot state its conformance test does not leave Discussion.

The ratchet is same-PR: an Accepted Standards Track NEP lands its conformance fixtures in the implementing PR — the spec text amendment, the registered error codes, and the fixtures that prove them arrive together, never separately. A registered error code without a fixture is a spec bug. (The precedent: MCP made a conformance scenario a Final-gate for every SEP — SEP-2484; this door holds the same bar.)

What a NEP is not #

  • Not a bug report: defects in the engine go to the engine tracker.
  • Not documentation: docs follow the spec, they do not amend it.
  • Not a fork of authority: a NEP the maintainers (today) or the committee (tomorrow) rejected does not become a dialect. Divergent runtimes lose the compatibility claim per the conformance rule.

How to propose #

  1. Copy governance/nep-template.md to governance/nep-NNNN-<slug>.md (next free number).
  2. Fill every section. "Rejected alternatives" and "Compatibility impact" are mandatory: an empty alternatives section means the design was not explored.
  3. Open the PR. Discussion happens there. Silence is not consent: a NEP advances only by explicit acceptance.

Rejected alternatives #

  • GitHub issues as the process: issues have no lifecycle, no template discipline, and vanish from the reading order. A numbered file in git is citable forever.
  • RFC-style mailing list: the studio is small and the audience is developer-first. The PR is where the diff and the debate share a page.
  • Waiting until vendors exist to define the process: the process must predate its first external user, or the first external proposal arrives with no door to knock on. Foundations land before the peak.

Compatibility impact #

None. This NEP is additive: it creates governance/ and binds nothing retroactively. The pre-1.0 gate (rulings, migrations, conformance work) proceeds unchanged.