# System Design Review Checklist: [System or design name]

> Checklist and scoring rubric for reviewing a system design, for design
> reviewers in engineering organisations and for interviewers running a
> system design interview. It covers thirteen areas: requirements and
> scope, estimation, API, data model and access patterns, consistency per
> write path, single points of failure, scalability, failure modes,
> security and privacy, operations and SLOs, cost, migration and rollout,
> and evolvability. Each area is scored on a four-level rubric defined by
> observable evidence, red flags block approval, and the review ends with a
> recorded decision. Section 8 gives a 45-minute interview variant. The
> checklist draws on common industry practice and on public methods such as
> the SEI Architecture Tradeoff Analysis Method (ATAM) and the AWS
> Well-Architected Framework. Replace every `[bracketed]` value and every
> row marked *Example*.

<!--
Guidance: How to use this template
- Send the checklist to the design author before the review, so the
  document answers the questions instead of the meeting.
- Score only on evidence in the document or shown in the review. "We will
  handle that" is level 1 (asserted), not level 2.
- Record a finding for every score below 2 and for every red flag; a score
  without a finding gives the author nothing to fix.
- This checklist reviews a design; it does not replace the design. The
  author writes the System Design Document Template
  (`system-design/system-design-document`) or a `design-*` reference
  design. For a formal board submission use Architecture Review Board
  Request Template (`architecture/architecture-review-request`); for a
  scenario-based evaluation of quality attributes, Architecture Evaluation
  Report Template (ATAM) (`architecture/atam-evaluation`).
- Pitfall: reviewers who redesign the system in the meeting. Ask
  questions, record findings, and let the author choose the fix.
-->

## Document control

<!-- Guidance: Pin the exact version of the design under review. A score applies to that version only. -->

| Field | Value |
|---|---|
| Document ID | [SDR-2026-001] |
| Version | [0.1] |
| Status | [Draft / In review / Decision recorded] |
| Owner (lead reviewer) | [@lead-reviewer] |
| Approvers / reviewers | [@reviewer-1], [@reviewer-2], [@security-reviewer] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Design under review | [Title], [document ID], [version or commit] |
| Design author(s) | [@author] |
| Review mode | [Design review / Interview (section 8)] |
| Review date | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Lead reviewer | [@name] | [Approved / Approved with conditions / Changes required] | YYYY-MM-DD |
| Security reviewer | [@name] | [Decision] | YYYY-MM-DD |
| Operations / SRE reviewer | [@name] | [Decision] | YYYY-MM-DD |
| Design owner (acknowledges findings) | [@name] | [Acknowledged] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Pre-read scores |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Scores after review meeting; findings SDR-F-001 to SDR-F-006 |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Decision recorded: approved with conditions |

## Contents

<!-- Guidance: Keep this list in step with the headings below. -->

1. [Review scope and inputs](#1-review-scope-and-inputs)
2. [Scoring rubric](#2-scoring-rubric)
3. [Checklist by area](#3-checklist-by-area)
4. [Score summary](#4-score-summary)
5. [Red flags](#5-red-flags)
6. [Findings register](#6-findings-register)
7. [Review record and decision](#7-review-record-and-decision)
8. [Interview mode: 45-minute rubric](#8-interview-mode-45-minute-rubric)
9. [Glossary and references](#9-glossary-and-references)

## 1. Review scope and inputs

<!-- Guidance: State what is being decided and what is not. A review without a stated decision drifts into a brainstorm. Questions: what decision does this review unblock, and what inputs did reviewers receive? -->

| Item | Value |
|---|---|
| Decision this review supports | [*Example:* Start implementation of the payment ledger in Q1] |
| In scope | [*Example:* Write path, ledger storage, reconciliation, rollout] |
| Out of scope | [*Example:* UI, pricing, vendor contract] |
| Inputs received | [Design document link, ADRs, load test results, threat model] |
| Pre-read deadline | YYYY-MM-DD |
| Reviewers and focus | [*Example:* @a data model, @b reliability, @c security] |

Rules for this review:

1. Reviewers score each area independently before the meeting, then agree
   on one score per area in the meeting.
2. A reviewer who cannot find evidence for a check marks it "No evidence"
   rather than guessing.
3. Checks that do not apply are marked N/A with a one-line reason; an N/A
   area is removed from the weighted total (section 4).

## 2. Scoring rubric

<!-- Guidance: Levels describe evidence, not opinion. Two reviewers who read the same document should land on the same level. Pitfall: scoring on how confident the author sounded. -->

Every area in section 3 is scored on one scale:

| Level | Name | Observable evidence |
|---|---|---|
| 0 | Missing | The area is not addressed in the document or the review |
| 1 | Asserted | The area is mentioned, but claims have no reasoning, numbers or alternatives ("it will scale", "we use retries") |
| 2 | Reasoned | Claims are backed by numbers, a named mechanism and at least one rejected alternative with the reason |
| 3 | Evidenced | Level 2 plus evidence that the claim holds: a prototype, load test, failure drill, measurement from a comparable system, or a cited and applicable reference |

Area-specific anchors, so reviewers calibrate the same way:

| Area | Level 1 looks like | Level 3 looks like |
|---|---|---|
| Estimation | "Millions of users" | Inputs, formulas, results and the design consequence of each number, checked against measured traffic |
| Consistency | "Strongly consistent database" | Each write path named with its guarantee, isolation level and the anomaly it prevents, with a test that shows it |
| Failure modes | "Highly available" | Failure table with detection, blast radius, mitigation and RTO, and a game day result for the top two |
| Security | "Uses TLS and auth" | Threat model with trust boundaries, data classification, and controls traced to threats |
| Cost | "Should be cheap" | Unit cost model per request or per tenant, with the largest line item and how it scales |

## 3. Checklist by area

<!-- Guidance: Each check names the evidence a reviewer looks for. Score the area, not each line; the lines help you find gaps. Use the Notes column for the location in the design document. -->

### 3.1 Requirements and scope (A1)

| ID | Check | Evidence expected | Notes |
|---|---|---|---|
| SDR-A1-01 | Problem and users stated, with the business driver | Problem statement, success metric | [Section ref] |
| SDR-A1-02 | Core functional requirements separate from below-the-line items | Two explicit lists | |
| SDR-A1-03 | Non-functional requirements have numbers and a measurement method | Table with target and "measured as" | |
| SDR-A1-04 | Assumptions and constraints listed (team, deadline, existing systems) | Assumptions table | |
| SDR-A1-05 | Decisions requested from reviewers are explicit | Question list with recommended option | |

### 3.2 Estimation (A2)

| ID | Check | Evidence expected | Notes |
|---|---|---|---|
| SDR-A2-01 | Peak rate, not only average, for reads and writes | Peak-to-average factor stated | |
| SDR-A2-02 | Storage growth over the planning horizon, with replication | Formula and result | |
| SDR-A2-03 | Each number ends in a design consequence | "So we ..." sentence per estimate | |
| SDR-A2-04 | Orders of magnitude sanity-checked against a known system | Comparison or measurement | |

See Back-of-Envelope Estimation and Capacity Model Template
(`system-design/back-of-envelope-estimation`).

### 3.3 API (A3)

| ID | Check | Evidence expected | Notes |
|---|---|---|---|
| SDR-A3-01 | Operations, inputs, outputs and errors defined | API table or schema | |
| SDR-A3-02 | Idempotency for retried writes | Idempotency key or natural key semantics | |
| SDR-A3-03 | Pagination, limits and rate limits | Stated limits | |
| SDR-A3-04 | Versioning and compatibility policy | Versioning rule | |
| SDR-A3-05 | Authentication and authorization per operation | Scope or permission per call | |

### 3.4 Data model and access patterns (A4)

| ID | Check | Evidence expected | Notes |
|---|---|---|---|
| SDR-A4-01 | Entities and relationships drawn | ER diagram or schema | |
| SDR-A4-02 | Access-pattern table: query, key or index, partition key rationale | Table covering every hot query | |
| SDR-A4-03 | Hot partitions and skew considered | Named hot keys and mitigation | |
| SDR-A4-04 | Store choice justified by access pattern, not habit | Comparison of at least two stores | |
| SDR-A4-05 | Retention, deletion and archival defined | Retention table | |

### 3.5 Consistency per write path (A5)

| ID | Check | Evidence expected | Notes |
|---|---|---|---|
| SDR-A5-01 | Every write path listed with its consistency guarantee | Table: path, guarantee, mechanism | |
| SDR-A5-02 | Multi-step writes have a defined atomicity strategy (transaction, outbox, saga) | Sequence diagram with failure between steps | |
| SDR-A5-03 | Read-after-write expectations stated per client | Which reads may be stale and for how long | |
| SDR-A5-04 | Concurrency control for contended records | Locking, conditional writes or version checks | |
| SDR-A5-05 | Duplicate and out-of-order events handled | Deduplication key, ordering scope | |

### 3.6 Single points of failure (A6)

| ID | Check | Evidence expected | Notes |
|---|---|---|---|
| SDR-A6-01 | Every component on the critical path has redundancy or an accepted risk | Component list with redundancy column | |
| SDR-A6-02 | Shared dependencies (DNS, identity, secrets, config) identified | Dependency list | |
| SDR-A6-03 | Leader or coordinator failover described and timed | Failover mechanism and duration | |
| SDR-A6-04 | Human single points (one person who can deploy or recover) | Ownership and runbooks | |

### 3.7 Scalability (A7)

| ID | Check | Evidence expected | Notes |
|---|---|---|---|
| SDR-A7-01 | Scaling unit of each component named (replicas, shards, partitions) | Table "scales by" | |
| SDR-A7-02 | First bottleneck identified with the load at which it appears | "Limit before redesign" | |
| SDR-A7-03 | Behaviour at 10x and at 0.1x discussed | Trade-off row | |
| SDR-A7-04 | Latency budget per hop for the main path | Budget table | |

### 3.8 Failure modes (A8)

| ID | Check | Evidence expected | Notes |
|---|---|---|---|
| SDR-A8-01 | Failure-mode table: component, failure, detection, blast radius, mitigation, RTO | Table | |
| SDR-A8-02 | Timeouts, retries with backoff and jitter, circuit breakers | Values per dependency | |
| SDR-A8-03 | Overload behaviour: load shedding, back-pressure, priorities | Mechanism | |
| SDR-A8-04 | Fail-open versus fail-closed decided per dependency | Table with rationale | |
| SDR-A8-05 | Backup, restore and disaster recovery with RPO and RTO | Targets and test plan | |

See Resilience and Load Shedding Design Template
(`system-design/resilience-load-shedding-design`).

### 3.9 Security and privacy (A9)

| ID | Check | Evidence expected | Notes |
|---|---|---|---|
| SDR-A9-01 | Threat model with trust boundaries | Link to threat model | |
| SDR-A9-02 | Data classified; personal data minimised and mapped | Data inventory | |
| SDR-A9-03 | Authentication and authorization model, including service-to-service | Identity design reference | |
| SDR-A9-04 | Secrets, keys and encryption in transit and at rest | Key management description | |
| SDR-A9-05 | Abuse cases and rate limits | Abuse table | |
| SDR-A9-06 | Audit logging for security-relevant actions | Event list | |

Run the detailed analysis in Threat Model Template (`security/threat-model`)
and, where the design changes trust boundaries, Zero Trust Architecture Plan
Template (`security/zero-trust-architecture`).

### 3.10 Operations and SLOs (A10)

| ID | Check | Evidence expected | Notes |
|---|---|---|---|
| SDR-A10-01 | SLIs and SLOs defined for user-facing behaviour | SLO table | |
| SDR-A10-02 | Dashboards and alerts tied to SLOs, not only to resources | Alert list | |
| SDR-A10-03 | Runbooks for the top failure modes | Runbook links | |
| SDR-A10-04 | Deployment strategy (canary, blue-green) and rollback time | Deploy plan | |
| SDR-A10-05 | On-call ownership and escalation | Team and rotation | |

### 3.11 Cost (A11)

| ID | Check | Evidence expected | Notes |
|---|---|---|---|
| SDR-A11-01 | Cost estimate by component | Cost table | |
| SDR-A11-02 | Unit economics (cost per request, per user or per tenant) | Formula | |
| SDR-A11-03 | Largest cost driver and how it scales | Named driver | |

### 3.12 Migration and rollout (A12)

| ID | Check | Evidence expected | Notes |
|---|---|---|---|
| SDR-A12-01 | Migration plan for existing data and clients | Backfill, dual-write or dual-read plan | |
| SDR-A12-02 | Milestones with exit criteria | Milestone table | |
| SDR-A12-03 | Feature flags and rollback for each step | Rollback per step | |
| SDR-A12-04 | Verification during migration (shadow traffic, diff reports) | Method | |

### 3.13 Evolvability (A13)

| ID | Check | Evidence expected | Notes |
|---|---|---|---|
| SDR-A13-01 | Decisions recorded as ADRs with revisit triggers | ADR links | |
| SDR-A13-02 | Schema and API evolution path | Compatibility rules | |
| SDR-A13-03 | Known limits and the next redesign point | Limits table | |
| SDR-A13-04 | Fitness functions or automated checks protect key qualities | Check list | |

See Architecture Fitness Functions Catalogue Template
(`architecture/fitness-functions`).

## 4. Score summary

<!-- Guidance: Weights reflect what matters for this system; agree them before scoring, not after. Adjust the Example weights, keeping the total at 100. -->

The weighted score is

$$
S = \frac{100}{\sum_i w_i} \times \sum_i w_i \times \frac{level_i}{3}
$$

where $w_i$ is the weight of each applicable area and $level_i$ its score
from 0 to 3. With all thirteen areas applicable, $\sum_i w_i = 100$.

| Area | Weight | Score (0 to 3) | Weighted (w x score) | Main finding |
|---|---|---|---|---|
| A1 Requirements and scope | 10 | *Example:* 3 | 30 | |
| A2 Estimation | 6 | *Example:* 2 | 12 | |
| A3 API | 6 | *Example:* 2 | 12 | |
| A4 Data model and access patterns | 10 | *Example:* 3 | 30 | |
| A5 Consistency per write path | 10 | *Example:* 1 | 10 | SDR-F-001 |
| A6 Single points of failure | 8 | *Example:* 2 | 16 | |
| A7 Scalability | 8 | *Example:* 2 | 16 | |
| A8 Failure modes | 10 | *Example:* 2 | 20 | SDR-F-003 |
| A9 Security and privacy | 10 | *Example:* 2 | 20 | SDR-F-002 |
| A10 Operations and SLOs | 8 | *Example:* 1 | 8 | SDR-F-004 |
| A11 Cost | 4 | *Example:* 2 | 8 | |
| A12 Migration and rollout | 6 | *Example:* 2 | 12 | |
| A13 Evolvability | 4 | *Example:* 2 | 8 | |
| **Total** | **100** | | **202** | |

*Example:* $S = 202 / 3 \approx 67$.

Decision bands (*Example*, agree locally; apply the first row that matches, from the top):

| Condition | Outcome |
|---|---|
| Any blocking red flag (section 5) | Changes required, whatever the score |
| Any area weighted 10 scored 0 | Changes required |
| $S \ge 75$ and no area below 2 | Approved |
| $S \ge 60$ and none of the rows above apply | Approved with conditions: each area below 2 gets a finding with a due date |
| $S < 60$ | Changes required |

In the *Example*, the score is 67 and two areas are at level 1, so the
outcome is "approved with conditions".

## 5. Red flags

<!-- Guidance: A red flag is a defect that costs far more to fix after build than before. Blocking flags stop approval; advisory flags become findings. Pitfall: a long list of red flags that reviewers then ignore. Keep it short and specific. -->

| ID | Red flag | Blocking | Why it matters |
|---|---|---|---|
| RF-01 | No numbers anywhere: no load, no data size, no latency target | Yes | Every later decision is unfounded |
| RF-02 | Money, inventory or permissions written without a stated consistency guarantee | Yes | Silent double spend, oversell or exposure |
| RF-03 | Retries on non-idempotent writes | Yes | Duplicates under the most common failure |
| RF-04 | A single component whose loss stops the service with no failover and no accepted risk | Yes | Unplanned full outage |
| RF-05 | Personal or secret data with no classification or owner | Yes | Regulatory and breach exposure |
| RF-06 | No rollback path for a schema or data migration | Yes | Irreversible incident |
| RF-07 | Distributed transactions across services assumed to "just work" | Advisory | Usually a hidden saga with no compensation |
| RF-08 | Cache treated as source of truth without a rebuild path | Advisory | Data loss on eviction or restart |
| RF-09 | Alerts only on CPU and memory, none on user-facing SLIs | Advisory | Outages found by customers |
| RF-10 | Technology chosen before the access patterns were written | Advisory | Store fights the workload |
| [RF-nn] | [Red flag] | [Yes / Advisory] | [Reason] |

## 6. Findings register

<!-- Guidance: One row per finding with an owner and due date. Findings are what the author acts on; scores are only the summary. Write the finding as an observable gap plus the expected evidence, not as a prescribed solution. -->

| ID | Area | Severity | Finding | Expected evidence to close | Owner | Due | Status |
|---|---|---|---|---|---|---|---|
| SDR-F-001 *(Example)* | A5 | High | The refund path writes ledger and order tables in two calls without an outbox; a crash between them leaves them inconsistent | Atomicity strategy for refunds and a failure-injection test | [@author] | YYYY-MM-DD | Open |
| SDR-F-002 *(Example)* | A9 | Medium | Service-to-service calls use a shared static token | Workload identity design or rotation plan | [@author] | YYYY-MM-DD | Open |
| SDR-F-003 *(Example)* | A8 | Medium | No RTO for the reconciliation job | RTO target and restart test | [@author] | YYYY-MM-DD | Open |
| SDR-F-004 *(Example)* | A10 | Medium | SLOs defined, but alerts are on host metrics only | Burn-rate alerts on the two main SLOs | [@sre] | YYYY-MM-DD | Open |
| [SDR-F-nnn] | [Area] | [High / Medium / Low] | [Finding] | [Evidence] | [@owner] | YYYY-MM-DD | [Open / Closed / Accepted] |

Severity guide: **High** blocks launch until closed; **Medium** must close
before general availability; **Low** is tracked in the backlog. An
accepted risk needs an owner who has the authority to accept it and a
review date.

## 7. Review record and decision

<!-- Guidance: The record must stand alone: someone who missed the meeting reads it and knows what was decided, why, and what happens next. -->

### 7.1 Meeting record

| Field | Value |
|---|---|
| Date and duration | YYYY-MM-DD, [60] min |
| Attendees | [@names] |
| Design version reviewed | [Version or commit] |
| Areas discussed | [*Example:* A5, A8, A9, A10] |
| Questions resolved | [*Example:* Q-02 per-region shares accepted] |
| Questions deferred | [*Example:* Q-04 build or adopt, to the architecture board] |

### 7.2 Decision

| Field | Value |
|---|---|
| Outcome | [Approved / Approved with conditions / Changes required] |
| Weighted score | [*Example:* 67] |
| Blocking red flags | [*Example:* None] |
| Conditions | [*Example:* Close SDR-F-001 before implementation of refunds; SDR-F-004 before GA] |
| Re-review needed | [*Example:* No; lead reviewer verifies closure] |
| Decision recorded in | [ADR or board minutes link] |

### 7.3 Re-review triggers

Re-open this review when any of the following happens:

- Load or data size estimates change by more than [2x].
- A write path changes its consistency mechanism.
- A new trust boundary or new category of personal data is introduced.
- The store, queue or other core technology is replaced.
- A High finding is accepted as a risk instead of fixed.

## 8. Interview mode: 45-minute rubric

<!-- Guidance: In an interview you score the candidate's reasoning, not the final diagram. Use the same evidence idea: what did the candidate say or draw that shows the skill? Pitfall: rewarding memorised architectures that ignore the stated requirements. -->

### 8.1 Time plan

| Minutes | Phase | What a strong candidate does |
|---|---|---|
| 0 to 5 | Requirements | Asks about users, scale, core features; states below-the-line items |
| 5 to 10 | Estimation | Computes two or three numbers and says what each changes |
| 10 to 15 | API and data model | Defines the main calls and the access patterns that drive keys |
| 15 to 25 | High-level design | Draws the request path end to end and names where state lives |
| 25 to 38 | Deep dive | Picks the hardest problem, gives options, chooses with a reason |
| 38 to 45 | Wrap-up | Names failure modes, bottlenecks at 10x, and what they would do next |

### 8.2 Dimensions and levels

Score each dimension 1 to 4 on what the candidate showed.

| Dimension | 1: Insufficient | 2: Developing | 3: Solid | 4: Strong |
|---|---|---|---|---|
| Problem navigation | Starts drawing without clarifying | Clarifies when prompted | Drives scope, states assumptions | Prioritises scope by impact and revisits it as constraints appear |
| Estimation and requirements | No numbers | Numbers without consequences | Numbers that shape the design | Spots which estimate the design is most sensitive to |
| High-level design | Missing components on the main path | Complete but generic | Complete and fitted to the requirements | Simple first, adds parts only when a requirement demands them |
| Deep dive | Stays at box level | Goes deep only when led | Options, choice and reason for one hard problem | Two hard problems, including consistency or failure, with trade-offs quantified |
| Trade-offs and communication | Defends one option | Lists alternatives without weighing them | Weighs alternatives against stated requirements | Changes the design when the interviewer changes a constraint, explaining why |
| Operations and failure | Not mentioned | Mentions monitoring generically | Names failure modes and detection | Blast radius, fail-open or closed, rollout and recovery |

### 8.3 Signal by level (*Example* calibration)

| Target level | Expected profile |
|---|---|
| [Mid-level engineer] | Mostly 3 on navigation, high-level design and communication; 2 acceptable on deep dive |
| [Senior engineer] | 3 or above on all dimensions; at least one 4 |
| [Staff engineer] | 4 on deep dive and trade-offs; 3 or above elsewhere; raises organisational and migration concerns unprompted |

### 8.4 Interview record

| Dimension | Score (1 to 4) | Evidence (what the candidate said or drew) |
|---|---|---|
| Problem navigation | [n] | [*Example:* Asked about read/write ratio and global users before drawing] |
| Estimation and requirements | [n] | [Evidence] |
| High-level design | [n] | [Evidence] |
| Deep dive | [n] | [Evidence] |
| Trade-offs and communication | [n] | [Evidence] |
| Operations and failure | [n] | [Evidence] |
| **Overall recommendation** | [Strong no / No / Yes / Strong yes] | [One paragraph, written before discussing with other interviewers] |

Write evidence during or right after the interview. Do not compare notes
with other interviewers before submitting your own score.

## 9. Glossary and references

<!-- Guidance: Define terms reviewers use in findings so authors read them the same way. -->

### 9.1 Glossary

| Term | Meaning |
|---|---|
| Access pattern | A query the system must serve, with its key, frequency and latency need |
| Below the line | Requirements explicitly excluded from this design |
| Blast radius | The users, data or services affected by one failure |
| RTO / RPO | Recovery time objective / recovery point objective |
| SLI / SLO | Service level indicator / objective |
| Red flag | A design defect that blocks or must be tracked before approval |
| Sensitivity point | A design parameter that strongly affects a quality attribute (ATAM term) |

### 9.2 References

| Reference | Use |
|---|---|
| Kazman, Klein and Clements, "ATAM: Method for Architecture Evaluation", CMU/SEI-2000-TR-004, August 2000 | Scenario-based evaluation, risks and sensitivity points |
| AWS Well-Architected Framework, six pillars (operational excellence, security, reliability, performance efficiency, cost optimization, sustainability) | Cross-check of A6 to A11 |
| Beyer et al. (eds.), "Site Reliability Engineering", O'Reilly 2016, chapters on service level objectives and production readiness | A10 inspiration |
| Kleppmann, "Designing Data-Intensive Applications", O'Reilly | A4 and A5 inspiration only |
| Xu, "System Design Interview", volumes 1 and 2 | Section 8 inspiration only |
| System Design Document Template (`system-design/system-design-document`) | The document under review |
| Architecture Review Board Request Template (`architecture/architecture-review-request`) | Board submission |
| Architecture Evaluation Report Template (ATAM) (`architecture/atam-evaluation`) | Deeper quality-attribute evaluation |
| Threat Model Template (`security/threat-model`) | A9 evidence |
| Zero Trust Architecture Plan Template (`security/zero-trust-architecture`) | A9 for trust boundaries |

## Standard and licence note

Based on common industry practice for design reviews and system design
interviews, informed by the public SEI ATAM report and the AWS
Well-Architected Framework cited in 9.2. Books listed in 9.2 are
inspiration only; no text, diagrams or figures are copied from them. The
weights, levels and decision bands are illustrative and should be
calibrated by each organisation. This is original text; check the current
versions of the cited frameworks. Template licence: MIT.