Standards Lifecycle
Managing technology standards through explicit states with review dates, so the standard set reflects current reality rather than past decisions.
Standards without a lifecycle become a list of what was true when someone last cared, and they are therefore ignored — first by the teams furthest from the centre, then by everyone.
The states that make a standard set live: emerging (permitted for evaluation, with a review date), standard (the default, supported, expected), contained (in use, not for new work, no expansion permitted), retiring (with a date and a migration path), and prohibited, with the reason recorded.
Three things make the difference between a maintained set and a stale one:
Scheduled review with a date on every entry. A standard with no review date is permanent by default, which is how estates end up mandating technology nobody would choose today.
A named owner per standard, accountable for the review.
A published exception process with a decision, a record and a review — because a standard with no exception path is either ignored or followed into obviously wrong outcomes.
The scope discipline that keeps it credible: standardise where variation costs more than it is worth — security controls, identity, observability, deployment — and leave genuine variation alone. A standards set that reaches into every library choice will not be respected on the decisions that matter.