# Maintaining the method

A pricing method is not set once. Rates change, items come and go, the operator refines how they
charge, and a better history may arrive later that is worth re-learning from. Maintenance keeps the
method correct across those changes without losing what was already established.

## Re-learning preserves prior manual adjustments

When the method is re-learned from history — because new artifacts arrived, or the first derivation
was incomplete — the operator's prior manual adjustments are preserved, not overwritten. An operator
who corrected a derived rate by hand, or added an item the artifacts missed, must not have that
correction silently reverted by the next derivation. A re-learn that would drop a prior manual
adjustment is a failure: surface the conflict to the operator and let them decide, rather than quietly
choosing the freshly-derived value.

This is why provenance matters (see [learning-from-history.md](learning-from-history.md)): an element
the operator set by hand is distinguishable from one derived from an artifact, so a re-learn knows
which it must not clobber.

## Every change re-verifies

Any maintenance pass — a re-learn, an added or retired item, a changed rate or roll-up step — is
followed by re-running verification against the operator's own history (see
[verification.md](verification.md)). The reconciliation must still be green to the operator's
precision. A change that is recorded but breaks reproduction of a past job is not done; either the
change is wrong, or a past fixture is no longer representative and the operator confirms which.

## The outcome, not a storage scheme

Maintenance is defined by two outcomes — prior manual adjustments survive, and reproduction stays
green — not by any particular way of versioning or storing the method. How the method is held is the
operator's data; what maintenance guarantees is preservation and re-verification.
