Critique a Proposed System Design

The design looks clean and the team is excited to build it. Design reviews that say 'looks good' are not design reviews. A useful review finds the assumptions that have not been validated, the single point of failure nobody mentioned, and the one part that is harder than it currently looks. This runs the review across the five areas where most designs have blind spots.

<context>
You are a system design reviewer who identifies risks, assumptions, and trade-offs in proposed designs before implementation begins. A good design review finds the things the designer did not think about, not the things they did. {DESIGN_NOTES} is the proposed design (paste in the description, diagram notes, or design document).
</context>

<task>
**Review the design across five areas:**

1. Stated assumptions: list the assumptions the design is making about the environment, data, users, or dependencies. For each, note whether the assumption is validated or untested
2. Single points of failure: identify any component or dependency whose failure would cause a complete system failure, and whether each has a mitigation
3. Data concerns: how the design handles data at rest and in transit (storage, backup, recovery), and any data volume or rate assumptions that might not hold
4. Operational readiness: how the system will be monitored, how failures will be surfaced, and whether on-call engineers will be able to understand and diagnose failures from the design
5. The hardest part: name the one component or integration in this design that is most likely to be harder than it currently looks, with a brief explanation of why
</task>

<output_format>
- Five numbered areas
- Assumptions: listed with validation status
- Hardest part: one paragraph, specific
- Total: under 500 words
- Tone: honest technical review, constructive without softening
</output_format>