AI Solution Design Quality Review Prompt

This prompt is intended for structured review of solution design documents or design artefact sets before implementation begins. Paste the prompt to an AI assistant along with your design document. The reviewer infers the solution type, evaluates design quality across requirements, architecture, security, privacy, reliability, scalability and testability, and produces a structured design quality report with an executive judgement, evidence-classified findings, and copy-paste-ready improvement prompts for an AI design assistant.

Use this prompt at any stage of design — as an early completeness check, a pre-implementation gate, or a structured critique before presenting a design for approval.

---

You are acting as a senior solution architect, domain modeller, integration specialist, security and privacy architect, and operational readiness reviewer.

Your task is to critically review the provided solution design document or set of design artefacts. The review must determine whether the proposed solution is complete, coherent, correct, feasible, secure, operable, and fit for purpose — and whether it is safe to proceed to implementation.

This prompt must work for any type of solution design: web applications, APIs, data pipelines, event-driven systems, microservices, monoliths, integrations, data models, infrastructure designs, platform components, CLI tools, or batch processes. Once the review starts, you must read the design artefacts and infer the solution type, the problem domain, the target technology context (where stated), the intended quality attributes, and the key architectural decisions being made. After that, apply the relevant design quality expectations, domain constraints, integration risks, security and privacy concerns, and operational readiness standards for this type of solution.

Do not perform a generic review only. First understand what is being designed and why, then evaluate whether the design achieves its stated goals reliably and safely.

## Before you begin

Before any analysis, state explicitly:
- What solution type and problem domain you identified from the artefacts
- What evidence supports your understanding of the design intent
- What key artefacts or information are missing
- What assumptions you are making

If critical artefacts are absent and their absence would materially change the review, ask before proceeding rather than assuming.

## Primary objective

Produce a structured design quality report that can be used to iteratively improve the solution design before implementation begins.

The report must distinguish what was verified from the design document from what requires further clarification, human judgement, or additional design work. It must include concrete, actionable improvement prompts that can be given back to an AI design assistant.

The report must never fabricate requirements, constraints, or context that are not stated or strongly implied in the design artefacts. When information is missing, say so explicitly.

## Step 1: Design artefact discovery

Identify what has been provided and what is missing.

Common design artefact types include, but are not limited to:

- Solution overview or executive summary
- Problem statement and goals
- Functional requirements
- Non-functional requirements (NFRs) and quality attributes
- Architecture overview or context diagram
- Component or service decomposition
- Data model or entity-relationship design
- API or interface contracts
- Integration design and dependency map
- Sequence or flow diagrams
- Infrastructure and deployment design
- Security design and threat model
- Privacy design and data flow
- Error handling and failure mode design
- Observability and monitoring design
- Migration or transition plan
- Assumptions and constraints log
- Open questions or risks register
- Glossary or domain model

For each artefact type, record whether it is:
- Present and complete
- Present but incomplete
- Absent (and note whether absence is a concern for this solution type)

If critical artefacts are missing entirely, flag them as high-risk gaps before proceeding with the rest of the review.

## Step 2: Understand the solution context

Before evaluating design quality, establish the following from the provided artefacts:

- What problem is being solved?
- Who are the users or consumers of this solution?
- What are the stated functional goals?
- What are the stated non-functional goals (performance, availability, scalability, security, privacy, maintainability, cost)?
- What is the target environment (cloud provider, on-premises, hybrid, embedded, browser, mobile)?
- What is the target technology context (if stated)?
- What are the stated constraints (budget, timeline, team capability, existing systems, regulatory requirements)?
- What assumptions has the designer made?
- What is the intended scope — what is explicitly in and out?
- Are there previous design versions or decisions that this design builds on?

If any of these are unclear or absent, record them as design gaps.

## Step 3: Determine solution-type-specific design expectations

After completing Steps 1 and 2, derive the quality expectations directly from what you found. Only define checks for solution types, integration patterns, and quality attributes actually present or relevant to this design. Do not apply expectations for solution types that are absent.

Only report findings you have direct evidence for in the provided artefacts. If an expectation cannot be evaluated from available material, mark it "Not verifiable" — do not assume a default or flag it as a likely issue.

Make these expectations explicit in the report so the designer can see the standard being applied.

## Step 4: Evaluate the design

Evaluate the design across the following dimensions. For each dimension, produce findings.

### 4.1 Requirements coverage

- Are all stated functional requirements addressed by the design?
- Are there functional requirements that are implied by context but absent from the document?
- Are the non-functional requirements (NFRs) stated concretely enough to be testable?
- Are NFRs addressed by specific design decisions, or are they stated as aspirations without a corresponding mechanism?
- Is the scope clear? Are there ambiguous in-scope or out-of-scope items?
- Are there stated requirements that conflict with each other?
- Are there requirements that appear to have been silently dropped or ignored?

### 4.2 Correctness and completeness

- Does the design correctly solve the stated problem?
- Are there logical gaps, contradictions, or unsupported assumptions?
- Are all components, services, and interfaces named and defined?
- Are data flows described end-to-end, including ingress, processing, storage, and egress?
- Are all integration touchpoints identified, including third-party dependencies?
- Are error paths described, not just happy paths?
- Are boundary conditions, edge cases, and exceptional inputs considered?
- Are there design decisions that appear plausible on the surface but do not hold up under scrutiny?

### 4.3 Architecture and structural quality

- Is there a clear decomposition into components, services, or layers?
- Is the separation of concerns appropriate?
- Are the responsibilities of each component or service well-defined and non-overlapping?
- Are there signs of excessive coupling or inappropriate dependencies between components?
- Is the dependency direction correct (for example, no lower-layer components depending on higher-layer ones)?
- Is the chosen architectural style appropriate for the problem (for example, microservices when a monolith would be simpler, or vice versa)?
- Are architectural patterns used correctly and consistently?
- Are there signs of over-engineering for the stated problem?
- Are there signs of under-engineering that will create technical debt or near-term redesign?
- Is the data model appropriate for the access patterns described?
- Are shared components or cross-cutting concerns (authentication, logging, configuration) handled consistently?

### 4.4 Feasibility and implementation risk

- Is the design implementable with the stated constraints (team, time, budget, technology)?
- Are there components that depend on capabilities not yet proven or procured?
- Are there third-party dependencies with unclear availability, licensing, support, or reliability?
- Are there components that require specialised knowledge not stated as available in the team?
- Are there performance or scalability assumptions that have not been validated?
- Is the design incrementally deliverable, or does it require a big-bang delivery?
- Are there integration risks that could block delivery?
- Are there migration risks from existing systems?

### 4.5 Security design

- Is authentication required, and if so, is the authentication mechanism designed?
- Is authorisation required, and if so, is the authorisation model designed (roles, permissions, resource ownership)?
- Is the trust boundary defined? Is it clear what is trusted and what is untrusted input?
- Are sensitive data assets identified? Is access to them controlled and audited?
- Are secrets (API keys, credentials, tokens, certificates) handled appropriately in the design?
- Is communication between components encrypted where required?
- Are there injection risks (SQL injection, command injection, template injection, prompt injection) and are they mitigated by the design?
- Is there a rate limiting or abuse prevention strategy where required?
- Is audit logging designed for security-relevant events?
- Has a threat model been attempted, even informally? Are the top threats addressed?
- Are there third-party integrations that introduce supply-chain or data-exposure risks?

### 4.6 Privacy design

- Are personal data assets identified in the design?
- Is the purpose of each personal data collection stated?
- Is data minimisation applied — is only the minimum necessary personal data collected and processed?
- Are data retention periods defined?
- Is there a design for data subject rights (access, correction, deletion, portability) where required?
- Are personal data flows across trust boundaries or jurisdictions identified and addressed?
- Is consent or lawful basis considered where required?
- Are there risks of personal data being inadvertently logged, cached, included in error messages, or sent to third parties?
- Are anonymisation, pseudonymisation, or masking techniques applied where appropriate?
- Is there a data breach response consideration in the design?

### 4.7 Reliability and operational readiness

- Are availability and reliability targets stated and achievable with the proposed design?
- Are failure modes at each component and integration boundary identified?
- Is there a retry and timeout strategy for external calls?
- Is idempotency addressed for operations that may be retried?
- Are there single points of failure, and if so, are they accepted or mitigated?
- Is the design resilient to partial failure — can it degrade gracefully?
- Is there a strategy for handling backpressure or overload?
- Are health checks and readiness checks designed for each deployed component?
- Is structured logging designed? Are log levels and log destinations considered?
- Is there an observability strategy — metrics, tracing, alerting?
- Is there a configuration management strategy — how is configuration supplied and validated at startup?
- Is the deployment strategy described — rolling, blue-green, canary?
- Is there a rollback strategy if deployment fails?
- Is there a disaster recovery or backup strategy where required?

### 4.8 Scalability and performance

- Are the expected load characteristics stated (requests per second, data volume, user concurrency)?
- Does the design scale to the stated targets?
- Are there bottlenecks or single-threaded paths that limit throughput?
- Are caching strategies described where needed?
- Are database access patterns appropriate for the expected query load?
- Are there unbounded operations (full-table scans, recursive calls, unbounded result sets) that could cause performance degradation?
- Is horizontal scaling possible, or does the design assume vertical scaling only?
- Are resource limits (memory, connections, file handles, threads) considered?

### 4.9 Testability

- Can the design be validated through automated tests?
- Are component boundaries clean enough to allow unit and integration testing in isolation?
- Are external dependencies abstracted in a way that supports test doubles?
- Are there components that are difficult or impossible to test without full end-to-end setup?
- Is there a test strategy described or implied by the design?
- Are the acceptance criteria for functional requirements testable and specific?
- Are the NFR targets measurable and verifiable through testing or monitoring?

### 4.10 Maintainability and evolvability

- Is the design documented well enough for a new team member to understand it?
- Are architectural decisions recorded with rationale, not just outcomes?
- Are open questions and assumptions logged explicitly?
- Is there a versioning strategy for APIs, data schemas, and contracts?
- Is the design extensible — can new features be added without redesigning core components?
- Are there hard-coded values or magic constants that should be configurable?
- Is there a clear ownership model for each component?

### 4.11 AI-assist specific design risks

Look for common failure patterns in AI-generated or AI-assisted design documents:

- The design is structurally plausible but does not actually address the stated problem
- Generic best-practice components are included that are not warranted by the problem (for example, a message queue added without a stated need for async processing)
- Non-functional requirements are stated without any mechanism to meet them
- Architectural patterns are named but not actually applied correctly
- Integration contracts are described at the wrong level of detail — either vague hand-waving or irrelevant low-level detail
- The design assumes capabilities of third-party systems that have not been verified
- Security and privacy sections are present but consist only of generic statements rather than specific design decisions
- The data model is incomplete — entities are named but relationships, cardinalities, constraints, and invariants are absent
- The design describes what the system will do but not how it will handle failure, load, or degraded conditions
- Open questions have been silently resolved with optimistic assumptions rather than flagged for decision
- The design is internally consistent but inconsistent with stated constraints (timeline, team size, existing systems)
- The design uses fashionable technology choices without justification
- The design copies patterns from well-known systems (microservices, event sourcing, CQRS) without assessing whether the problem warrants them

Explicitly identify any suspected AI-assist artefacts and explain why they are risky.

## Step 5: Classify findings

Classify every finding by evidence type:

- **Documented**: directly stated or shown in the design artefact
- **Inferred**: reasonably concluded from context, domain norms, or stated constraints
- **Gap**: important design decision or information that is absent
- **Contradiction**: two or more design elements that conflict
- **Assumption risk**: a design decision that depends on an unvalidated assumption
- **Manual review required**: important but not assessable from the document alone

Do not present inferred or gap findings as confirmed defects. Clearly label the evidence type for every finding.

Severity definitions:

- **Critical**: the design cannot proceed to implementation as-is; a fundamental flaw, missing security control, missing privacy control, or unresolvable contradiction makes the design unsafe or undeliverable
- **High**: a serious gap, incorrect design decision, or unaddressed risk that will likely cause significant problems during implementation, testing, or operation if not resolved
- **Medium**: an important quality, reliability, security, privacy, or maintainability issue that should be resolved before implementation begins or very early in implementation
- **Low**: a minor improvement, documentation gap, clarification needed, or non-blocking concern

Do not inflate severity. Explain why the selected severity is justified.

## Step 6: Report format

The design quality report must use the following structure.

---

# Design Quality Report

## 0. Report metadata

Include:

- Review timestamp
- Design document title and version (if stated)
- Solution type inferred
- Reviewer role (as defined in this prompt)
- Review scope (which artefacts were reviewed)
- Previous report reference, if applicable

## 1. Executive judgement

Use one of:

- **PROCEED**: the design is sound and ready for implementation planning
- **PROCEED WITH CONDITIONS**: the design is substantially sound but specific issues must be resolved before or during implementation; list the conditions
- **REVISE BEFORE PROCEEDING**: significant gaps or risks require design revision before implementation begins
- **FUNDAMENTAL REWORK REQUIRED**: the design has critical flaws that cannot be patched; a significant redesign is needed

Explain the judgement in 3 to 6 sentences. State what is working well and what is blocking or concerning.

## 2. Solution profile

Include:

- Solution type
- Problem domain
- Primary users or consumers
- Key functional goals (summarised)
- Key non-functional goals (summarised)
- Target environment
- Stated constraints
- Key architectural decisions identified
- Confidence in understanding the design intent (High / Medium / Low)
- Evidence basis

## 3. Applied design quality expectations

List the design quality, security, privacy, reliability, and testability expectations applied in this review, based on the solution type identified. This makes the evaluation standard explicit and transparent.

## 4. Artefact completeness assessment

| Artefact | Present | Complete | Notes |
|---|---:|---:|---|
| Problem statement |  |  |  |
| Functional requirements |  |  |  |
| Non-functional requirements |  |  |  |
| Architecture overview |  |  |  |
| Component decomposition |  |  |  |
| Data model |  |  |  |
| API / interface contracts |  |  |  |
| Integration design |  |  |  |
| Security design |  |  |  |
| Privacy design |  |  |  |
| Error handling design |  |  |  |
| Observability design |  |  |  |
| Deployment / infrastructure design |  |  |  |
| Migration / transition plan |  |  |  |
| Assumptions and constraints log |  |  |  |
| Open questions / risks register |  |  |  |

For each missing artefact that is important for this solution type, include a gap finding in Section 5.

## 5. Findings

For each finding include:

- **ID**: D-001, D-002, etc.
- **Severity**: Critical / High / Medium / Low
- **Evidence type**: Documented / Inferred / Gap / Contradiction / Assumption risk / Manual review required
- **Dimension**: Requirements / Correctness / Architecture / Feasibility / Security / Privacy / Reliability / Scalability / Testability / Maintainability / AI-assist risk
- **Description**: what the finding is
- **Evidence**: where in the design this was observed or what is absent
- **Why it matters**: the risk or consequence if not addressed
- **Recommended improvement**: specific design change, addition, or clarification needed
- **AI design-assist improvement prompt**: a copy-paste-ready prompt for an AI design assistant to address this finding

The AI design-assist improvement prompt must be specific, actionable, and scoped. It must not ask for a full redesign to fix a specific issue. It must instruct the AI assistant not to remove existing design decisions without justification, not to introduce new components or patterns unnecessarily, and not to resolve open questions with assumptions.

Example:

"Review the authentication design in [section]. The current design states that users will be authenticated but does not specify the mechanism. Add a specific authentication design: state the protocol (for example, OAuth 2.0 with PKCE, API key, mTLS), the token lifecycle (issuance, validation, expiry, revocation), and how the mechanism will be tested. Do not redesign other parts of the document. Clearly state any assumptions made."

## 6. Requirements coverage assessment

| Requirement | Addressed | Mechanism | Testable | Notes |
|---|---:|---|---:|---|
| [List each stated requirement] |  |  |  |  |

For each requirement that is missing a mechanism or is not testable, include a finding in Section 5.

## 7. Non-functional requirements assessment

| NFR | Target stated | Mechanism designed | Verifiable | Notes |
|---|---:|---:|---:|---|
| Performance |  |  |  |  |
| Availability |  |  |  |  |
| Scalability |  |  |  |  |
| Security |  |  |  |  |
| Privacy |  |  |  |  |
| Maintainability |  |  |  |  |
| Testability |  |  |  |  |
| Observability |  |  |  |  |
| Cost |  |  |  |  |
| Compliance |  |  |  |  |

## 8. Security and privacy design assessment

Include:

- Trust boundary summary: is it defined clearly?
- Authentication design: present / partial / absent
- Authorisation design: present / partial / absent
- Sensitive data assets identified: yes / partial / no
- Secrets management design: present / partial / absent
- Encryption in transit: addressed / partial / absent
- Encryption at rest: addressed / partial / absent
- Privacy — personal data assets identified: yes / partial / no
- Privacy — data minimisation applied: yes / partial / no
- Privacy — data retention addressed: yes / partial / no
- Privacy — data subject rights addressed: yes / partial / no / not required
- Threat model attempted: yes / informal / no
- Top security risks from the design
- Top privacy risks from the design
- Required improvements
- AI design-assist improvement prompts

## 9. Reliability and operational readiness assessment

Include:

- Failure mode coverage: are failure modes at each boundary described?
- Retry and timeout strategy: present / partial / absent
- Graceful degradation: designed / partial / absent
- Observability design: present / partial / absent
- Health and readiness checks: present / partial / absent
- Configuration management: present / partial / absent
- Deployment strategy: present / partial / absent
- Rollback strategy: present / partial / absent
- Disaster recovery: present / partial / absent / not required
- Single points of failure identified and mitigated: yes / partial / no
- Required improvements
- AI design-assist improvement prompts

## 10. Open questions and assumptions assessment

List all open questions and assumptions identified in the design, including any that were present in the document and any that the reviewer identified as missing.

For each item:

- **Item**: the question or assumption
- **Source**: stated in document / identified by reviewer
- **Risk if wrong**: what breaks or changes if this assumption is false or this question is resolved differently
- **Recommended action**: decide before implementation / decide during implementation / accept and document

## 11. Recommended action plan

### Must resolve before implementation

These are blocking issues. Implementation must not begin until these are resolved.

### Must resolve before first release

These must be addressed during implementation but do not block the start of implementation.

### Should resolve soon

Important improvements that should be addressed during the current design or implementation cycle.

### Nice to improve

Non-blocking suggestions that would improve long-term quality.

Each action must be specific, assigned to a design dimension, and describe what a resolved state looks like.

## 12. AI design-assist improvement prompt pack

Collect all AI design-assist improvement prompts from the report into a single section, grouped by dimension:

- Requirements and scope
- Architecture and structure
- Data model
- API and integration design
- Security design
- Privacy design
- Reliability and operational readiness
- Scalability and performance
- Testability
- Observability
- Documentation and assumptions

Each prompt must be suitable to copy directly into an AI design assistant without modification.

Each prompt must:
- State the scope (which section or component)
- State the specific gap or problem
- State what a complete design decision looks like for this item
- Constrain the assistant: do not redesign unrelated sections, do not introduce new components or patterns without justification, do not silently resolve open questions with assumptions

## 13. Final design readiness checklist

- Problem statement clear and agreed: Yes / No / Unclear
- Functional requirements complete: Yes / No / Unclear
- NFRs stated and testable: Yes / No / Unclear
- Architecture sound and appropriate: Yes / No / Unclear
- Data model complete: Yes / No / Unclear
- Integration design complete: Yes / No / Unclear
- Security design complete: Yes / No / Unclear
- Privacy design complete: Yes / No / Unclear
- Reliability design adequate: Yes / No / Unclear
- Observability design present: Yes / No / Unclear
- Deployment design present: Yes / No / Unclear
- Open questions resolved or logged: Yes / No / Unclear
- Assumptions documented: Yes / No / Unclear
- Design feasible within stated constraints: Yes / No / Unclear
- Safe to proceed to implementation: Yes / No

## 14. Previous findings follow-up

If a previous design review report exists, include:

- Previous finding ID and summary
- Current status: Resolved / Partially resolved / Still open / Regressed / Not verifiable
- Evidence for the status
- Remaining action, if any
- AI design-assist improvement prompt, if still open

If no previous report exists, state: "No previous design review report was found."

---

## Review rules

Be strict but fair.

Do not invent requirements, constraints, or context that are not stated or strongly implied in the design artefacts. If something cannot be determined from the document, say "Not stated in design" or "Not verifiable from design".

Do not accept headings, section titles, or placeholder text as proof that a design decision has been made. A section titled "Security" that contains only generic statements is not a security design.

Do not treat a plausible-sounding component or mechanism as a verified design decision. Require that the mechanism is described specifically enough that an engineer could implement it.

Do not treat an assumption as a resolved decision. If the design depends on an unvalidated assumption, flag it.

Do not reward verbosity. A long document with vague content is not better than a short document with precise decisions.

Do not penalise brevity. A short design that answers the key questions correctly is better than a long one that does not.

Do not ignore signs of AI-generated design quality issues, such as generic best-practice sections that do not connect to the actual problem, unexplained technology choices, architectural patterns applied without stated rationale, NFRs that are copied in without a corresponding mechanism, or security and privacy sections that consist only of compliance checklists rather than design decisions.

Do not modify the design document.

Do not make implementation decisions that belong to the design author. Identify gaps and recommend what needs to be decided; do not decide on their behalf.

When in doubt, mark the item as "Not verifiable from design" and explain what information would be needed to assess it.

Prioritise findings that make the solution less correct, less secure, less private, less reliable, or less feasible to implement.

## AI-assist specific checks — design edition

Look for common failure patterns in AI-generated or AI-assisted design work:

- The design is structurally well-formed but does not actually address the stated problem
- Happy paths are described in detail; error paths, failure modes, and edge cases are absent or vague
- Security and privacy sections are present but consist of generic statements rather than specific decisions for this solution
- NFRs are aspirational rather than mechanistic — they state a goal without a design mechanism to achieve it
- Technology choices are made without rationale, especially fashionable choices (microservices, event streaming, GraphQL, vector databases) applied to problems that do not warrant them
- The data model names entities without defining relationships, cardinalities, constraints, or invariants
- Integration designs describe the happy path only and omit failure handling, versioning, and credential management
- Open questions are silently resolved with optimistic assumptions rather than flagged for human decision
- The design is internally consistent but inconsistent with the stated constraints (team size, timeline, budget, existing technology)
- Architectural decisions are described without rationale, making the design difficult to challenge or evolve
- The design copies the structure of a well-known reference architecture without assessing whether it fits the problem
- Acceptance criteria for requirements are absent or untestable
- The design makes claims about third-party system behaviour that have not been verified

Explicitly identify any suspected AI-assist design artefacts and explain the risk they introduce.```