# Lifecycle strategies

> Condition-triggered maintenance and rehabilitation events - roof recoats, boiler retubes, overhauls - that extend asset life, carry costs, and bend the condition projection.

Source: https://app.assetlab.ca/docs/asset-management/lifecycle-strategies

A renewal forecast that only knows "purchase year plus expected lifetime" assumes you never touch an asset between buying it and replacing it. Real programs recoat roofs, retube boilers, and overhaul air handlers - interventions that cost a fraction of replacement and buy years of life. Lifecycle strategies model exactly that: named events that fire when an asset's projected condition reaches a trigger window, extend its life or restore its condition, and carry their own fixed cost.

Strategies are managed under **Strategy** in the left nav, open to Managers and Administrators. The same capability exists for [infrastructure features](/docs/infrastructure/lifecycle-strategies), scoped to their own tiers - both run on one shared projection engine, and an organization that has both modules gets them as two tabs on that one page (**Facilities** and **Infrastructure**). A facilities-only organization sees no tabs at all.

## Before you start

A strategy is read-time math over what an asset already carries, so three things have to be in place before any curve can draw. Set them up in this order:

1. **Turn on age-based condition estimates.** **Settings → Organization → Estimate condition from age**. Assets that have never been assessed then show an age-implied condition (marked with a ~ and a dashed border) everywhere condition appears, so a fleet you have not inspected yet still reads as something other than blank. The lifecycle projection falls back to that same age-implied condition on its own for a never-assessed asset, but with the toggle off you only see the fallback on the projection card, not on the lists and dashboards beside it.
2. **Give each asset type a service life.** **Categories → Asset Types → add or edit a type → Service life**, in years. The asset type is the tier between a system and an individual asset - "Fan coil", not "HVAC" and not "Fan coil #12" - and it is what a strategy is keyed to.
3. **Assign your assets to their asset types.** An asset with no type resolves no strategy and inherits no service life, so it is invisible to this whole feature. Once typed, it carries its type's service life without anyone re-entering the number per asset.

Each asset also needs an **in-service date** (its purchase date) and a **service life** - its own expected lifetime, or the one inherited from its type. With either missing the projection has no curve to draw and the card stays empty.

> [!note]
> Estimated conditions are display-only. They are never saved onto an asset, never overwrite a recorded score, and any [condition assessment](/docs/asset-management/condition-assessments) you record takes over as the anchor from the day it lands.

## How a strategy is scoped

A strategy is not assigned to assets one by one. It is keyed to the asset-type catalog:

- **An asset type** - "Condensing boiler", for that type's own strategy
- **An asset type group** - "HVAC", covering every type in the group that has no strategy of its own

Every asset resolves the most specific strategy that matches its type: its type's own strategy first, else its type's group strategy. Tiers never blend. Edit the strategy once and every matching asset re-projects. The asset's projection card names which tier answered, so there is never a mystery about where a projection came from.

Strategies deliberately do **not** scope by system. A system is a functional grouping - an asset can sit in several - while maintenance behaviour belongs to what the asset *is*, which is its type. Reporting still slices by system everywhere it already does.

## Events

Each event carries:

| Setting | What it does |
|---|---|
| **Type** | Preventative maintenance or rehabilitation |
| **Trigger window** | Fires when the projected condition falls to the window's upper bound. An asset already below the window has missed it |
| **Effect** | Adds years of life, or resets condition to a value ("a boiler retube sets condition to 100") |
| **Cost** | A fixed amount per application, with a cost source and a staleness flag after a year unconfirmed |
| **Max times applied / min years between** | Bounds recurring events like servicing |

Each event also carries a **Work generation** setting: what a due application of it should become - **plan only**, a **work order** (with a work category and priority you set once, on the event), or a **project**. It is a policy recorded with the strategy, not an automation: nothing is created on a schedule, and the Due interventions panel below is still where the record is created. The setting decides which button leads, and what the created record arrives carrying.

Replacement is deliberately **not** an event. The renewal forecast picks the year and the asset's replacement value prices it, exactly as before. A strategy changes what happens *before* replacement, and thereby when replacement lands.

## The projection

The strategy editor previews the classic sawtooth: condition declines, an event fires and lifts the curve, decline resumes, until replacement. Beside it: expected useful life with and without the strategy, and the cost per added year of life the strategy buys.

On an asset's own page (the bottom of its Overview) and on its detail sheet, the same chart shows the **last five years** alongside the forecast: every condition score recorded in that window is plotted to the left of today as a grey line with a point per reading, so the projection is read against what the asset has actually been doing. That half is observed and stops at today; the coloured line to the right is modelled. Where the newest reading is older than today the two are joined by a flat segment, which is what the model believes - an assessed score is carried forward unchanged until a new assessment lands. An asset newer than five years shows only back to its in-service date.

The forecast half is anchored at **that asset's state**, not a template:

- An assessed asset projects **from its assessed condition** - whatever the score - and re-anchors the day a new [assessment](/docs/asset-management/condition-assessments) lands.
- A never-assessed asset projects from its age, and the card says so.

The renewal year keeps its own discipline regardless: with no strategy events it is never later than the age-based end of life - a good score alone does not defer replacement; a strategy event that fires can.

An asset already past its age-based end of life has nothing left to project: the card shows **Past service life since** that year in place of a renewal year, the chart shades the time since, and no strategy event can fire, because a score does not move that date. A [betterment](/docs/asset-management/betterments) that adds service life does, and so does a new purchase date when the asset is replaced.

The projection needs a service life. The asset's own expected lifetime wins; when it has none, the **asset type's default service life** (set on the type under Categories) fills in - so a whole type of assets can project from one number maintained in one place.

A strategy supplies the interventions, not the curve, so the card does not wait for one. An asset carrying recorded [betterments](/docs/asset-management/betterments) charts without a strategy: the unassisted decline, each piece of capital work marked on the timeline at its own date and listed underneath with what it cost and the life it bought, and a pointer to set a strategy up when you want interventions modelled on top. Capital work buys service life, and where you record a condition with it, that score anchors the curve like any other reading. The life it buys flattens the curve and pushes the renewal out rather than stepping the line up. The dashed comparison line accounts for that: it is the asset with nothing recorded against it at all, neither strategy events nor capital work, so the gap between the two lines is everything you have done for it. Only an [assessment](/docs/asset-management/condition-assessments) moves a condition score. An asset with neither a strategy nor recorded work charts too - its unassisted decline is still the truth about it - with the pointer carried as a footnote under the chart rather than in place of it.

> [!tip]
> The projection knows when an asset has already fallen below an event's trigger window. The card flags it plainly: the cheap intervention was missed, and the model proceeds without it. That flag is your early warning that a preventative program is leaving money on the table.

> [!note]
> Nothing is ever written onto assets. The projection is read-time math; condition scores stay owned by assessments, and the strategy can be edited or removed at any time without touching asset data.

## The forecast believes the strategy

The strategy-adjusted renewal year is not confined to the asset's page. The Lifecycle tab of the dashboard - the forecast chart, the replacement table, and the summary cards - reads the same strategy-aware year through one shared resolver, so an asset whose recoat program defers replacement to 2041 forecasts, ranks, and prices by 2041 everywhere. With no strategies defined, nothing moves: the resolver's no-strategy answer is the forecast's historical math.

## Due interventions

A **Due interventions** panel appears the moment a strategy produces a row, in the [Planner](/docs/projects/replacement-planner) (facilities scope, Assets mode): assets whose projected condition sits inside an event's trigger window right now, grouped per event and priced, one click from becoming a work order or a project. A group's count and cost always cover every asset in it; on a large registry the group lists its first 200, and acting on the group acts on those. Assets that have already fallen below a window are listed separately - the cheap intervention was missed, and the panel prices what running late costs.

## In the Planner

The Planner reads the same strategy-aware renewal year as everywhere else. Each facilities recommendation card shows the forecast renewal year, with a **+N** chip when a strategy defers it - the "service it instead of replacing it" signal, visible before an asset is dragged onto the calendar. And the filter panel gains a **Lifecycle strategy** filter in both scopes: **Due intervention** and **Missed window**, so the recommendation list can be cut down to exactly what the strategies say to act on. The planned year you set by dragging remains the human-owned override, as before.

## Closing the loop

A work order created from the due-interventions list remembers which event it executes. When you complete it, AssetLab offers the outcome the event models - "Compressors Replacement resets condition to 70" - as a **condition assessment for you to confirm or correct**, pre-filled per asset, with a skip that costs nothing. Confirm it and the asset's condition moves, the curve re-anchors at the new score, the asset leaves the trigger window, and every forecast follows - the same as any assessment you record by hand, because that is exactly what it is.

The strategy never writes condition itself. A modelled reset is a projection, not an observation, and only [assessments](/docs/asset-management/condition-assessments) (or inspections, on the infrastructure side) author an asset's condition. Events that add years rather than restoring condition propose no score - there is no number to observe - so the prompt opens with the score blank.

## What the strategies are worth

The dashboard's **Assets** tab prices the whole program the moment a strategy covers an asset: a year-by-year cash flow of intervention costs and remaining replacements against the dashed run-to-replacement line, headline figures for replacement value deferred and years of life bought, and each strategy ranked by **cost per added year of life** - all in today's dollars. Assets that already fell below an intervention window are priced too: the section shows what the missed events would have cost, which is the budget case for funding the preventative program on time. The [infrastructure dashboard](/docs/infrastructure/lifecycle-strategies) has the same section for its strategies.

## API access

Lifecycle events are a full [API and MCP resource](/docs/reference/resources) (scope family `asset_lifecycle_events`): integrators and AI assistants can read and maintain strategies - "add a roof recoat event to the Roofing group at $12,000" - through the same scoped, tenant-bound access as every other resource.