CEP Format¶

Catalyst Enhancement Proposals capture one clear coherent proposed idea, not a bag of roughly adjacent future features. If a draft starts needing several independent acceptance criteria, split it into focused CEPs and link them through Related Details.

CEP files use cep-NNNN-kebab-case-title.md, where NNNN is the next four-digit number in the proposal index.

Each CEP should use this shape:

# CEP-NNNN: Title

!!! status "Draft"
    One-sentence status and V1 boundary.

## Summary

## Motivation

## Proposed Direction

## Example

## V1 Compatibility

## Related Details

Code examples are highly encouraged. If a proposal affects source syntax, public APIs, configuration, generated output, reflection shape, or diagnostics, include one or more short examples unless they would be misleading. Mark examples as possible future shape, illustrative output, invalid V1, or rejected alternatives so readers do not mistake draft syntax for accepted language. Prefer tiny examples that show the semantic pressure behind the proposal over large end-to-end programs.

Use optional sections when they clarify the proposal, such as Dependencies, Representation Direction, Open Questions, Rejected Alternatives, or a focused topic heading. Keep accepted V1 rules out of CEPs except where needed to explain compatibility. Active docs should link to the CEP for future direction and remain the source of truth for current behavior.

Before adding a CEP, check whether the idea has one owner question and one acceptance path. If the proposal combines separate mechanisms such as inference, overloading, and named arguments, split those mechanisms into separate CEPs even when they interact.

When adding, renaming, superseding, accepting, or rejecting a CEP, update Catalyst Enhancement Proposals and any active docs that point at the old location or status.