# RFC-NNNN: <Title>

| Field          | Value                                             |
|----------------|---------------------------------------------------|
| Author(s)      |                                                   |
| Status         | Draft \| Accepted \| Accepted-with-changes \| Rejected \| Deferred \| Superseded |
| Created        | YYYY-MM-DD                                         |
| Decided        | YYYY-MM-DD                                         |
| Reviewers      |                                                   |
| Supersedes     | RFC-____ (if any)                                 |
| Superseded by  | RFC-____ (if any)                                 |

## Summary

*One paragraph. What is changing and why, in language a new postdoc could follow.*

## Motivation / Problem

*What is wrong or missing today? What forces this change now? What breaks or stays painful if we do
nothing? Be concrete — name the configuration, the user, the failure.*

## Context & constraints  ← (theory transfer: assume the reader does NOT have it in their head)

*What must a reader hold in mind to evaluate this fairly? The relevant parts of the current
architecture, the data flow through the affected components, external constraints (HPC memory
budget, cluster environment, WMO/Copernicus/UNFCCC obligations, backward-compat promises to
existing CIF users). This is the section that lets someone reason about the change instead of just
trusting you.*

## Proposed design

*How it works. Interfaces, data structures, control flow. Diagrams welcome. Enough detail that a
reviewer can find the holes — but this is NOT the most important section; the ones around it are.*

## Alternatives considered  ← (this is the theory: the road not taken and WHY)

*For each serious alternative: what it was, and the specific reason it was rejected. "Wrap vs
rewrite," "GP vs NN surrogate," "DART as subprocess vs reimplementing the analysis step" — the
kind of decision where the reasoning is the real asset. Include the option of doing nothing.*

## Invariants & assumptions affected  ← (the tacit "never do X because Y")

*What currently-true properties could this touch? Check the ones relevant to CIF:*
- [ ] **Adjoint / tangent-linear consistency** — does the gradient still match the forward? How verified?
- [ ] **Numerical reproducibility** — do reference results change? Bit-for-bit, or within tolerance?
- [ ] **Mass conservation / physical invariants** in the transport or transform operators.
- [ ] **Plugin interface contract** — are existing plugins (LMDz, FLEXPART, TM5mp, CHIMERE, …) still valid?
- [ ] **Config / YAML backward compatibility** — do existing user setups still run? Migration needed?
- [ ] **On-disk / output format** compatibility.
- [ ] Ordering dependencies, global state, or other "obvious to me, invisible to everyone" traps.

## Impact

- **Affected components / plugins / instruments:**
- **Performance & memory** (esp. the host-RAM + GPU-HBM budget):
- **User-facing changes** (config, CLI, outputs):
- **Documentation** that must change:

## Validation plan  ← (how do we KNOW it's correct — not just that it runs)

*Which regression/characterization configs cover this? New gradient checks? A benchmark
configuration to compare before/after? What tolerance, and why that tolerance? Correctness in a
variational inversion framework is numerical, not obvious — make the evidence explicit.*

## Risks & open questions

*What might go wrong, what you're unsure about, what you're explicitly asking reviewers to weigh in
on. Honesty here is what makes the review useful.*

## Rollout / migration

*Phased or big-bang? Deprecation path for anything removed? What existing users must do, and how
they'll be told.*

## Decision  ← (filled in by the decider; this is what turns the RFC into an ADR)

**Outcome:**
**Date / decider:**
**Rationale (esp. if rejected or changed):**
**Follow-up issues / MRs:**