# ADR-0009: `obsvect` and `controlvect` derive their content from the `datavect` structure

| Field         | Value       |
|---------------|-------------|
| Kind          | ADR         |
| Status        | Accepted    |
| Decided       | historical  |
| Deciders      | Antoine Berchet |
| Supersedes    | —           |
| Superseded by | —           |

## Context

The observation vector (`obsvect`) and the control vector (`controlvect`) both need to
know, per component/tracer, which parameters exist and how they should be handled. Both
plugin types declare `datavect` as a hard requirement (`requirements = {"datavect": ...}`
in `pycif/plugins/obsvects/standard/__init__.py` and
`pycif/plugins/controlvects/standard/__init__.py`), and are built by walking the
`datavect` YAML block: `controlvect/standard`'s docstring states directly that "the
control vector is initialized according to the information specified in the data
vector," and for each datavect parameter, a set of primary/secondary YAML arguments on
that parameter decides whether and how it enters the control vector.
`obsvect/standard` organises `yobs`/`ysim`/`dy` by the same `component` / `tracer`
structure "as declared in the `datavect` YAML block."

## Decision

`obsvect` and `controlvect` do not maintain their own independent declaration of what
they contain. They fetch that information from `datavect`, which acts as the single,
centralised place where the user describes the data of the system.

## Consequences

- Centralising this in `datavect` means the user declares a component/tracer's data once,
  and both the observation side and the control side of the inversion derive their
  structure from that single declaration, rather than requiring the user to repeat or
  keep in sync two separate declarations.
- **Known weakness:** it is impossible to have an element in the control vector or the
  observation vector that is not defined in `datavect`. Anything obs/control-vector-only
  has no path into the system today.
- **Known weakness:** membership is implicit and error-prone. Whether a given `datavect`
  parameter ends up in the control vector (and how) is inferred from *which* optional
  primary/secondary arguments happen to be set on it, rather than from an explicit,
  readable declaration of "this parameter is/is not part of the control vector." The same
  applies on the observation side. A config author can misjudge what actually lands in
  either vector without an explicit error.
- These two weaknesses are expected to motivate a dedicated **RFC** in the near future
  (e.g. to make obs/control-vector membership explicit, and/or to allow elements that
  don't route through `datavect`). This ADR records the current, load-bearing state of
  affairs; it does not attempt to resolve it.