Capability Lifecycle Economics
Capabilities are not just born and promoted — they live, branch, contend, age, and die; this section covers the lifecycle the maturity ladder alone does not answer.
Why This Section Exists
Section 8 specifies how capabilities are promoted. The full lifecycle is more than that. Capabilities are also forked, merged, fragmented, contested, abandoned, and retired. They consume maintenance burden that grows or shrinks with usage. This section covers the lifecycle questions the maturity ladder alone does not answer — and it is the area of v0.4 with the least production evidence.
Lifecycle Events Beyond Promotion
| Event | Description |
|---|---|
| Creation | New L1 capability registered |
| Promotion | L1 → L2, L2 → L3 (Section 8) |
| Fork | Divergent variant created, typically by a cell with specialized needs |
| Merge | Two related capabilities unified into one |
| Fragmentation | Capability split into multiple smaller capabilities |
| Ownership Transfer / Dispute | Maintainer changes, or parties contest direction |
| Demotion / Deprecation / Retirement / Archive | Movement down, marked for removal, removed, or removed-but-retained-for-audit |
When Does a Capability Die?
A capability should be retired when any of the following is true:
- Superseded — another capability does it better and cells are migrating naturally
- Adoption collapse — L1 unused 6+ months; L2 fewer than 2 cells 6+ months; L3 below 30% with declining trend
- Maintenance burden exceeds value — the maintainer spends more keeping it current than it returns
- The underlying problem has changed — absorbed into the kernel, or this is now the wrong solution
- The capability is causing harm — consistent workslop, hidden cost, repeated trace anomalies
Deprecation Mechanics
| Level | Minimum Migration Window | Rationale |
|---|---|---|
| L1 | None required | No commitments made |
| L2 | 90 days | Cells need time to plan and migrate |
| L3 | 180 days | Wide adoption means many cells migrate |
| L3 + critical | 12+ months | Some L3 deprecations are major organizational events |
During the window the deprecated capability keeps working, the catalog marks it with the sunset date, and the Inspector Pipeline tracks remaining adopters. The default for a missed sunset should be to force the migration rather than extend indefinitely — indefinite-extension capabilities become zombies.
Forks, Merges, Fragmentation
The worst fork is the silent fork: a cell modifies a copy without registering it, so cells reading the catalog assume they use the canonical version when each has its own diverged copy. The kernel should detect this through telemetry — agents declaring spec-writer@2.1 but behaving differently are flagged. Merges are right when two capabilities address substantially the same problem (>70% overlap); fragmentation is right when one capability has accreted unrelated functionality. The general principle: let the shape emerge from usage; don't impose it ahead of usage.
Ownership Disputes
A capability's direction is not always agreed. Kernel maintainers mediate maintainer disagreements; conflicting cell directions are resolved by choosing one, fragmenting, or adding an optional surface. The healthy norm: a capability without a willing maintainer must be deprecated, regardless of adoption.
Maintenance Burden Economics
| Level | Maintainer Time (est.) | Why |
|---|---|---|
| L1 | 0-5% of an engineer | Best-effort; no commitments |
| L2 | 5-15% of an engineer | Issue response, version maintenance, migration support |
| L3 | 15-30% of an engineer | Multi-cell support, deeper backward compatibility, longer windows |
Decreasing burden is the healthy long-term pattern. Increasing burden — adoption growing faster than economy of scale, or the kernel evolving faster than the capability keeps up — is a signal: invest more, fragment, or retire.
Don't let capabilities zombie. Don't fork silently. Don't merge prematurely. When the lifecycle event happens, declare it explicitly and follow the structural process.