Conduct Architect Reviews

Architect reviews protect engineering quality without making the architect the author of every implementation choice. The review identifies material problems in structure, security, integration, maintainability, and adherence to approved enterprise assets.

Responsible role: Architect / Senior Engineer.
Participants: Product Engineer; other specialists when risk or policy requires them.
Inputs: Implemented changes, applicable standing instructions, architecture decisions, related specifications, ordinary tests, known issues; independent verification results for final review.
Outputs: Findings with severity and disposition, agreed corrections, and technical sign-off where required.

Stage 2 technical foundation work prepares the approved environment and architectural direction. Cycle 1 includes two planned reviews of implemented software, at Stages 4 and 7; preparation does not add a separate mandatory review.

Initial review, Cycle 1 Stage 4. Assess the first substantial implementation before the team invests further in client-led iteration. This review focuses on whether the architectural foundation, reuse choices, integration approach, security boundaries, and maintainability are credible. Material findings are corrected before substantial stakeholder review.

Final review, Cycle 1 Stage 7. Assess the implementation after stakeholder changes and Spec-Based Testing. Confirm earlier findings remain resolved; examine any new risks introduced during iteration; consider verification failures or limitations; and establish technical readiness for UAT under enterprise policy.

1. Understand what changed and why. Read the relevant specifications and change context. Review only source code without knowing intended behavior can miss the most important failure.

2. Examine architectural fit. Confirm that responsibilities are appropriately separated, approved platforms and assets are used, dependencies are justified, integration boundaries remain understandable, and the code can be maintained by the Product Engineer over time.

3. Examine material safety and security concerns. Consider authorization boundaries, secret exposure, data access, external integrations, input handling, and other application-specific risks. Coordinate specialist reviews where enterprise policy requires them.

4. Review testing and known limitations. Look for credible automated coverage and observable behavior, and review independent verification evidence during final sign-off. A passing test command is evidence, but not proof of correctness or suitability.

5. Record actionable findings. Explain each significant problem, its consequence, expected correction or decision, and owner. Distinguish blocking findings from improvements that can reasonably follow later.

6. Verify correction and conclude. The Product Engineer directs necessary changes and supplies evidence of resolution. The architect confirms disposition and makes the required technical decision.

Cycle 2 architect reviews occur where required by risk and enterprise policy. Relevant triggers can include changes to permissions, integrations, data flows, shared libraries, or architecture. A routine change that uses existing approved patterns should not automatically be subjected to the same process as a new security boundary.

Required review has occurred; material findings have explicit disposition; blocking problems are resolved or escalated under applicable policy; and the technical decision is recorded separately from business UAT acceptance.

Reducing review to style preferences; discovering architecture issues only after extensive client iteration; treating every routine change as a formal architecture project; and presenting technical sign-off as proof that the product solves the business problem.