Contribute to Capacity Atlas
Use a pull request for canonical data or Lean code. Use an issue to discuss uncertain claims before editing.
Add a capacity problem
Copy an existing file in data/problems. A problem is not merely a channel name. It fixes the information pattern, constraints, error criterion, and requested quantity.
- Choose a stable lowercase identifier and matching YAML filename.
- Specify the channel model so a reader can reconstruct the problem without opening a paper.
- Record the current result as an exact formula, characterization, region, or explicit lower and upper bounds.
- Add primary references to
data/references.yaml. - For an open entry, explain the bottleneck and concrete forms of progress.
Update a bound
Bounds are first-class records. Do not replace a number without preserving its provenance and conditions.
bounds:
- id: descriptive-bound-id
direction: lower
relation: 'C \ge R'
method: One-sentence description of the code or converse.
year: 2026
conditions: Optional parameter range.
references: [paper-id]
For numerical or computer-assisted results, link the paper and note the certificate or implementation in the method or notes field. The initial release does not display non-Lean proof-assistant artifacts as formal proofs.
Add a Lean formalization
Reuse the definitions in lean/CapacityAtlas. Add a shared abstraction only when at least two entries can plausibly use it.
- Add the Lean file and import it from
lean/CapacityAtlas.lean. - Prove all stochasticity and well-formedness obligations.
- Use no
sorry,admit, or hidden axiom. - List every displayed declaration in the problem YAML.
- Set the status conservatively: definitions, statement, partial, or complete.
A complete badge means the capacity claim shown on the page is proved. A valid channel definition alone earns the definitions badge, not a proof badge.
Run the same checks as CI
python -m pip install -e '.[dev]'
make check
cd lean
lake build
make check validates the schema, reference identifiers, Lean file links, named declarations, Python tests, formatting, and a complete static-site build.
What maintainers review
- The model and rate convention are unambiguous.
- Every factual claim has a primary source.
- The displayed bounds are current and carry their parameter ranges.
- Open-problem language distinguishes conjecture from theorem.
- Formalization status matches what Lean actually checks.
- The contribution stays small enough to maintain.