Tool lifecycle states
Lifecycle states record where each tool sits, from in use to being phased out, so your Map reflects current reality.
Last updated June 1, 2026
A stack is never static. Tools get adopted, retired, and replaced, and lifecycle states let the Forest Map reflect where each one stands today instead of freezing a snapshot from the day you added it.
Lifecycle state answers a simple question: is this tool actually carrying its mapped capabilities right now? A product you are sunsetting still appears in the catalog and still has mappings, but it should not be counted the same way as a tool in full production. Recording its state keeps your coverage picture honest.
State is what separates real coverage from paper coverage. A capability covered only by a tool you are phasing out is closer to a gap than it looks. Marking that tool as being retired surfaces the exposure before the contract lapses and leaves you blind.
Use lifecycle state to keep the Map current:
Reflect tools that are evaluated, in use, or on their way out.
Flag a tool being replaced so its overlap with the incoming tool reads as a planned transition, not waste.
Retire tools you no longer run so they stop inflating coverage.
A planned replacement is the one case where overlap is expected. Set lifecycle state so the Map reads it as a migration rather than redundant spend.
Lifecycle state works closely with two other views. It explains apparent duplication that overlap detection surfaces, and it tells you when removing a tool will affect the integration relationships others depend on. Keep states current and the Map keeps telling you the truth.