> For the complete documentation index, see [llms.txt](https://docs.opendatadiscovery.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0078-confirm-and-store-reduce-field-edits.md).

# ADR-0078: Editing a consequential field uses a change-preview confirmation that reduces into the store

## Status

**Accepted.** Reconstructed from the codebase on 2026-06-15 — the entity lifecycle-status control is the established implementation; the 0.28.0 DQ-test severity work (odd-platform#1750) is the newest adopter and the reason the pattern is written down.

## Context

Some editable fields are not cosmetic — their value drives downstream display or semantics that other people and systems trust:

* a data entity's **lifecycle status** (`STABLE` / `DRAFT` / `DEPRECATED` / `DELETED`) drives soft-delete, lineage and group relations, and the header status badge;
* a **DQ-test severity** (`MINOR` / `MAJOR` / `CRITICAL`) drives the dataset's aggregate SLA RED / ORANGE / GREEN colour an operator trusts at a glance.

For such a field two properties matter: a change must be **deliberate** — a single unconfirmed gesture must not silently reclassify a trusted signal — and the rendered value must equal the **persisted record**, never an optimistic local guess that can diverge if the write fails. The status control already solved this; the severity control had drifted into the opposite shape (an instant fire-and-forget save, an uncontrolled select, no store reduction), which is the defect odd-platform#1750 fixes.

## Decision

**A field whose value drives downstream display or semantics is edited through a confirmation, and the persisted result is reduced into the store. No optimistic instant-save.** Concretely:

1. A **selectable control**, not an auto-committing input: choosing a new value opens a **confirmation dialog** (the shared `ConfirmationDialog`) rather than persisting immediately.
2. The confirmation **previews the change** (old → new) and carries any **additional change configuration** the field needs (for example the status switch-time / propagate options; many fields, such as severity, need none).
3. The mutation is **awaited**, with the success / error toast surfaced; on failure nothing is persisted and the displayed value stays the stored value.
4. The server result is **reduced into the store** (a slice `extraReducers` case, or an action such as `updateEntityStatus`) so the rendered value derives from the persisted record without a refetch.
5. The displayed value **derives from the store** (controlled), keyed by the current record, so navigating between records never bleeds one record's value onto another.

Reference implementation: the entity-status control — `SelectableEntityStatus` + `StatusSettingsForm` + the `updateEntityStatus` reducer. Newest adopter: DQ-test severity (`SelectableSeverity`), shipping in 0.28.0.

## Consequences

* A consistent, deliberate, non-divergent way to edit any consequential field; new such fields conform rather than re-deciding the interaction each time.
* No new shared primitive — the pattern composes `ConfirmationDialog` and the existing menu / select controls, all already shipped.
* A confirm step per change is the accepted cost; it is right for fields that drive trusted signals and is **not** intended for trivial cosmetic inputs, which stay plain controls.
* This ADR is descriptive — it standardises the existing pattern and directs reuse; it does not mandate retrofitting every editable field at once.