KEP-NNNN: Enhancement title

Modeled on the Kubernetes Enhancement Proposal format – the most rigorous public proposal template in open source. Heavyweight: use for changes that need graduation criteria and test planning, not for small features.

Field	Value
KEP number	NNNN
Title	Short descriptive title
Status	provisional / implementable / implemented / deferred
Authors	@name
Reviewers	@a, @b
Approvers	@lead
Created	YYYY-MM-DD
Stage	alpha / beta / stable

Summary

One paragraph: what is proposed, understandable by a non-specialist.

Motivation

Why this enhancement matters – evidence, user pain, scale of impact.

Goals

• Measurable goal one
• Measurable goal two

Non-goals

• Explicitly excluded

Proposal

User stories

1. As a [role], I want [capability] so that [outcome].
2. As a [role], I want [capability] so that [outcome].

Notes/constraints/caveats

• Caveat readers must know upfront

Risks and mitigations

Risk	Mitigation
Risk one	Mitigation

Design details

The technical proposal – APIs, data flow, state machines, diagrams.

flowchart TD
    A[Component] --> B[Component]

Test plan

How this is proven correct:

• Unit tests: what is covered
• Integration tests: scenarios
• E2E tests: user-visible paths
• Performance: benchmarks

Graduation criteria

Alpha

• Feature behind flag, disabled by default
• Basic e2e test

Beta

• Enabled by default for N% of users
• Metrics/dashboards exist
• Feedback collected from N users

Stable / GA

• N releases in beta with no critical bugs
• Docs complete
• Upgrade/downgrade tested

Upgrade / downgrade strategy

Behavior when rolling forward and back – data migration safety.

Dependencies

• Dependency and its readiness state

Alternatives

What was considered and why this won.

Drawbacks

Honest costs of doing this – complexity, maintenance, lock-in.

Open questions

• Unresolved item – owner