Lifecycle model
Lifecycle describes the estate's intended treatment of a repository. It is not a quality score.
| State | Meaning | Default attention |
|---|---|---|
active | Current use or development justifies ongoing attention. | Quarterly review and truthful entrance. |
maintenance | Retained capability with bounded verification and no default feature pressure. | Annual review; semiannual for live data. |
candidate | Potentially useful, but no current consumer or authority decision justifies activation. | Consumer-triggered only. |
frozen | Preserved historical, educational, research, or institutional evidence. | Context and lineage, not modernization. |
superseded | Replaced by a named successor and no longer authoritative. | Successor link, then archive consideration. |
archived | Intentionally closed at GitHub-settings level. | No routine review. |
Lifecycle versus health
Lifecycle and health are independent.
A maintenance repository may require README or automation repair. A frozen repository may be excellent and complete. An active repository may have unknown runtime status. The registry therefore records lifecycle, health, front-door status, and verification separately.
Re-entry rule
Candidate, frozen, or superseded assets should not re-enter active work because they appear interesting.
Re-entry requires:
- a named current consumer;
- the exact capability needed;
- evidence that the capability is not already available elsewhere;
- the smallest extraction or verification that satisfies the consumer;
- an explicit authority decision.
Proposed assignments
Except where marked declared, current lifecycle values are working assignments derived from the 2026 estate audit. The README and lifecycle campaigns may confirm or revise them without changing repository identity or losing prior reasoning.
The machine-readable contract is estate/lifecycle.yaml.