{"row":{"n":"0000","slug":"nep-0000-the-nep-process","file":"nep-0000-the-nep-process.md","headline":"The NEP Process","title":"The NEP Process","status":"Active (process NEP · never Final)","type":"Process","created":"2026-07-18","author":"SuperNovae Studio maintainers","lede":"A NEP (Nika Enhancement Proposal) is the public, numbered document through\nwhich every evolution of the Nika standard is proposed, discussed and\ndecided.","sections":[{"title":"Abstract","anchor":"abstract"},{"title":"Motivation","anchor":"motivation"},{"title":"Specification","anchor":"specification"},{"title":"How to propose","anchor":"how-to-propose"},{"title":"Rejected alternatives","anchor":"rejected-alternatives"},{"title":"Compatibility impact","anchor":"compatibility-impact"}],"words":870,"sha256":"891dbe82fd5d050d00fc81ce66718e55be4292c9f3d7f4d68a3b521c9c4557b5"},"prev":null,"next":{"n":"0002","slug":"nep-0002-lethal-trifecta-human-gate","file":"nep-0002-lethal-trifecta-human-gate.md","headline":"Lethal-trifecta detection with a Rule-of-Two human gate","title":"Make the lethal trifecta a static check with a required human gate","status":"Draft","type":"Standards Track","created":"2026-07-19","author":"Thibaut Melen (SuperNovae Studio)","lede":"Add a static check that fires when a workflow's declared capability boundary\ngrants all three legs of the lethal trifecta · private-data access, untrusted-\ncontent ingress, and external egress · without a human gate on the egress path.","sections":[{"title":"Abstract","anchor":"abstract"},{"title":"Motivation","anchor":"motivation"},{"title":"Specification","anchor":"specification"},{"title":"Conformance test","anchor":"conformance-test"},{"title":"Compatibility impact","anchor":"compatibility-impact"},{"title":"Migration plan","anchor":"migration-plan"},{"title":"Rejected alternatives","anchor":"rejected-alternatives"}],"words":1650,"sha256":"bf54b94c1aeb614c6e765e92d30ecb69158acf87589940c38e4d942da4f2c19c"},"total":18}

[{"k":"h","depth":1,"text":"NEP-0000 · The NEP Process","id":"nep-0000--the-nep-process"},{"k":"list","ordered":false,"items":[[{"k":"strong","text":"NEP"},{"k":"text","text":": 0000"}],[{"k":"strong","text":"Title"},{"k":"text","text":": The NEP Process"}],[{"k":"strong","text":"Author"},{"k":"text","text":": SuperNovae Studio maintainers"}],[{"k":"strong","text":"Status"},{"k":"text","text":": Active (process NEP · never Final)"}],[{"k":"strong","text":"Type"},{"k":"text","text":": Process"}],[{"k":"strong","text":"Created"},{"k":"text","text":": 2026-07-18"}]]},{"k":"h","depth":2,"text":"Abstract","id":"abstract"},{"k":"p","inline":[{"k":"text","text":"A NEP (Nika Enhancement Proposal) is the public, numbered document through\nwhich every evolution of the Nika standard is proposed, discussed and\ndecided. Nobody amends the standard directly, the maintainers included.\nThis document defines the process itself: the lifecycle, the template, who\ndecides, and how the process evolves."}]},{"k":"p","inline":[{"k":"text","text":"The lineage is deliberate: "},{"k":"link","text":"PEP 1","href":"https://peps.python.org/pep-0001/"},{"k":"text","text":"\ngoverns Python this way, the\n"},{"k":"link","text":"KEP process","href":"https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/0000-kep-process/README.md"},{"k":"text","text":"\ngoverns Kubernetes (itself taken from Rust's RFCs, themselves shaped by\nPEPs), and the "},{"k":"link","text":"TC39 stages","href":"https://tc39.es/process-document/"},{"k":"text","text":" govern\nJavaScript. A standard earns trust when its evolution has one public door."}]},{"k":"h","depth":2,"text":"Motivation","id":"motivation"},{"k":"p","inline":[{"k":"text","text":"Three effects, proven by the processes above:"}]},{"k":"list","ordered":true,"items":[[{"k":"strong","text":"Credible neutrality."},{"k":"text","text":" A third-party vendor proposes an evolution\nthrough the same door the maintainers use. That is the condition for\nrival runtimes to adopt the spec at all."}],[{"k":"strong","text":"Fork resistance."},{"k":"text","text":" Fragmentation, relicensing, capture and dialects\nshare one antidote: a public evolution process nobody can confiscate."}],[{"k":"strong","text":"A navigable freeze."},{"k":"text","text":" Post-1.0 the surface is frozen, additive only.\nWithout a proposal process, frozen means dead. With one, frozen means\nstable and governed: the NEP is the vehicle of every legal addition."}]]},{"k":"h","depth":2,"text":"Specification","id":"specification"},{"k":"h","depth":3,"text":"Lifecycle","id":"lifecycle"},{"k":"code","lang":"text","text":"Draft → Discussion → Accepted | Rejected → Implemented → Final"},{"k":"list","ordered":false,"items":[[{"k":"strong","text":"Draft"},{"k":"text","text":": a PR adding "},{"k":"code","text":"governance/nep-NNNN-<slug>.md"},{"k":"text","text":" from the template.\nThe number is the next free integer, claimed by the PR itself."}],[{"k":"strong","text":"Discussion"},{"k":"text","text":": public, in the PR and its linked issue. There is no\nprivate track."}],[{"k":"strong","text":"Accepted / Rejected"},{"k":"text","text":": decided per the Decision authority below.\nA rejected NEP stays published with its rationale. The record of noes\nis worth as much as the record of yeses: it prevents relitigating."}],[{"k":"strong","text":"Implemented"},{"k":"text","text":": the reference engine ships it behind a green\nconformance suite, and the spec text is amended by the NEP's cascade."}],[{"k":"strong","text":"Final"},{"k":"text","text":": the amendment is part of the frozen surface. Process NEPs\n(like this one) stay "},{"k":"strong","text":"Active"},{"k":"text","text":" instead: they may be amended by a\nsuccessor NEP."}]]},{"k":"h","depth":3,"text":"Types","id":"types"},{"k":"list","ordered":false,"items":[[{"k":"strong","text":"Standards Track"},{"k":"text","text":": changes the language surface, the stdlib contract,\nthe conformance suite or the trace format."}],[{"k":"strong","text":"Process"},{"k":"text","text":": changes how Nika evolves (this document is one)."}],[{"k":"strong","text":"Informational"},{"k":"text","text":": records a design position without changing anything."}]]},{"k":"h","depth":3,"text":"Decision authority","id":"decision-authority"},{"k":"p","inline":[{"k":"text","text":"Today: the SuperNovae Studio maintainers, by explicit written acceptance\nin the NEP's PR. Tomorrow: when three to five independent vendors ship\nconformant runtimes, authority transfers to a technical committee they\nseat together. That transfer is itself a Process NEP, proposed through\nthis same door."}]},{"k":"h","depth":3,"text":"Numbering and the founding era","id":"numbering-and-the-founding-era"},{"k":"p","inline":[{"k":"text","text":"NEP numbering runs through this door from NEP-0000 onward — a pre-1.0\nDraft claims its number the same way (NEP-0002 is the living proof).\nThe pre-1.0 rulings are the founding era: their verbatim record (the\nRULINGS documents and the ADR line) remains canonical history, not\nretroactive NEPs. One retroactive exception is reserved: NEP-0001,\n\"the nika: v1 language surface\", a Standards Track summary of the\nconstitution as frozen at 1.0, so the language has one readable front\ndoor."}]},{"k":"h","depth":3,"text":"Relationship to conformance","id":"relationship-to-conformance"},{"k":"p","inline":[{"k":"text","text":"An accepted Standards Track NEP is not Implemented until the conformance\nsuite proves it. The public claim « Nika v1 Conformant — "},{"k":"text","text":"<Level>"},{"k":"text","text":"\n(spec "},{"k":"text","text":"<commit>"},{"k":"text","text":") » (the one claim string ·\n"},{"k":"link","text":"spec/07 §Claiming conformance","href":"../spec/07-conformance.md#claiming-conformance"},{"k":"text","text":")\nis earned by passing the suite, never by declaration. A NEP that cannot\nstate its conformance test does not leave Discussion."}]},{"k":"p","inline":[{"k":"text","text":"The ratchet is same-PR: an Accepted Standards Track NEP lands its\nconformance fixtures in the implementing PR — the spec text amendment,\nthe registered error codes, and the fixtures that prove them arrive\ntogether, never separately. A registered error code without a fixture\nis a spec bug. (The precedent: MCP made a conformance scenario a\nFinal-gate for every SEP — SEP-2484; this door holds the same bar.)"}]},{"k":"h","depth":3,"text":"What a NEP is not","id":"what-a-nep-is-not"},{"k":"list","ordered":false,"items":[[{"k":"text","text":"Not a bug report: defects in the engine go to the engine tracker."}],[{"k":"text","text":"Not documentation: docs follow the spec, they do not amend it."}],[{"k":"text","text":"Not a fork of authority: a NEP the maintainers (today) or the committee\n(tomorrow) rejected does not become a dialect. Divergent runtimes lose\nthe compatibility claim per the conformance rule."}]]},{"k":"h","depth":2,"text":"How to propose","id":"how-to-propose"},{"k":"list","ordered":true,"items":[[{"k":"text","text":"Copy "},{"k":"code","text":"governance/nep-template.md"},{"k":"text","text":" to "},{"k":"code","text":"governance/nep-NNNN-<slug>.md"},{"k":"text","text":"\n(next free number)."}],[{"k":"text","text":"Fill every section. \"Rejected alternatives\" and \"Compatibility impact\"\nare mandatory: an empty alternatives section means the design was not\nexplored."}],[{"k":"text","text":"Open the PR. Discussion happens there. Silence is not consent: a NEP\nadvances only by explicit acceptance."}]]},{"k":"h","depth":2,"text":"Rejected alternatives","id":"rejected-alternatives"},{"k":"list","ordered":false,"items":[[{"k":"strong","text":"GitHub issues as the process"},{"k":"text","text":": issues have no lifecycle, no template\ndiscipline, and vanish from the reading order. A numbered file in git\nis citable forever."}],[{"k":"strong","text":"RFC-style mailing list"},{"k":"text","text":": the studio is small and the audience is\ndeveloper-first. The PR is where the diff and the debate share a page."}],[{"k":"strong","text":"Waiting until vendors exist to define the process"},{"k":"text","text":": the process must\npredate its first external user, or the first external proposal arrives\nwith no door to knock on. Foundations land before the peak."}]]},{"k":"h","depth":2,"text":"Compatibility impact","id":"compatibility-impact"},{"k":"p","inline":[{"k":"text","text":"None. This NEP is additive: it creates "},{"k":"code","text":"governance/"},{"k":"text","text":" and binds nothing\nretroactively. The pre-1.0 gate (rulings, migrations, conformance work)\nproceeds unchanged."}]}]

NEP-0000

The NEP Process

Active (process NEP · never Final) · Process · opened 2026-07-18 · 870 words

NEP-0000 · The NEP Process #

NEP: 0000
Title: The NEP Process
Author: SuperNovae Studio maintainers
Status: Active (process NEP · never Final)
Type: Process
Created: 2026-07-18

Abstract #

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

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:

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.
Fork resistance. Fragmentation, relicensing, capture and dialects share one antidote: a public evolution process nobody can confiscate.
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

1Draft → 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 — a pre-1.0 Draft claims its number the same way (NEP-0002 is the living proof). 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 #

Copy governance/nep-template.md to governance/nep-NNNN-<slug>.md (next free number).
Fill every section. "Rejected alternatives" and "Compatibility impact" are mandatory: an empty alternatives section means the design was not explored.
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.

This proposal in the spec repo The specification it amends