Keep it alive

A model answers a question and the question is decided. Then the model sits. Deciding whether to keep it is a real decision, and the honest answer is usually no.

Retire it well

Publish the inputs, the outputs, the check and the sources, with a date. Write one page saying what question it answered and what it should not be used for. Then stop. A model that is archived with its data is worth more than one that limps on unmaintained and is trusted by mistake.

If it lives

A model that people act on continuously, a flood forecast, a traffic operations model, a network twin, needs four things that a project model does not:

1. An owner whose job includes it, by name.
2. A data feed that is monitored, so that a gauge that stops reporting is noticed before the model goes quiet.
3. A standing check against what happens, repeated on a schedule, with the result published. See the check.
4. A budget for the three above, approved for more than one year.

Without all four, it is a project model with a long tail, and should be retired instead.

Keep the question in view

Live models drift from the question they were built for, and begin to be asked things they were never checked against. Keep the sentence from the first guide on the front page of the model, and say no to questions outside it until it has been checked for them.

Keep the people

The users change, the operators change, the people affected stay. Tell them, once a year, what the model is doing with their place and their data. That is the privacy note kept current.

An ontology is part of what drifts. Jessica Talisman's point that the day a vocabulary is deployed is the day it starts to drift, and that maintenance is the project rather than a phase at its end, is in the review of The Ontology Pipeline.

This site

The same rule applies here. Entries carry a date and a source so that a reader can see when they were last checked, and nothing is promoted from draft until a person has read its sources.