AI-008·AI Track·Advanced·3–12 hrs saved

Catch the Design Flaws Before They Become Production Incidents — A Structured Technical Design Review

An AI-assisted workflow that reviews a proposed technical design against requirements, failure modes, security, and operability — grounded in evidence, not architectural preference.

3Phases

19Prompts

3–12Hours saved

12Deliverables

Executive Brief

Your Challenge

A technical design is the last cheap place to be wrong. Once code is written, data is migrated, interfaces are published, and other teams build dependencies, every design flaw costs an order of magnitude more to correct. But design reviews are wildly inconsistent — one review fixates on framework choice and diagram style while missing data ownership, authorization, failure recovery, and rollback entirely. The result is security findings discovered late, migrations that can't be reversed, and services no team agreed to operate.

Common Obstacles

AI can make reviews consistent by applying a repeatable framework — but only if it stays grounded. Left unconstrained, it favors familiar patterns, invents requirements that were never stated, overstates speculative scale risks, and recommends microservices or cloud-native complexity for workloads that don't need them. It will happily judge a design 'good' because it uses a popular stack, or block one because it uses older technology. Preference dressed as a finding is worse than no finding at all.

The ABME Approach

This workflow forces the right order: establish the business problem and confirmed requirements first, separate what's confirmed from what's assumed, then review the design across every dimension that matters — architecture, data, security, reliability, scale, operations, testing, deployment, migration, cost. Every finding carries a severity, a confidence level reported separately, evidence, and a blocking/non-blocking status. The output is a defensible recommendation — approve, approve with conditions, revise, or reject — backed by a risk register and a validation plan, never a rubber stamp.

Insight Summary

A technical design review should improve decisions, not create architecture by committee. Findings reference requirements, risks, standards, or evidence — never preference.

phase-1

Missing requirements cannot be solved reliably through architecture assumptions. Separate the requirement gap from the design defect before you review anything else.

phase-2

Authentication does not prove that an authenticated user may access a specific resource. Authorization is a separate concern, and the design has to say so.

phase-2

Many messaging systems may redeliver messages. 'The queue handles it' is not a design — idempotency must be designed explicitly.

phase-3

A deployment plan without rollback is incomplete, and a code rollback does not reverse data changes. Review deployment and rollback together, or you'll discover the gap in production.

tactical

'Designed to scale' and 'uses OAuth' are not measurable design statements. Every performance target needs a validation method and every security claim needs a mechanism.

The Journey

Three phases; each lists the tools you'll use there.

Frame the Design and Its Requirements

Gather the design and its context, then separate confirmed requirements from assumptions and constraints before evaluating anything.

Gather the design document, requirements, and supporting evidence
Summarize the business problem and proposed approach
Separate confirmed, inferred, missing, and conflicting requirements
Inventory assumptions and constraints
Identify what information is missing that materially affects approval

Prerequisites Checklist Requirements Coverage Matrix Assumption Register Constraint Register

Review the Design Across Every Dimension

Use the prompt pack to evaluate architecture, data, security, reliability, scale, and performance — producing severity-and-confidence-rated findings.

Run the primary prompt with the design and its context
Apply focused follow-up prompts per dimension (API, events, data, security, tenancy, reliability, scale, performance)
Rate each finding by severity and confidence separately
Build a failure-mode table with detection, impact, mitigation, and recovery
Generate a prioritized list of design-review questions

Technical Design Review Prompt Pack finding-severity-model confidence-model failure-mode-table review-outcome-model

Decide, Validate, and Record

Turn findings into a recommendation, a validation plan, and decision records — then confirm high-risk claims before implementation proceeds.

Assemble blocking and non-blocking findings into a risk register
Reach an approve / approve-with-conditions / revise / reject recommendation
Map every high-risk design claim to a validation method and owner
Record major decisions as architecture decision records
Run the design review checklist as an acceptance gate

Design Review Checklist Design Validation Matrix Blocking Finding Template Open Question Template

What's Inside the Execution Layer

Numbered deliverables grouped by phase. Membership unlocks every tool.

2. PHASE 2Prompt Packprotected

Technical Design Review Prompt Pack

One primary review prompt and eighteen focused follow-ups that evaluate a design across every dimension while staying grounded in supplied requirements.

Use this to

Run a complete, evidence-based design review
Drill into a specific dimension — API, events, data, security, tenancy, reliability, scale, performance, deployment, migration, cost
Generate review questions and architecture decision records

Included with membership — $20/mo

Primary Prompt

Start here with the design and as much of its context as you have.

You are a senior software architect conducting a formal technical design review.I will provide some or all of the following:• Business objective• Product requirements• Functional requirements• Non-functional requirements• Technical design• Architecture diagrams• Data-flow diagrams• Sequence diagrams• API specifications• Event schemas• Data models• Security requirements• Privacy requirements• Compliance requirements• Performance expectations• Capacity estimates• Availability targets• Recovery objectives• Technology constraints• Existing architecture• Migration requirements• Deployment model• Test strategy• Cost estimates• Support model• Ownership information• Alternatives consideredYour task is to determine whether the design is complete, justified, implementable, secure, resilient, testable, deployable, and operable.Do not begin by recommending a different architecture.First:1. Summarize the business problem.2. Summarize the proposed technical approach.3. Identify: • Confirmed requirements • Inferred requirements • Missing requirements • Conflicting requirements • In-scope capabilities • Out-of-scope capabilities • Deferred capabilities4. Identify: • Assumptions • Constraints • Dependencies • External systems • Ownership boundaries • Trust boundaries5. Identify the proposed: • Components • Responsibilities • Interfaces • Data stores • Communication patterns • Deployment model • Operational model6. Identify missing information that materially affects approval.Then review the design across:• Business alignment• Requirements coverage• Scope• Architecture• Component boundaries• Interfaces• Data ownership• Data consistency• Transactions• Security• Privacy• Availability• Reliability• Scalability• Performance• Capacity• Failure handling• Observability• Operations• Testing• Deployment• Migration• Rollback• Compatibility• Cost• Maintainability• Technical debt• Organizational readinessFor each finding, include:• Finding ID• Title• Category• Severity• Confidence• Evidence• Requirement affected• Business impact• Technical impact• Operational impact• Security or compliance impact• Recommended action• Blocking or non-blocking status• Suggested owner• Required resolution date or phase• Validation methodRequirements:• Do not invent requirements.• Do not assume undocumented behavior.• Separate confirmed findings from questions.• Separate mandatory changes from optional improvements.• Avoid preference-based recommendations.• Do not recommend microservices, event-driven design, serverless, containers, or cloud services without justification.• Do not optimize for hypothetical scale without evidence.• Do not approve unresolved critical security, data-loss, or migration risks.• Identify the smallest design change that resolves each concern.• Evaluate alternatives already considered.• Identify tradeoffs.• Identify decisions that should be recorded in architecture decision records.• Identify implementation details that can safely remain unresolved.• State when a proof of concept, benchmark, load test, migration rehearsal, or security review is required.Then produce:1. Executive summary.2. Recommendation: • Approve • Approve with conditions • Revise and resubmit • Reject3. Design strengths.4. Requirements coverage matrix.5. Assumption and constraint register.6. Architecture assessment.7. Data assessment.8. Security and privacy assessment.9. Reliability and scalability assessment.10. Operational readiness assessment.11. Testing assessment.12. Deployment and migration assessment.13. Cost and maintainability assessment.14. Risk register.15. Blocking findings.16. Non-blocking recommendations.17. Open questions.18. Required design changes.19. Suggested validation plan.20. Decision record recommendations.

Review Requirements Coverage

To map the design against supplied requirements systematically.

Compare the technical design against the supplied requirements.Create a matrix with:• Requirement ID• Requirement• Design section addressing it• Coverage status• Evidence• Gap• Risk• Required actionUse these coverage states:• Fully addressed• Partially addressed• Not addressed• Conflicting• Cannot determine

Review Architecture Boundaries

When component and service boundaries need scrutiny.

Review the proposed component and service boundaries.Assess:• Responsibility clarity• Cohesion• Coupling• Dependency direction• Shared state• Ownership• Deployment independence• Data ownership• Cyclic dependencies• Change isolationRecommend boundary changes only when they resolve a specific risk or requirement.

Review API Design

For designs proposing new or changed APIs.

Review the proposed API design.Assess:• Resource model• Operation semantics• Authentication• Authorization• Validation• Idempotency• Pagination• Filtering• Error model• Versioning• Rate limiting• Compatibility• Observability• DocumentationIdentify public-contract decisions that must be finalized before implementation.

Review Event-Driven Design

For event- or message-based designs.

Review the event-driven design.Assess:• Event ownership• Schema• Versioning• Delivery guarantees• Ordering• Duplication• Idempotency• Retry• Dead-letter handling• Poison messages• Replay• Observability• Data consistency• Consumer compatibilityIdentify where eventual consistency affects user or business behavior.

Review Data Design

When persistent data, schema, or storage decisions are involved.

Review the data design.Assess:• Data ownership• Schema• Validation• Constraints• Transactions• Consistency• Concurrency• Indexing• Retention• Classification• Encryption• Migration• Backup• Recovery• Deletion• Analytics and reportingIdentify data decisions that would be expensive to change after implementation.

Review Security Design

For security-sensitive designs, before formal threat modeling.

Review the technical design for security.Assess:• Authentication• Authorization• Identity propagation• Trust boundaries• Least privilege• Secret management• Encryption• Administrative access• Tenant isolation• Input validation• Audit logging• Dependency security• Abuse cases• Security monitoringSeparate design-review findings from issues requiring formal threat modeling.

Review Multi-Tenant Design

For any design serving multiple tenants.

Review the multi-tenant design.Assess:• Tenant identification• Tenant isolation• Authorization• Data partitioning• Shared resources• Encryption• Administrative access• Logging• Backup• Restore• Export• Deletion• Noisy-neighbor risk• Rate limitsIdentify all locations where tenant context could be lost or bypassed.

Review Reliability Design

To evaluate failure handling and recovery.

Review reliability and failure handling.Assess:• Failure modes• Timeouts• Retries• Backoff• Idempotency• Circuit breakers• Partial failure• Resource exhaustion• Dependency failure• Redundancy• Recovery• Disaster recovery• Manual interventionCreate a failure-mode table with detection, impact, mitigation, and recovery.

Review Scalability and Capacity

When scale claims or capacity assumptions need verification.

Review the scalability and capacity assumptions.Identify:• Expected users• Request volume• Data volume• Concurrency• Peak-to-average ratio• Growth rate• External limits• First likely bottleneck• Scaling mechanism• Measurement plan• Capacity thresholds• Cost implicationsDo not accept unsupported scale claims.

Review Performance Design

When latency or throughput targets matter.

Review the proposed performance design.Assess:• Latency targets• Throughput targets• Critical path• Network calls• Database calls• Serialization• Caching• Batch processing• Concurrency• Resource usage• Cold starts• Performance test planIdentify where benchmarks or proofs of concept are required.

Review Observability Design

To confirm operators can detect and diagnose failures.

Review observability and operational visibility.Assess:• Structured logging• Metrics• Distributed tracing• Correlation identifiers• Business events• Health checks• Dashboards• Alerts• Service-level indicators• Retention• Sensitive data handling• Diagnostic workflowsDetermine whether operators can detect, isolate, and diagnose likely failures.

Review Deployment and Rollback

Evaluate deployment and rollback together.

Review the deployment and rollback design.Assess:• CI/CD• Environment promotion• Feature flags• Configuration• Secret deployment• Infrastructure changes• Database changes• Compatibility• Canary or phased release• Health validation• Rollback triggers• Rollback procedure• Data written by the new versionIdentify any change that cannot be safely rolled back.

Review Migration Design

For any migration or cutover plan.

Review the migration plan.Assess:• Existing data• Data transformation• Compatibility window• Dual write• Backfill• Validation• Cutover• Downtime• Rollback• Reconciliation• Legacy retirement• Customer communication• Migration monitoringIdentify irreversible steps and required rehearsal.

Review Testing Strategy

To map tests to design risks.

Review the testing strategy against the design risks.Assess:• Unit tests• Integration tests• Contract tests• End-to-end tests• Security tests• Performance tests• Resilience tests• Migration tests• Recovery tests• Compatibility tests• Acceptance tests• Test data• Environment fidelityIdentify critical design claims that currently lack a validation method.

Review Cost Model

To surface cost drivers and assumptions.

Review the cost assumptions.Assess:• Compute• Storage• Data transfer• Managed services• Licensing• Observability• Backups• Disaster recovery• Development effort• Operational labor• Support• Migration• Exit costIdentify missing cost drivers and assumptions requiring measurement.

Generate Design Review Questions

To produce a prioritized question list for the review meeting.

Generate a prioritized list of design-review questions.Group them into:• Blocking questions• High-value clarifications• Implementation questions• Optional future considerationsEach question should explain why the answer matters.

Create Architecture Decision Records

To capture decisions worth documenting.

Identify decisions in the technical design that should be documented as architecture decision records.For each decision provide:• Decision title• Context• Options considered• Decision• Rationale• Tradeoffs• Consequences• Revisit trigger

3. PHASE 1Matrixprotected

Requirements Coverage Matrix

Track every requirement against the design section that addresses it, its coverage status, and the remaining gap.

Use this to

Prove each requirement is addressed or flag where it is not
Attach evidence to every coverage claim
Drive required actions from coverage gaps

Included with membership — $20/mo

Reference rows from the blueprint — downloads ship as an empty skeleton

Requirement ID	Requirement	Coverage	Design Evidence	Gap
FR-001	User can submit a report	Fully addressed	API and sequence diagram	None
NFR-001	Response within two seconds	Partially addressed	Caching proposed	No performance test
SEC-001	Tenant data isolation	Partially addressed	Tenant ID in schema	Authorization path unclear
DR-001	Recovery within four hours	Not addressed	None	DR plan required

RubricCoverage states: Fully addressed, Partially addressed, Not addressed, Conflicting, Cannot determine.

4. PHASE 1Matrixprotected

Assumption Register

Record each assumption the design depends on, the impact if it proves false, and how it will be validated.

Use this to

Make design assumptions explicit
Rank assumptions by impact if false
Assign a validation method to each high-impact assumption

Included with membership — $20/mo

Reference rows from the blueprint — downloads ship as an empty skeleton

Assumption ID	Assumption	Impact if False	Validation
A-001	Peak load remains below 500 requests/second	Performance degradation	Load test
A-002	Identity provider supports required claims	Authorization redesign	Confirm with IdP team
A-003	Legacy records contain valid tenant IDs	Migration failure	Data profiling
A-004	External API remains backward compatible	Integration failure	Contract review

RubricAssumptions with high impact should be validated before implementation.

5. PHASE 1Matrixprotected

Constraint Register

Capture the constraints that shaped the design, their source, and their impact on design options.

Use this to

Document non-negotiable constraints
Trace each constraint to its source
Understand how constraints limit design choices

Included with membership — $20/mo

Reference rows from the blueprint — downloads ship as an empty skeleton

Constraint	Source	Design Impact
Must deploy in approved cloud region	Compliance	Limits service selection
Existing clients cannot upgrade immediately	Product	Requires backward compatibility
Database downtime limited to ten minutes	Operations	Requires online migration
Team supports Java and Python	Engineering	Reduces technology options

6. PHASE 3Matrixprotected

Design Validation Matrix

Map each high-risk design claim to the validation method, owner, and gate at which it must be proven.

Use this to

Ensure every risky claim has a validation method
Assign an owner to each validation
Set the gate each claim must pass before

Included with membership — $20/mo

Reference rows from the blueprint — downloads ship as an empty skeleton

Design Claim	Validation Method	Owner	Required Before
Supports 2,000 requests/second	Load test	Performance engineer	Production launch
Prevents cross-tenant access	Security and authorization tests	Security engineer	Implementation approval
Migration completes within ten minutes	Migration rehearsal	Database engineer	Cutover approval
Worker safely handles duplicates	Integration test	Service owner	Release
Regional recovery meets RTO	Recovery exercise	SRE	General availability

8. PHASE 3Templateprotected

Blocking Finding Template

A standard structure for documenting each blocking finding with its evidence, required change, owner, and deadline.

Use this to

Record blocking findings consistently
Tie each finding to a requirement and validation method
Assign an accountable owner and resolution date

Included with membership — $20/mo

Finding ID

Assign a stable identifier.

TDR-XXX

Title

Concise description.

[Concise description]

Requirement

The requirement or risk affected.

[The requirement or risk affected]

Evidence

What in the design demonstrates the issue?

[What in the design demonstrates the issue]

Impact

What could happen?

[What could happen]

Required Change

What must be resolved?

[What must be resolved]

Validation

How will resolution be confirmed?

[How resolution will be confirmed]

Owner

Who is responsible?

[Responsible owner]

Deadline

When must it be resolved?

[Resolution date or phase]

9. PHASE 3Templateprotected

Open Question Template

A standard structure for logging each unresolved question with its owner, deadline, and the decisions that depend on it.

Use this to

Record open questions with accountable owners
Explain why each answer matters
Track possible design changes tied to each question

Included with membership — $20/mo

Question ID

Assign a stable identifier.

Q-XXX

Question

What is unresolved?

[What is unresolved]

Why It Matters

Which decision or risk depends on the answer?

[Decision or risk that depends on the answer]

Owner

Who should answer?

[Owner who should answer]

Required By

What phase or date requires resolution?

[Phase or date]

Possible Outcomes

What design changes may result?

[Possible design changes]

🔒 The full execution layer — every checklist, matrix, and the prompt pack — is included with ABME membership.

Unlock Full Blueprint

Full Playbook

Overviewpublic

A technical design translates business and product requirements into an implementable engineering approach.

A strong technical design should explain:

What problem is being solved
What is included
What is excluded
How the proposed system will work
Why specific technical choices were made
What alternatives were considered
How data will move
How failures will be handled
How the system will be secured
How it will be tested
How it will be deployed
How it will be operated
How the design can evolve

Technical design reviews are intended to identify risks, omissions, unclear assumptions, and costly decisions before implementation begins.

This is important because design problems become more expensive to correct after:

Code is written
Data is migrated
Interfaces are published
Infrastructure is deployed
Customers begin using the system
Other teams build dependencies
Security controls are approved
Operational procedures are established

This workflow uses AI to perform a structured review of a proposed technical design. The AI should not merely judge whether the design is "good" or "bad." It should evaluate whether the design:

Satisfies confirmed requirements
Makes its assumptions explicit
Addresses important failure modes
Defines appropriate boundaries
Protects security and data
Supports operations
Can be tested and deployed safely
Avoids unnecessary complexity
Provides a reasonable migration and rollback path

The goal is to answer: "Is this design sufficiently complete, justified, secure, operable, and implementable to proceed?"

Business Problempublic

Technical designs are often reviewed inconsistently.

Some reviews focus heavily on:

Programming language
Framework preference
Diagram style
Naming
Individual technology choices

While overlooking:

Business requirements
Data ownership
Failure recovery
Authorization
Capacity
Migration
Deployment
Observability
Compatibility
Operational ownership
Cost
Rollback

Poor design reviews may result in:

Unclear implementation scope
Repeated redesign
Security findings late in delivery
Incompatible APIs
Data migration failures
Uncontrolled cloud cost
Poor operational support
Scalability bottlenecks
Fragile deployments
Difficult testing
Unowned services
Architectural drift
Missed regulatory requirements
Large technical debt commitments

AI can improve review consistency by applying a repeatable framework, but it must remain grounded in the supplied requirements and organizational constraints.

Typical Use Casespublic

Use this workflow when:

Reviewing a new application design
Reviewing a major feature design
Reviewing a new service
Reviewing an API proposal
Reviewing an event-driven workflow
Reviewing a database design
Reviewing a cloud architecture
Reviewing a third-party integration
Reviewing an authentication or authorization design
Reviewing a migration plan
Reviewing a multi-tenant design
Reviewing a data-processing pipeline
Reviewing a serverless solution
Reviewing a disaster recovery design
Reviewing infrastructure-as-code plans
Preparing for an architecture review board
Preparing for implementation approval
Performing technical due diligence
Reviewing AI-generated system designs

Do NOT Use This Workflow Whenpublic

This workflow is not intended to:

Replace formal security threat modeling
Replace penetration testing
Replace code review
Replace load testing
Replace privacy review
Replace legal or regulatory review
Approve a design with missing requirements
Recommend technology solely because it is popular
Reject a design solely because it uses older technology
Require microservices for every application
Require cloud-native architecture for every workload
Treat every possible future requirement as current scope
Optimize for hypothetical scale without evidence
Introduce unnecessary abstraction
Guarantee implementation success
Make final risk-acceptance decisions without accountable owners

A technical design review should improve decisions, not create architecture by committee.

Expected Outcomepublic

After completing this workflow, you should have:

A concise design summary
Requirements coverage assessment
Assumption inventory
Constraint inventory
Design completeness assessment
Architecture and component review
Interface review
Data design review
Security findings
Reliability findings
Scalability findings
Performance findings
Operational readiness findings
Testing assessment
Deployment assessment
Migration assessment
Cost considerations
Risk register
Open questions
Required design changes
Optional improvements
Recommendation to approve, approve with conditions, revise, or reject

🔒 The complete playbook — reference models, worked examples, and operational guidance — is included with ABME membership.

Unlock Full Blueprint

Technical Design Review Objectivesprotected

A complete review should answer:

What business problem is being solved?
What requirements are confirmed?
What requirements are missing or ambiguous?
What is in scope?
What is out of scope?
What assumptions does the design depend upon?
What constraints influenced the design?
What components are proposed?
Are component responsibilities clear?
Are interfaces explicit?
Who owns each data set?
What are the trust boundaries?
What can fail?
How will failures be detected?
How will failures be recovered?
How will the system scale?
How will capacity be measured?
How will the system be tested?
How will it be deployed?
How will it be rolled back?
How will existing users or data migrate?
How will operators support it?
What are the costs and dependencies?
What decisions remain unresolved?
Is the design ready for implementation?

Design Review Categoriesprotected

Business Alignment

Review whether the design supports:

Business objective
User needs
Product requirements
Expected value
Delivery timeline
Compliance obligations
Service expectations
Strategic direction
Budget
Team capability

Requirements Coverage

Determine whether the design addresses:

Functional requirements
Non-functional requirements
Security requirements
Privacy requirements
Availability requirements
Performance requirements
Scalability requirements
Data-retention requirements
Compatibility requirements
Accessibility requirements
Operational requirements
Reporting requirements

Scope

Review:

In-scope capabilities
Out-of-scope capabilities
Deferred work
Dependencies
Assumed existing capabilities
Ownership boundaries
External responsibilities

Unclear scope is a major source of implementation conflict.

Architecture

Review:

Major components
Responsibilities
Boundaries
Communication patterns
Dependency direction
Coupling
Cohesion
Shared services
External systems
Deployment topology

Interfaces

Review:

APIs
Events
Queues
Files
Database interfaces
SDKs
User interfaces
Administrative interfaces
Internal contracts
External contracts

Data

Review:

Ownership
Schema
Validation
Consistency
Transactions
Retention
Classification
Encryption
Replication
Migration
Backup
Recovery
Archiving
Deletion

Security

Review:

Authentication
Authorization
Identity
Trust boundaries
Least privilege
Secret management
Encryption
Tenant isolation
Administrative access
Audit logging
Input validation
Dependency security
Threat exposure

Reliability

Review:

Failure modes
Timeouts
Retries
Circuit breakers
Idempotency
Redundancy
Recovery
Partial failure
Dependency failure
Resource exhaustion
Disaster recovery

Scalability and Capacity

Review:

Expected load
Growth assumptions
Horizontal scaling
Vertical scaling
Storage growth
Queue depth
Concurrency
Rate limiting
Caching
Partitioning
Database capacity
External limits

Performance

Review:

Latency targets
Throughput targets
Critical paths
Query performance
Serialization
Network calls
Batch behavior
Caching
Cold starts
Resource usage

Operations

Review:

Ownership
Monitoring
Logging
Metrics
Tracing
Alerting
Runbooks
Support model
On-call impact
Service-level indicators
Service-level objectives
Capacity monitoring

Delivery

Review:

Implementation phases
Dependency sequencing
CI/CD
Environments
Feature flags
Release strategy
Rollback
Compatibility
Database changes
Infrastructure provisioning

Testing

Review:

Unit testing
Integration testing
Contract testing
End-to-end testing
Security testing
Performance testing
Resilience testing
Migration testing
Recovery testing
Acceptance testing

Cost

Review:

Infrastructure cost
Licensing
Data transfer
Storage growth
Vendor charges
Operational labor
Support requirements
Engineering effort
Migration cost
Exit cost

Review Outcome Modelprotected

Approve

The design is sufficiently complete and risks are acceptable. Minor implementation details may remain.

Approve with Conditions

The design may proceed after clearly identified conditions are satisfied.

Add authorization detail
Define rollback
Complete capacity testing
Confirm data retention
Resolve interface ownership

Revise and Resubmit

Material design gaps or unresolved risks prevent safe implementation.

Reject

The proposed approach does not satisfy critical requirements, creates unacceptable risk, or lacks a viable implementation path. Rejection should include evidence and alternative directions.

Finding Severity Modelprotected

Critical

A finding could result in the following. Critical findings normally block approval.

Unauthorized access
Cross-tenant exposure
Data loss
Regulatory failure
Irrecoverable migration
Major financial error
System-wide outage
Unsafe operation
No viable rollback for a critical change

High

A finding could result in the following. High findings usually require resolution or explicit risk acceptance.

Significant availability risk
Major scaling failure
Repeated deployment failure
Material customer impact
Incompatible public contract
High operational burden
Serious data inconsistency
Unsupported critical dependency

Medium

A finding may result in:

Maintainability problems
Moderate operational difficulty
Localized performance issues
Incomplete testing
Documentation gaps
Limited observability
Increased future implementation cost

Low

A finding involves:

Minor ambiguity
Small documentation improvement
Local simplification
Non-blocking consistency concern
Optional optimization

Confidence Modelprotected

Confirmed

Directly supported by the design, requirements, code, or evidence.

High Confidence

Strongly supported but requires limited verification.

Medium Confidence

Likely, but important context is missing.

Low Confidence

Possible concern based on incomplete information.

Unknown

The design does not provide enough information to assess. Severity and confidence should be reported separately.

Design Evidence Typesprotected

Review evidence may include

Product requirements
User stories
Acceptance criteria
Architecture diagrams
Sequence diagrams
Data-flow diagrams
Entity models
API specifications
Event schemas
Source code
Proofs of concept
Benchmarks
Load tests
Vendor documentation
Security policies
Incident history
Operational metrics
Cost estimates
Migration rehearsals
Team capability assessments

Technical Design Document Structureprotected

A complete design document may contain

Not every design requires the same level of detail, but omitted sections should be intentional.

Executive summary
Business context
Goals
Non-goals
Requirements
Assumptions
Constraints
Current state
Proposed architecture
Component responsibilities
Data flow
Interfaces
Data model
Security
Privacy
Reliability
Scalability
Performance
Observability
Testing
Deployment
Migration
Rollback
Operations
Cost
Alternatives
Risks
Open questions
Decision records
Implementation plan

Example Design Inputprotected

Requirement

Create a service that accepts customer-generated reports, processes them asynchronously, and makes the final output available for download.

Proposed Design

REST endpoint accepts report requests.
API stores the request in a database.
API publishes a message to a queue.
Worker processes the request.
Output is stored in object storage.
User polls a status endpoint.
Download URL is returned after completion.
Authentication uses the existing identity provider.
The system is expected to process up to 10,000 reports per day.

Example Design Summaryprotected

The proposed system uses an asynchronous processing model.

The API accepts the request, persists job state, and publishes work to a queue.

A worker retrieves the message, generates the report, stores the output, and updates job status.

The client polls for status and retrieves a download link when processing completes.

The high-level pattern is appropriate for work that may exceed normal synchronous request duration.

However, several design details materially affect implementation readiness:

Queue delivery semantics
Duplicate message handling
Job idempotency
Tenant authorization
Download-link expiration
Failure and retry behavior
Output retention
Worker concurrency
Status-state transitions
Reconciliation between database and queue
Operational ownership

Example Findingsprotected

TDR-001 — Duplicate Queue Delivery Is Not Addressed

Category: Reliability
Severity: High
Confidence: High

Evidence: The design relies on queue processing but does not define idempotency or duplicate-message behavior.

Requirement Affected: One report should be produced per accepted job.

Business Impact: Customers may receive duplicate reports or be charged multiple times if billing is added later.

Technical Impact: Duplicate processing may create conflicting status updates and unnecessary compute cost.

Recommended Action: Define an idempotency key based on the job identifier and ensure report generation and final-state updates tolerate repeated delivery.

Blocking: Yes
Suggested Owner: Application architect and worker-service owner
Validation: Integration test delivering the same message multiple times.

TDR-002 — Tenant Authorization for Status and Download Is Unclear

Category: Security
Severity: Critical
Confidence: Medium

Evidence: Authentication is referenced, but the design does not describe how report ownership is verified when status or output is requested.

Business Impact: A user may be able to access another tenant's report.

Security Impact: Potential cross-tenant data exposure.

Recommended Action: Bind every report job to tenant and user context at creation. Enforce ownership or authorized-role checks for status and download access.

Blocking: Yes
Suggested Owner: Security architect and API owner
Validation: Authorization tests using users from separate tenants.

TDR-003 — Output Retention Is Undefined

Category: Data and Operations
Severity: Medium
Confidence: Confirmed

Evidence: The design stores outputs in object storage but provides no retention or deletion policy.

Business Impact: Storage cost and privacy obligations may increase over time.

Recommended Action: Define retention duration, deletion behavior, legal-hold interaction, and customer-visible expiration.

Blocking: Conditional
Validation: Lifecycle-policy test and retention-policy approval.

TDR-004 — Queue and Database Consistency Is Not Addressed

Category: Reliability and Data
Severity: High
Confidence: High

Evidence: The design separately writes job state and publishes a queue message without defining atomicity or reconciliation.

Business Impact: A report request may be stored but never processed, or a message may be processed without valid state.

Recommended Action: Evaluate an outbox pattern, transactional messaging capability, or a reconciliation process.

Blocking: Yes
Validation: Failure tests between database commit and message publication.

Failure-Mode Analysisprotected

A design review should evaluate what happens when:

Input is invalid
Authentication fails
Authorization fails
Database is unavailable
Queue is unavailable
Message delivery is duplicated
Message delivery is delayed
Events arrive out of order
Worker crashes
External service times out
Output storage is unavailable
Data is partially written
Deployment is interrupted
Capacity is exhausted
A region is unavailable
A migration fails
Configuration is incorrect
A secret expires
Monitoring fails

Failure-Mode Tableprotected

Failure	Detection	Impact	Mitigation	Recovery
Queue unavailable	Publish error metric	New jobs not scheduled	Retry with bounded backoff	Reconciliation
Worker crash	Missing heartbeat and job timeout	Delayed report	Message redelivery	Resume idempotently
Duplicate message	Duplicate job execution	Duplicate output	Idempotency check	Retain single final output
Storage failure	Write error and alert	Job cannot complete	Retry and circuit breaker	Reprocess job
Database unavailable	Health check and error rate	Status unavailable	Fail safely	Restore and reconcile

Detailed Review Considerationsprotected

Data Ownership Review

For each data set, identify:

Authoritative owner
Writer
Readers
Schema owner
Retention owner
Classification
Encryption requirements
Backup requirements
Restore owner
Deletion owner
Export requirements

Shared data without explicit ownership often becomes a long-term architecture problem.

Interface Review

For each interface, document:

Producer
Consumer
Protocol
Authentication
Authorization
Schema
Versioning
Timeout
Retry
Rate limit
Error behavior
Compatibility
Ownership
Monitoring

Sequence Review

A sequence diagram should make clear:

Initiating actor
Authentication
Authorization
Validation
Data writes
External calls
Events
Responses
Error paths
Timeouts
Retry boundaries
Transaction boundaries

Success-only sequence diagrams are incomplete for important workflows.

Security Review Considerations

Technical designs should explicitly address:

Identity source
Authentication method
Token validation
Authorization model
Administrative roles
Service identities
Tenant context
Secret storage
Secret rotation
Data encryption
Network boundaries
Input validation
Output encoding
Audit logging
Sensitive logging
Abuse prevention
Rate limiting
Dependency trust

A statement such as "uses OAuth" is not a complete security design.

Privacy Review Considerations

Review:

Personal data collected
Purpose of collection
Data minimization
Retention
Deletion
Export
Consent
Data residency
Third-party sharing
Logging
Analytics
Backup copies
Legal hold

Privacy requirements may require a separate formal review.

Reliability Review Considerations

Review whether the design defines:

Availability target
Recovery-time objective
Recovery-point objective
Redundancy
Dependency behavior
Retry policy
Timeout policy
Idempotency
Failure isolation
Load shedding
Resource limits
Degraded mode
Manual recovery
Disaster recovery

Scalability Review Considerations

The design should define or estimate:

Average request rate
Peak request rate
Concurrent users
Job duration
Message volume
Data volume
Storage growth
Retention
Read/write ratio
Geographic distribution
Growth rate
External quotas
Scaling threshold
Cost at expected scale

"Designed to scale" is not a measurable design statement.

Performance Review Considerations

Review:

User-visible latency
Background completion time
Critical path
Synchronous dependencies
Number of network calls
Query count
Query complexity
Payload size
Serialization
Caching
Batch size
Connection pools
Resource limits

Every performance target should have a validation method.

Observability Review Considerations

A complete design should identify:

Important business events
Application logs
Security logs
Metrics
Traces
Correlation identifiers
Tenant identifiers where permitted
Job identifiers
Health checks
Dependency checks
Alerts
Dashboards
Retention
Ownership

Avoid including secrets or sensitive data in telemetry.

Testing Review Considerations

The test strategy should map to design risk. Examples:

Risk	Test
Duplicate message processing	Idempotency integration test
Cross-tenant access	Authorization test
Database and queue inconsistency	Failure-injection test
Schema incompatibility	Contract test
Capacity limit	Load test
Migration data loss	Migration rehearsal
Regional outage	Recovery test
Secret expiration	Operational simulation

Deployment Review Considerations

Review:

Build process
Artifact ownership
Environment configuration
Infrastructure provisioning
Secret provisioning
Database migration
Feature flags
Deployment order
Health checks
Canary strategy
Monitoring
Rollback trigger
Rollback procedure

Database Change Review

Database changes should address:

Backward compatibility
Forward compatibility
Migration duration
Locking
Data volume
Default values
Nullability
Index creation
Application deployment order
Rollback
Old-version coexistence
Data validation

A code rollback may fail if the database schema is no longer compatible.

Migration Review

A migration plan should define:

Source system
Target system
Data mapping
Data cleansing
Backfill
Validation
Parallel operation
Cutover
Reconciliation
Rollback
Legacy retirement
Ownership

Rollback Review

For every material change, identify:

What can be rolled back
What cannot be rolled back
Data written by the new version
Compatibility with the previous version
Rollback trigger
Decision owner
Maximum decision window
User impact
Communication plan

Cost Review

The review should consider both direct and indirect costs.

Direct

Compute
Storage
Data transfer
Licensing
Managed services
Backups
Monitoring

Indirect

Engineering labor
On-call effort
Support
Training
Migration
Compliance
Vendor management
Exit cost

Maintainability Review

Assess:

Complexity
Ownership
Documentation
Testability
Dependency management
Module boundaries
Public contracts
Configuration
Build process
Local development
Debugging
Upgrade path

Organizational Readiness

A technically sound design can still fail if the organization cannot operate it.

Review:

Team skills
Ownership
On-call coverage
Support model
Training
Vendor support
Security review capacity
Data governance
Release management
Budget
Timeline
Cross-team dependencies

Alternatives Review

For each major decision, document:

Option
Benefits
Drawbacks
Cost
Risk
Operational impact
Migration impact
Reversibility
Reason selected or rejected

Alternatives should be realistic, not weak options included only to justify the preferred design.

Architecture Decision Record Exampleprotected

ADR-001 — Use Asynchronous Report Processing

Context: Report generation may take several minutes and requires external data retrieval.

Options:

Synchronous API request
Asynchronous queue-based processing
Scheduled batch generation

Decision: Use asynchronous queue-based processing.

Rationale: It avoids long-lived HTTP requests, supports independent worker scaling, and improves failure recovery.

Tradeoffs:

Requires job-state tracking
Introduces eventual consistency
Requires duplicate-message handling
Increases operational components

Revisit Trigger: Reevaluate if most reports complete in under two seconds or queue operations become a major cost driver.

Review Meeting Structureprotected

A productive review meeting may follow:

Business problem
Goals and non-goals
Requirements
Proposed design
Critical assumptions
Data flow
Security
Failure modes
Operations
Migration
Alternatives
Findings
Decisions
Owners and due dates

Avoid spending the entire meeting debating minor implementation syntax.

Proof-of-Concept Guidanceprotected

A proof of concept should answer a specific design question.

Weak objective: Determine whether the technology works.

Stronger objective: Determine whether the selected database can sustain 2,000 writes per second while maintaining the required transaction behavior and remaining below the defined latency threshold.

A proof of concept should include:

Question
Success criteria
Representative workload
Constraints
Results
Limitations
Decision impact

Design Review Report Structureprotected

Report sections

Executive summary
Review recommendation
Business context
Design summary
Requirements coverage
Strengths
Blocking findings
High-priority findings
Non-blocking recommendations
Security and privacy
Reliability and scale
Data
Operations
Testing
Deployment and migration
Cost
Assumptions
Risks
Open questions
Required actions
Decision records
Approval record

Design Review Metricsprotected

Useful metrics include

Metrics should improve design quality, not encourage unnecessary process.

Designs reviewed before implementation
Average review cycle time
Blocking findings by category
Findings discovered after implementation
Rework caused by design gaps
Security findings identified during design
Migration defects
Rollbacks caused by design omissions
Designs with explicit operational ownership
Designs with capacity assumptions
Designs with rollback plans
Open questions past due
Conditions closed before implementation
Architecture decision records created

Governance Recommendationsprotected

Define:

Which changes require design review
Required design-document sections
Required reviewers
Security review triggers
Privacy review triggers
Data review triggers
Approval authority
Finding severity
Blocking criteria
Risk-acceptance authority
Required validation
Decision-record standards
Review timing
Design ownership
Closure process
Post-implementation review
AI-generated review validation

Suggested Review Triggersprotected

Require formal review for changes involving

New public APIs
New services
New data stores
Authentication
Authorization
Tenant isolation
Sensitive data
Major migrations
New cloud services
Material cost
High availability
Disaster recovery
Cross-team interfaces
External integrations
Critical business processes
Unsupported technology
Irreversible data changes
New regulatory scope

Post-Implementation Reviewprotected

After implementation, compare:

Design assumptions
Actual architecture
Actual performance
Actual cost
Actual failure behavior
Operational burden
Security controls
Test coverage
Migration results
Outstanding debt

Document:

What changed
Why it changed
Which decisions should be updated
Which risks remain
What future designs should learn

Automation Opportunitiesprotected

Architecture review boards
Design-document reviews
Pull-request design checks
Cloud architecture approvals
Security design reviews
API governance
Data architecture governance
Migration planning
Technical due diligence
Platform engineering standards
AI-generated design validation
Engineering readiness reviews
A mature workflow could retrieve the design document, retrieve requirements and standards, extract assumptions and interfaces, build a requirements matrix, identify design gaps, generate review questions, compare against approved patterns, produce a draft risk register, require reviewer confirmation, and track required changes to closure.

Pro Tipsprotected

Begin with business requirements.
Separate missing requirements from design defects.
Review assumptions explicitly.
Identify trust boundaries.
Review failure paths, not only success paths.
Define data ownership.
Treat authorization as a separate concern from authentication.
Require measurable performance and capacity assumptions.
Review deployment and rollback together.
Review database changes for compatibility.
Require idempotency where operations may repeat.
Confirm operational ownership.
Map tests to design risks.
Use proof-of-concept work to answer specific questions.
Document alternatives honestly.
Separate blocking findings from optional improvements.
Avoid preference-based recommendations.
Record important decisions.
Assign owners to every open question.
Review designs before implementation begins.
Revisit the design after implementation.
Require human validation of AI-generated findings.

Common Mistakesprotected

Reviewing Technology Instead of Requirements — A design is not good merely because it uses a preferred platform or framework.
Approving Incomplete Requirements — Missing requirements cannot be solved reliably through architecture assumptions.
Focusing Only on the Success Path — Failure behavior is a core part of the design.
Ignoring Authorization — Authentication does not prove that an authenticated user may access a specific resource.
Treating Data as an Implementation Detail — Data ownership, retention, migration, and recovery often determine the system's long-term risk.
Assuming Queues Guarantee Exactly-Once Processing — Many messaging systems may redeliver messages. Idempotency must be designed explicitly.
Relying on Retries Without Limits — Unbounded retries can amplify outages and increase cost.
Ignoring Rollback — A deployment plan without rollback is incomplete.
Assuming Code Rollback Reverses Data Changes — Persistent data may prevent safe rollback.
Using Hypothetical Scale to Justify Complexity — Design for evidence-based growth and create clear scale triggers.
Omitting Operations — If no team can monitor, support, and recover the system, the design is incomplete.
Treating Logging as Observability — Logs alone may not provide system health, latency, dependency, or business visibility.
Treating Managed Services as Risk-Free — Managed services still have quotas, outages, version changes, cost, and operational requirements.
Failing to Document Alternatives — Without alternatives, reviewers cannot evaluate whether tradeoffs were considered.
Leaving Decisions Unowned — Open questions should have accountable owners and deadlines.
Reviewing Too Late — A design review after implementation becomes a code and remediation review.
Allowing Preference-Based Blocking — Review findings should reference requirements, risks, standards, or evidence.

Security Considerationsprotected

Technical designs frequently contain sensitive information: internal architecture, trust boundaries, security controls, administrative interfaces, data classification, vulnerability assumptions, network topology, recovery limitations, and vendor dependencies.
Before using an AI system, remove active credentials.
Before using an AI system, remove tokens.
Before using an AI system, remove private keys.
Before using an AI system, remove production connection strings.
Sanitize customer information.
Remove unnecessary internal addresses.
Follow architecture-classification requirements.
Follow vulnerability-handling procedures.
Confirm the AI platform is approved.
Confirm retention and training settings.
Restrict distribution of the output.
Do not allow the AI-generated review to become the sole approval record for security-sensitive designs.

Brian Diamond

Founder, BrianOnAI

Twenty-five years designing, operating, and governing enterprise infrastructure — from MSP operations across dozens of client environments to enterprise infrastructure leadership. This blueprint codifies the operating model he's implemented in production, not theory.

Related Blueprints

Perform an AI-Assisted Code Review Analyze and Diagnose a Software Defect Perform an Application Architecture Review Generate Unit and Integration Tests Refactor Code Safely Generate API and Developer Documentation Identify and Prioritize Technical Debt Modernize a Legacy Application Build and Maintain Development Prompts Explain a Legacy PowerShell Script Generate Pester Tests for a PowerShell Script Refactor PowerShell for Readability and Maintainability

⚠ Normalization Warnings — 13 for review

RESTRUCTURE: 'Primary Prompt' and 'Follow-Up Prompts' (two source H1s + 18 H2 sub-prompts) combined into one prompt_pack tool with 19 prompts; 'when' guidance lines are editorial additions, prompt text verbatim.
CLASSIFICATION TO CONFIRM: 'Prerequisites' classified as a checklist TOOL (gather-before-start items). Alternative: body/prose.
CLASSIFICATION TO CONFIRM: 'Requirements Coverage Matrix', 'Assumption Register', 'Constraint Register', and 'Design Validation Matrix' classified as matrix TOOLS — each is a real table the practitioner completes. Their doc rows are captured as example_rows; skeleton_rows: 0 (downloads ship empty).
CLASSIFICATION TO CONFIRM: 'Design Review Checklist' is an unambiguous checklist tool. 'Design Review Checklist' groups preserved verbatim from source H2 subsections.
CLASSIFICATION TO CONFIRM: 'Testing Recommendations' classified as a checklist TOOL renamed 'Pre-Approval Validation Checklist' (items are selectable validation activities). Alternative: body/reference. Display name changed from source heading — confirm.
CLASSIFICATION TO CONFIRM: 'Blocking Finding Template' and 'Open Question Template' classified as template TOOLS (labeled fill-in structures with placeholders). Guidance text is the doc's own prompt text under each label.
CLASSIFICATION TO CONFIRM: 'Failure-Mode Table', 'Testing Review Considerations' table, and the matrix/register example tables inside body: the Failure-Mode Table and Testing risk/test table are kept as body/example (illustrative, not a tool the reader completes here) since the FILL-IN failure-mode work is driven by the 'Review Reliability Design' prompt. Confirm the Failure-Mode Table is not intended as a standalone matrix tool.
CLASSIFICATION: severity/confidence/outcome models, evidence types, document structure, report structure, review triggers, and metrics classified as body/reference (consulted taxonomies). Review Outcome Model, Finding Severity Model, and Confidence Model rendered as tiered references.
GROUPING: 'Design Review Categories' (14 H2s) and the many detailed *-Review-Considerations H1s grouped under two body groups ('Design Review Categories' and 'Detailed Review Considerations') to avoid a flat 40+ section list. Confirm grouping boundaries.
STATS: deliverables counted as 12 tools; prompts counted as 19 (1 primary + 18 follow-ups). Confirm counting convention.
PLAYBOOK: security_considerations and common_mistakes populated from dedicated H1 sections (prose subsections flattened to list items with heading — text preserved). No Quick Wins or Roadmap sections exist in this doc; playbook.quick_wins and roadmap intentionally empty.
NON-STANDARD TAIL SECTIONS: 'Governance Recommendations', 'Suggested Review Triggers', 'Design Review Metrics', 'Post-Implementation Review', 'Review Meeting Structure', 'Proof-of-Concept Guidance', 'Design Review Report Structure' retained in body (reference/prose) rather than playbook — they are consulted guidance, not the standard playbook tail. Confirm.
DATE: normalization date is a placeholder ISO date; set to actual run date.

SEO Block

Title tag: Review a Technical Design with AI | ABME (40 chars)
Meta: Review any technical design against requirements, failure modes, security, and operability — with a severity model, risk register, and approve/revise/reject call. (162 chars)
Schema: HowTo · noindex: false
Related: ai-001, ai-002, ai-003, ai-004, ai-005, ai-006, ai-007, ai-009, ai-010, ps-001, ps-004, ps-005, ps-006, ps-007, ps-008, ps-009, ps-010
Keywords: technical design review, architecture review, design review checklist, requirements coverage matrix, failure mode analysis, technical due diligence, architecture decision record, design review severity model, migration review, rollback review

Copied

Catch the Design Flaws Before They Become Production Incidents — A Structured Technical Design Review

Executive Brief

Your Challenge

Common Obstacles

The ABME Approach

Insight Summary

The Journey

Frame the Design and Its Requirements

Review the Design Across Every Dimension

Decide, Validate, and Record

What's Inside the Execution Layer

Prerequisites Checklist

Technical Design Review Prompt Pack

Primary Prompt

Review Requirements Coverage

Review Architecture Boundaries

Review API Design

Review Event-Driven Design

Review Data Design

Review Security Design

Review Multi-Tenant Design

Review Reliability Design

Review Scalability and Capacity

Review Performance Design

Review Observability Design

Review Deployment and Rollback

Review Migration Design

Review Testing Strategy

Review Cost Model

Generate Design Review Questions

Create Architecture Decision Records

Requirements Coverage Matrix

Assumption Register

Constraint Register

Design Validation Matrix

Design Review Checklist

Business and Scope

Requirements

Architecture

Data

Security and Privacy

Reliability and Scale

Operations

Testing

Delivery

Cost and Readiness

Blocking Finding Template

Finding ID

Title

Requirement

Evidence

Impact

Required Change

Validation

Owner

Deadline

Open Question Template

Question ID

Question

Why It Matters

Owner

Required By

Possible Outcomes

Pre-Approval Validation Checklist

Full Playbook

Overviewpublic

Business Problempublic

Typical Use Casespublic

Do NOT Use This Workflow Whenpublic

Expected Outcomepublic

Technical Design Review Objectivesprotected

Design Review Categoriesprotected

Business Alignment

Requirements Coverage

Scope

Architecture

Interfaces

Data

Security

Reliability