High-Level Design (HLD) Review
Review High-Level Design documents against architecture principles, requirements, and quality standards.Command
Description
Performs comprehensive review of High-Level Design documents to ensure alignment with architecture principles, requirements coverage, and implementation readiness. Provides structured feedback with blocking issues and recommendations.Arguments
- Project ID or HLD path: Project identifier or path to HLD document (e.g., ‘001’, ‘vendors/acme/hld-v1.md’)
When to Use
- After receiving vendor HLD
- Before DLD phase begins
- During design review gates
- For vendor proposal evaluation
- Before implementation approval
Required Context
- Architecture Principles (ARC-000-PRIN-*.md) - MANDATORY
- Requirements (ARC--REQ-.md) - MANDATORY
- SOW (Statement of Work) - Recommended
- Risk Register (ARC--RISK-.md) - Recommended
- Architecture Diagrams (DIAG) - For cross-reference
Review Criteria
A. Architecture Principles Compliance
For each principle:- ✅ Compliant - Design follows principle
- ⚠️ Violation - Design violates principle
- ❓ Exception - Approved deviation
- Cloud-First: Using cloud-native services?
- API-First: RESTful API strategy?
- Security by Design: Encryption, authentication?
- Microservices: Proper service boundaries?
B. Requirements Coverage
For each requirement:- Verify coverage in HLD
- Assess design adequacy
- Trace to components
- NFR-P-001 (<2s response): CDN? Caching? Database indexing?
- NFR-S-001 (PCI-DSS): Security architecture? Token vault?
C. Architecture Quality
Scalability:- Horizontal scaling strategy
- Load balancing approach
- Database scaling (sharding, read replicas)
- Stateless design
- Caching strategy (Redis, CDN)
- Database optimization
- Asynchronous processing
- API response times
- Authentication/Authorization (OAuth, JWT, RBAC)
- Data encryption (at rest, in transit)
- Secrets management
- API security (rate limiting, WAF)
- Fault tolerance (circuit breakers, retries)
- Disaster recovery (RTO/RPO)
- Multi-region/AZ deployment
- Data backup strategy
- Monitoring and observability
- CI/CD pipeline
- Blue-green or canary deployment
- Runbooks and automation
D. Architecture Patterns
- Patterns used correctly?
- Anti-patterns identified?
- Data consistency strategy
- Integration patterns
E. Technology Stack
- Technologies from approved list?
- Deprecated technologies avoided?
- License compliance
- Team expertise
- Vendor lock-in risks
Risk Assessment
HIGH (Blocking):- Principle violations
- Missing NFRs
- Security gaps
- Suboptimal design
- Performance concerns
- Technical debt
- Minor improvements
- Documentation gaps
Review Output
Executive Summary
Status:- ✅ APPROVED
- ⚠️ APPROVED WITH CONDITIONS
- ❌ REJECTED
Detailed Findings
- Principle compliance (violations flagged)
- Requirements coverage matrix
- Architecture quality scores
- Risk assessment
- Open questions for vendor
Action Items
BLOCKING (must fix before approval):- Critical security gaps
- Principle violations
- Missing critical NFRs
- Performance optimizations
- Documentation gaps
- Future enhancements
Output
Creates:projects/{project}/vendors/{vendor}/ARC-{PROJECT_ID}-HLDR-v1.0.md
Example Review
Input
Assessment
- ✅ Cloud-First: Using AWS cloud-native
- ✅ API-First: RESTful with OpenAPI
- ❌ Microservices: Single monolith (VIOLATION)
- ✅ Security: PCI-DSS compliant
- ⚠️ Resilience: Single region (RISK)
Outcome
Status: APPROVED WITH CONDITIONS Blocking Items:- Must add multi-AZ for 99.99% uptime
- Consider microservices migration path
Review Scores
- Scalability: 7/10
- Security: 9/10
- Resilience: 6/10
- Overall: 73/100
Related Commands
arckit dld-review- Review Detailed Design (after HLD approval)arckit diagram- Generate diagrams from HLDarckit requirements- Source requirements for review
Important Notes
- HLD review is a GATE - implementation cannot start until approved
- All findings must reference specific principles or requirements
- Security and compliance violations are typically blocking
- Document any assumptions or questions for vendor
- HLD approval is NOT final sign-off (DLD review comes next)
Next Steps
After HLD approval:- Vendor addresses blocking items
- Re-review if major changes
- Proceed to DLD phase
- Update traceability matrix
- Schedule DLD review