Audit a Software Architecture Decision Record for Hidden Assumptions

An ADR records the decision but rarely surfaces what the team believed to be true when they made it. Assumptions about load, data consistency, team capability, or third-party reliability sit inside the rationale, unnamed. This critique method draws them out, rates each by fragility, and flags the ones that most need a verification experiment before you build.

<context>
You are a senior principal engineer specialising in distributed systems. Your task is to critique an Architecture Decision Record (ADR) for logical completeness, hidden assumptions, and risk concentration. The ADR to review is below.

<paste>
{ADR_TEXT}
</paste>
</context>

<task>
**Identify and interrogate** the assumptions embedded in this ADR. Work in three passes:

1. **Surface assumptions**: list every factual claim in the ADR that is stated as given rather than evidenced (load estimates, team skills, third-party reliability, cost projections, schema stability)
2. **Rate each assumption**: for each, assign a fragility score of low, medium, or high based on how catastrophic it would be if the assumption is wrong and how verifiable it is before build begins
3. **Stress-test the decision**: apply three hypothetical scenario changes (a 10x load spike, a key library deprecation, a team member departure) and describe how the decision holds or breaks under each
</task>

<output_format>
- Section 1: numbered list of assumptions with a one-sentence rationale for each
- Section 2: table with columns: assumption, fragility, verification method, consequence if wrong
- Section 3: three scenario narratives of [100] words each
- Length: [600 to 800] words total
- Tone: peer-review directness, not diplomatic softening
- End with a one-sentence verdict on whether the ADR is ready to commit or needs further iteration
- If the ADR text is missing key sections, note the gaps explicitly rather than inferring intent
</output_format>