Plans and ADRs

An Architecture Decision Record (ADR) is the human-readable explanation of a proposed change. In the CloudBooster portal it appears as a tab on the ChangeSet review screen — Markdown, rendered with headings, ready to read before you approve.

When you open the ADR tab, you read a short narrative: what's changing, why, what was considered instead, and what you'll have to live with.

What's in an ADR

Every ADR follows this shape. The Context section sets the scene; the Decision states the choice in plain language; Alternatives records what you didn't pick; Consequences names the tradeoffs you've accepted.

Who writes it

The CloudBooster planner writes the first draft from your intent. It's a starting point, not the final word — you can edit the ADR in the portal before approval. That's useful when you want to record a constraint the planner didn't capture ("we picked single-AZ because this is staging-only and the team accepts the failover risk").

The edited ADR is what's archived alongside the ChangeSet, so future readers see the reasoning you actually used.

A short example

## Decision
Provision Amazon RDS for PostgreSQL 16, db.t4g.medium, single-AZ,
50 GB gp3 storage, for the API service in staging.
 
## Alternatives considered
- Aurora Serverless v2 — rejected, cost floor exceeds expected usage.
- Self-host on EC2 — rejected, no operational capacity on the team.
 
## Consequences
- Multi-AZ failover is **not** enabled. Acceptable while staging-only.
- Backups retained 7 days by default.

Exporting an ADR

The ADR is plain Markdown, so you can copy it out of the portal and commit it to your repo for offline review or change history. What you see in the ADR tab is exactly what gets archived alongside the ChangeSet.

See also

• ChangeSets — where the ADR tab lives.
• Review a ChangeSet — the operational how-to.