Skip to content

Temporary-Solution Expiry Review

Lifecycle ritual — instantiates Inventory-Bounded Resource Recomposition

A scheduled forcing function that makes a team consciously renew, formalize, replace, or dismantle an improvised configuration — so a stopgap can't quietly become permanent by default.

Every improvised configuration is meant to be temporary, and almost none are — the make-do fix outlives the emergency that justified it and calcifies into permanent, unowned patchwork. Temporary-Solution Expiry Review breaks that drift with a single move: it attaches an expiry date to the improvisation at the moment it is created, and at that date forces a conscious decision — renew for a bounded extension, formalize it into a supported solution, replace it via procurement, or dismantle it and roll back. Its defining feature is that the trigger is time, set in advance, not a failure or a complaint. The review doesn't build anything; it is the calendar entry that refuses to let "temporary" become permanent by default, and makes someone own the choice either way.

Example

A highway authority closes a corroded overpass and stands up a temporary at-grade signal and pedestrian detour in a weekend — an improvisation cobbled from a spare signal controller, jersey barriers, and painted crosswalks. Because it works, the pressure to revisit it evaporates. At creation, though, the crew books a Temporary-Solution Expiry Review for six months out and writes down the condition for each outcome.

At the review the options are laid on the table deliberately. Renew? — acceptable for one more season while design funds are sought, but not indefinitely. Formalize? — no; an at-grade signal was never meant to carry this corridor's volume. Replace? — the review fires the external-procurement trigger, releasing the capital request for a permanent structure now that the stopgap has bought time to fund it. Dismantle? — only once the replacement opens, following the pre-planned removal of barriers and return of the borrowed controller. The detour still stands, but now on a decided, dated path to replacement rather than by forgotten default — and the spare controller it borrowed is scheduled to come back.

How it works

  • Set the expiry at birth. The improvisation is created with a review date and an owner attached, before the pressure to revisit it disappears.
  • Force one of four outcomes. At the date, the team must choose explicitly — renew (bounded), formalize, replace, or dismantle — and no-decision is not an available answer.
  • Fire procurement when replacement is the answer. If the verdict is to replace, the review releases the external-procurement request the stopgap was buying time for.
  • Route to the exit path. Whichever outcome is chosen, hand off to the corresponding upgrade, formalization, or demobilization plan rather than leaving the configuration in limbo.

Tuning parameters

  • Expiry horizon — how far out the review is set. A short horizon catches drift early but can force a premature call while the emergency is still live; a long one gives the stopgap room but risks entrenchment before anyone looks.
  • Renewal cap — how many times a temporary solution may be renewed before renewal is taken off the table. A hard cap prevents indefinite extension by installments; a soft one preserves flexibility at the cost of permanence-by-drift.
  • Trigger type — purely calendar-based, or also tripped by usage or condition thresholds. Adding condition triggers catches a stopgap that degrades faster than expected, at the cost of more monitoring.
  • Decision authority — how senior the sign-off must be. Higher authority makes the formalize/replace commitment stick but slows the review; lower keeps it nimble but easier to rubber-stamp into another renewal.

When it helps, and when it misleads

Its strength is that it makes the cost of permanence a scheduled, visible decision instead of an accident. Improvised configurations accrue technical debt — the accumulating cost of a quick fix left in place — and the expiry review is the forced repayment date that keeps that debt from compounding invisibly.[1] It is the mechanism that most directly answers the maxim that nothing is as permanent as a temporary fix.

Its failure modes are subtle because the ritual can be performed hollowly. The commonest is the rubber-stamp renewal — the review meets, renews by reflex, and the temporary solution becomes permanent one approved extension at a time; a renewal cap is the guard. It can also fire too early and dismantle a stopgap still doing useful work, or too late, after the improvisation has already been built upon and can no longer be cleanly removed. And a review with no teeth — no authority to release procurement or fund removal — merely documents the drift it was meant to stop. The discipline that keeps it honest is a real decision owner, a hard cap on renewals, and treating "renew" as the exception that must be argued for, not the default.

How it implements the components

Temporary-Solution Expiry Review realises the lifecycle-governance side of the archetype — the components that decide an improvisation's end state:

  • upgrade_or_demobilization_path — the review routes the configuration onto one of its exits: renew, formalize (upgrade), or dismantle (demobilize), rather than leaving it in indefinite limbo.
  • external_procurement_trigger — when the verdict is to replace, the review releases the procurement request the stopgap was buying time to fund.

It governs the exit, not the build or the bookkeeping: configuration_record belongs to the Configuration Change Log and provenance_and_maintenance_record to the Salvage and Cannibalization Workflow. The review consumes those records to decide; it does not produce them.

Notes

The trigger being time rather than failure is the whole point: a review that fires only when the stopgap breaks has already missed the window in which replacing it was cheap and orderly. Booking the expiry at creation, while the improvisation's temporary status is still self-evident, is what makes the later decision possible.

References

[1] Technical debt names the deferred cost of choosing a quick, expedient solution over a proper one — cheap now, more expensive the longer it stays. The expiry review is the scheduled point at which that debt is either repaid (formalize/replace) or explicitly refinanced (a bounded renewal). ↩