Override Expiry Workflow¶

Governance process — instantiates Controlled Inheritance Propagation

Gives every override an expiry date so it must be re-justified, renewed, or removed and backfilled to the inherited default — stopping temporary exceptions from silently becoming permanent.

Override Expiry Workflow is the temporal governance mechanism for exceptions. Every override in an inheritance system starts life as a local deviation from an inherited default; without a clock, those deviations accumulate forever and nobody remembers why. This workflow attaches an expiry to each override — a review date or time-to-live — and drives a recurring cycle: at expiry the override must be re-justified and renewed, or retired and backfilled so the descendant returns to the current inherited default. Its defining idea is that an exception's default fate is removal: overrides are guilty until re-proven, which is what keeps the override surface from silently ratcheting upward over years.

Example¶

A company's baseline firewall policy inherits down to every business unit. A team needs a temporary hole — inbound access to a vendor IP for a six-week integration. Instead of a permanent exception, they file it through the override-expiry workflow: the rule is granted with an expiry about eight weeks out and a named owner. As the date nears, the workflow notifies the owner and forces a choice. The integration is done, so the override is retired and the descendant is backfilled to the inherited baseline — the hole closes automatically. Had the access still been needed, the owner would have had to re-justify it for a bounded renewal rather than let it drift on unreviewed.

Multiply that across hundreds of "temporary" exceptions and the workflow is the difference between a policy that slowly rots into Swiss cheese and one where every live deviation is current, owned, and time-boxed.

How it works¶

Register with an expiry. Every override is recorded with an owner, a justification, and an expiry (fixed date or TTL).
Prompt a decision at expiry. As the date nears, the workflow forces a choice — renew (re-justify for another bounded term), retire (remove and backfill to the inherited default), or promote (the exception is really the new norm, so push it up into the ancestor and stop treating it as an exception).
Backfill on retirement. Retiring an override triggers a migration plan that brings the descendant back onto the current inherited value safely, checking nothing had come to depend on the lapsed exception.
Default inaction to removal. An override whose review lapses defaults to retirement or a safe hold, so doing nothing shrinks the exception surface instead of perpetuating it.

Its distinguishing move is that it acts on time: the trigger is a clock, and the default outcome of doing nothing is that the exception disappears — the inverse of how untended overrides normally behave.

Tuning parameters¶

Default term length — how long an override lives before review. Short terms keep the surface fresh but cost review churn; long terms cut churn but let staleness build.
Lapse behavior — what happens when a review is missed: auto-retire (safe by default, but can yank a still-needed exception), auto-hold, or auto-renew (convenient, but defeats the purpose). The single most consequential dial.
Backfill strategy — on retirement, snap straight to the inherited default, or migrate gradually with validation. Immediate is clean for reversible settings; staged suits risky ones.
Promotion threshold — how many descendants must share an override before it is promoted into the ancestor rather than renewed everywhere — the signal that the "exception" is actually the rule.
Review rigor — rubber-stamp renewal versus fresh re-justification. Heavier review resists expiry theater but taxes owners.

When it helps, and when it misleads¶

Its strength is that it fixes the one thing a static override register never does — decay. Exceptions that were justified at creation and obsolete a year later get caught, and the default-to-removal stance means the override surface shrinks unless someone actively keeps a deviation alive. It also surfaces which "temporary" overrides are really permanent and belong in the baseline.

Its failure mode is that the workflow is only as real as its lapse behavior and review rigor. Auto-renew or rubber-stamped reviews turn it into expiry theater — the ceremony of dates with none of the discipline — and every override becomes permanent again, now with extra paperwork. The opposite failure bites too: naive auto-retire can close a still-needed exception at 2 a.m. and cause the very outage the override was preventing. The framing to borrow is the legislative sunset clause — a provision that lapses unless actively renewed — which works only when renewal demands genuine re-justification rather than a signature.^[1] The discipline is to default to safe retirement, require real re-justification to renew, and pair expiry with impact-checking so a backfill never breaks a descendant that quietly came to rely on the exception.

How it implements the components¶

Override Expiry Workflow realizes the lifecycle side of the archetype — governing how exceptions end, not how they propagate:

override_review_and_sunset_rule — its core: every override carries an expiry and a recurring renew / retire / promote review, so no deviation outlives its justification.
migration_and_backfill_plan — on retirement it brings the descendant back onto the current inherited default safely, closing the exception without breakage.

It does NOT count or cap the number of live overrides — that budget check is Inheritance Lint or Static Analysis; it does not predict what retiring an override will disturb downstream — that's Lineage Impact Analysis Report; and it does not define how the default it backfills to propagates — that's Configuration Inheritance Tree.

Instantiates: Controlled Inheritance Propagation — the lifecycle process that keeps the override surface from silently becoming permanent.
Consumes: Lineage Impact Analysis Report to check what a retirement and backfill will affect before it lands.
Sibling mechanisms: Inheritance Lint or Static Analysis · Lineage Impact Analysis Report · Configuration Inheritance Tree · CSS Cascade and Specificity Rule · Effective Configuration Diff · Object-Oriented Class Inheritance · Template Clause Override Register · Permission Inheritance with Explicit Denial · Policy Inheritance Matrix · Prototype Delegation Chain · Platform Variant Option Model · Schema Extension and Override Check · Trait or Mixin Composition Rule

References¶

[1] A sunset clause is a legislative or contractual provision that automatically expires on a set date unless it is deliberately renewed. Its whole force comes from the default being expiry, so the burden falls on whoever wants the exception to continue — the same logic this workflow applies to inherited overrides. ↩