Skip to content

Temporary Local Shim with Expiry

Time-boxed stopgap tool — instantiates Layer-Appropriate Capability Placement

Permits a narrow local stand-in for a missing host capability, but only with an explicit scope and a hard expiry date, so the stopgap can't quietly harden into a permanent shadow platform.

A Temporary Local Shim with Expiry is a sanctioned, deliberately small local implementation that stands in for a host capability which doesn't exist yet — built with two things a normal workaround lacks: a fixed scope and a hard expiry date. When the right layer can't serve a need today but will (the host feature is on the roadmap, the migration is in flight), the honest options are to block or to build a stopgap; the shim makes the stopgap safe by wiring in its own retirement from the start. It provides a temporary substitution path so work isn't blocked, while its expiry guarantees the duplicate facility is torn out once the host catches up — so the stand-in can't quietly graduate into the permanent local platform the archetype warns against. Its defining move is that it is born with an end date: a local build that is explicitly, contractually temporary.

Example

A product team needs a shared cache to hit its latency target, but the platform's official caching service is still six months from general availability. Blocking the product for two quarters is untenable; silently standing up a permanent private cache is how a shadow platform starts. The team files a Temporary Local Shim with Expiry instead: a small in-service cache, scoped to just this service's read paths, explicitly not a general-purpose store, with an expiry tied to the platform cache's GA date and a retirement ticket already written. The shim is tagged as temporary in code and in the architecture register, and its scope budget forbids it from growing into a multi-tenant store other teams start depending on.

When the platform cache ships, the expiry comes due: the retirement path executes — traffic cuts over to the host service, the local cache is deleted, the ticket closes. The team got its latency now, and the organization didn't inherit one more permanent local facility to maintain. Treated honestly, the shim is a piece of deliberate, time-boxed technical debt with the repayment already scheduled.[1]

How it works

  • Sanction a narrow stand-in. Permit a local implementation only as wide as the immediate need — a substitution for the missing host capability, not a general-purpose facility.
  • Fix the scope. Bound what the shim may do and, crucially, forbid it from growing new dependents, so it can't accrete into something too entangled to remove.
  • Set a hard expiry. Attach an explicit end condition — a date, or the host capability's arrival — and write the retirement ticket at creation, not later.
  • Retire on cue. When the expiry comes due, cut over to the host and tear the shim out; the built-in retirement path is what distinguishes a shim from a permanent local build.

Tuning parameters

  • Expiry basis — a fixed calendar date versus an event (host feature GA). Dates force review but can arrive before the host is ready; event-based waits for the host but can slip forever without a backstop.
  • Scope tightness — how narrowly the shim is fenced. Tighter is easier to retire but may not cover the need; looser covers more but grows retirement cost with every new dependent.
  • Dependent policy — whether other teams may build on the shim. Allowing it spreads the value and multiplies the pain of removal; forbidding it keeps the shim disposable.
  • Renewal rule — whether expiry can be extended, and how hard that is. Easy renewal is how "temporary" becomes permanent; a renewal that demands re-justification keeps the clock real.
  • Visibility — whether the shim is tagged as temporary in code and the architecture register. An untagged shim is indistinguishable from a permanent facility the moment its author moves on.

When it helps, and when it misleads

Its strength is that it unblocks work under a real host gap without paying for it in permanent duplication — the stand-in exists, and its removal is guaranteed by design rather than left to good intentions. It is the disciplined form of a stopgap: deliberate technical debt with the repayment already on the calendar.

Its whole risk lives in the word temporary. Expiries get extended, scopes creep, other teams quietly build on the shim, and the stand-in hardens into exactly the permanent shadow platform it was meant to avoid — the old truth that nothing is so permanent as a temporary solution. The misuse is the shim with a nominal expiry no one enforces, used to launder a permanent local build past architectural review under cover of "just until the host ships." The discipline that keeps it honest is to make the expiry load-bearing: an enforced end condition, a renewal that costs real re-justification, a ban on new dependents, and a Shadow-Platform Audit that catches shims which have quietly outlived their date.

How it implements the components

The shim fills the disciplined-stopgap side of the archetype — the components that let a subsystem survive a host gap without permanent duplication:

  • duplicate_facility_retirement_path — the shim's hard expiry is a retirement path: a local facility built with the mechanism of its own removal wired in from the start.
  • host_substitution_path — it provides the interim path by which the subsystem substitutes for the missing host capability, so work proceeds until the host can take over.

It is a stopgap, not a governor: it does not detect shims that have overstayed their expiry (that's Shadow-Platform Audit), decide whether the capability should instead be promoted into the host (that's the sibling Capability-Promotion Review), or grant out-of-band access to an existing host capability (that's Privileged Host Escape Hatch).

Notes

Despite the shared word "shim," this is not the Compatibility Bridge or Shim sibling: that one translates between two interfaces that must coexist and may live indefinitely, while this one stands in for a capability that doesn't exist yet and is defined by its expiry. The test is whether removal is the goal (this mechanism) or interoperation is (the bridge).

References

[1] Technical debt (Ward Cunningham's metaphor) frames a deliberate shortcut as borrowing against the future: useful if repaid on schedule, corrosive if left to accrue interest. A shim with an enforced expiry is the prudent, deliberate form — debt taken on knowingly with repayment already scheduled; an unenforced expiry is how it turns into the reckless kind. ↩