# How should an ADR record a decision with an explicit expiry date and revalidation trigger? > Record an ADR's expiry, measurable review triggers, owner, evidence, and exit path so temporary architecture decisions get revisited. Canonical URL: https://www.devobs.io/articles/qa-ge50-architectural-decisions-with-expiry-dates/ By: Jonah Reed Published: 2025-12-12T14:36:05.696Z Updated: 2026-09-06T10:18:15.722Z Section: Architecture Use a normal ADR, but treat temporary decisions as leases rather than permanent laws. Record not just the choice and consequences, but the decision horizon, exact expiry date, measurable revalidation triggers, named owner, evidence to collect, and the rollback or replacement path. That keeps the ADR faithful to the original purpose of preserving context while making it clear when the team must revisit the decision instead of silently inheriting it. ## Why add expiry and revalidation fields to an ADR? The core ADR pattern is still the right base: context, decision, status, and consequences, as described in [Documenting Architecture Decisions](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions). The problem is that reversible, assumption-heavy choices fail in a specific way: the ADR explains why the team took a shortcut, but not when that shortcut stops being acceptable. That gap matters for decisions such as a temporary queue, a feature-flagged subsystem boundary, or a stopgap data model during migration. The point is not to predict the future perfectly. It is to make the future testable. The general ADR guidance also emphasizes context and consequences as the durable value of the record, and ADR repositories commonly evolve decisions over time rather than deleting history, as reflected in the [Architecture Decision Record repository](https://github.com/joelparkerhenderson/architecture-decision-record). ## What should the ADR include beyond the standard template? Add five fields to the usual ADR structure: - Decision horizon: the period this choice is expected to remain valid. - Expires on: a calendar date. - Revalidation triggers: observable conditions that force review earlier than the date. - Owner: the team or role accountable for review. - Exit path: the replacement target and preconditions for rollback or migration. A good trigger is measurable, not interpretive. “Revisit when scale increases” is weak. “Revisit when sustained queue latency exceeds 200 ms for five business days” is usable. For feature-flagged designs, use triggers tied to carrying cost, because feature flags add operational and validation complexity; [Feature Toggles](https://martinfowler.com/articles/feature-toggles.html) is especially clear that teams should constrain long-lived toggles. Also capture the evidence link you expect to consult at review time: dashboard, cost report, dependency milestone, incident search, or schema-readiness ticket. ## What does a worked ADR look like? Here is a compact pattern for a temporary queue decision: **Title:** Use the primary database as a job queue for the billing backfill **Status:** Accepted **Context:** We need a backfill within six weeks. Throughput is currently below 20 jobs per second. Operating a dedicated broker now would delay the compliance deadline. **Decision:** We will use a database-backed queue for the backfill worker. **Decision horizon:** Valid only for the backfill phase. **Expires on:** 2026-12-15 **Revalidation triggers:** Review immediately if either average enqueue-to-start delay exceeds 2 minutes for 3 consecutive days, or worker retries caused by lock contention exceed 1% of jobs. **Owner:** Billing platform lead. **Evidence for review:** Queue latency dashboard, lock-wait report, weekly job volume, incident tickets. **Exit path:** Move to the broker-based design in ADR-042 once the broker service is production-ready and workers support idempotent consumption. **Rollback preconditions:** Before switching, verify idempotency keys are enforced and dead-letter handling is tested in staging. That last line is important. “Rollback” across unrelated systems is rarely a single atomic action. State the migration sequence: first add idempotency, then enable the new consumer, then drain the old path. ## How do teams keep expiry ADRs from rotting? Four failures show up repeatedly. First, an expiry date with no owner. Second, triggers that nobody measures. Third, an ADR that names a stopgap but not the escape hatch. Fourth, code and runbooks that keep depending on an assumption after the ADR should have expired. Operationalize the fix. Open the review ticket when the ADR is accepted, not later. Link the ADR to dashboards and migration issues. Review it during [production readiness](https://www.devobs.io/articles/production-readiness-review-evidence/) checks and incident follow-up. When the decision changes, keep the old ADR and mark it superseded instead of editing away the original reasoning. ## Follow-up Q&A? **Should every ADR have an expiry date?** No. Use it for decisions that are intentionally temporary, assumption-heavy, or contingent on a milestone, threshold, or external dependency. **Is a [feature flag](https://www.devobs.io/articles/feature-flag-operational-lifecycle/) itself enough to make a decision reversible?** No. The ADR should still record when the flag must be removed, what metrics justify keeping it, and what must be true before the old path can be retired. Next step: add an “expires on / revalidation triggers / owner / exit path” block to your ADR template this week, then retrofit it onto the stopgap decisions already in flight. Reviewed: 2026-09-05 ## Source references - - -