STD-GOV-133: ADR Lifecycle Standard¶

Field	Value
Standard	STD-GOV-133
Title	ADR Lifecycle Standard
Status	Draft
Owner	CDO
Created	2026-04-03
Review	Annually

Purpose¶

Define the lifecycle states, transitions and governance for Architecture Decision Records (ADRs) at Simpaisa. ADRs are the primary mechanism for documenting significant architectural decisions. Without a defined lifecycle, ADRs become stale, contradictory or ignored. This standard ensures every ADR has a clear status, is reviewed periodically and is properly superseded when better alternatives emerge.

Scope¶

All ADRs in Standards/ADR/. Covers creation, review, approval, deprecation and supersession. Applies to all technology domains: API, Data, Security, Infrastructure, Platform, AI, Mobile, Product, Observability and Web.

Lifecycle States¶

Proposed → Accepted → Deprecated → Superseded
                ↑                       │
                └───────────────────────┘
                  (new ADR replaces old)

State	Description	Who Can Set
Proposed	ADR drafted. Under review. Not yet authoritative.	Any engineer
Accepted	Approved by ARB. Authoritative. Teams must follow.	ARB
Deprecated	No longer recommended. Better alternative identified but not yet formalised.	ARB
Superseded	Replaced by a newer ADR. The superseding ADR is linked.	ARB

Transition Triggers¶

Proposed → Accepted¶

Trigger: New technology choice, architectural pattern or significant design decision requiring team alignment.
Process: Author submits ADR → ARB pre-read (3 business days) → ARB meeting review → Approval.
Approval: ARB quorum (Chair + 2 members). Chair (CDO) has final authority.
Outcome: Status updated to Accepted. Implementation may begin.

Accepted → Deprecated¶

Trigger: A better alternative has been identified through experience, technology evolution or changed requirements. The existing ADR is no longer the recommended approach, but no replacement ADR has been written yet.
Process: ARB identifies the ADR as outdated → Status changed to Deprecated → Beads issue created to write replacement ADR.
Restrictions: Deprecated ADRs should not be used for new work. Existing implementations may continue until superseding ADR is accepted.

Deprecated → Superseded¶

Trigger: A replacement ADR has been written and accepted by the ARB.
Process: New ADR accepted → Old ADR status changed to Superseded → Link to superseding ADR added.
Format: Add Superseded by: [ADR-XXX-NNN](./ADR-XXX-NNN.md) to the old ADR metadata table.

Accepted → Superseded (Direct)¶

In cases where the replacement ADR is written before the old one is formally deprecated, the transition can go directly from Accepted to Superseded.

ADR Naming Convention¶

Format: ADR-{DOMAIN}-{YYYY}-{MM}-{NNN}.md

Component	Description	Example
Domain	Technology domain	API, DATA, GOV
YYYY-MM	Year and month of creation	2026-04
NNN	Sequential number within domain	024

ADR Template Requirements¶

Every ADR must contain (see Standards/ADR/ADR-TEMPLATE.md):

Title — Clear, descriptive title including the decision.
Metadata table — Status, date, decision maker, domain, review date.
Context — Why this decision is needed. Current state, problems, constraints.
Decision — What was decided and why.
Consequences — Positive and negative impacts.
Alternatives considered — What else was evaluated and why it was rejected.
Compliance impact — PCI DSS, central bank regulations, data residency.
Migration path — How to implement the decision (if applicable).

Annual Review¶

Cadence: All ADRs reviewed annually at the Q1 ARB meeting.
Scope: Every ADR in Accepted status.
Review criteria:
Is the decision still valid given current context?
Has the technology landscape changed?
Are teams following the decision in practice?
Is there a better alternative now?
Outcome per ADR: Reaffirm (no change), Deprecate (flag for replacement), or Supersede (if replacement already exists).

Technology Radar Linkage¶

Each ADR should reference the relevant Technology Radar entry:

ADR adopting a technology → Technology Radar entry moves to Adopt.
ADR rejecting a technology → Technology Radar entry remains at Assess or moves to Hold.
ADR deprecating a technology → Technology Radar entry moves to Hold or Retire.

Updates to TECHNOLOGY-RADAR.md must accompany ADR status changes.

Metrics¶

Metric	Target	Measurement
ADRs in Proposed > 30 days	0	Monthly check
Accepted ADRs without review date	0	Quarterly audit
Deprecated ADRs without replacement	0 (within 90d)	Quarterly audit
ADR coverage of major decisions	100%	ARB self-assessment

Current ADR Inventory¶

As of 2026-04-03, the Standards/ADR/ directory contains ADRs across these domains:

Domain	Count	Status Distribution
API	10+	Majority Proposed, pending ARB review
Platform	8+	Majority Proposed
Security	10+	Majority Proposed
Data	6+	Majority Proposed
AI	3+	Majority Proposed
Observability	2+	Proposed

Priority: Backlog all existing ADRs for ARB ratification (see STD-GOV-124 Action 4).

Actions¶

#	Action	Owner	Deadline
1	Add review dates to all existing ADRs	Platform Lead	2026-Q2
2	Schedule Q1 annual ADR review at ARB	CDO	2026-Q2
3	Backlog all Proposed ADRs for ARB ratification	Platform Lead	2026-Q2
4	Create ADR status dashboard	Platform Lead	2026-Q3
5	Link all ADRs to Technology Radar entries	Platform Lead	2026-Q3

References¶

Standards/ADR/ADR-TEMPLATE.md
STD-GOV-124-ARCHITECTURE-REVIEW-BOARD-CHARTER.md
TECHNOLOGY-RADAR.md
STD-GOV-126-TECHNOLOGY-LIFECYCLE-MANAGEMENT.md