Engineering Quality Gate — architecture and implementation review

Focused engineering gate for choosing and running Architecture Boundary Review and Standards-Backed Implementation Review, without mixing in testing, refactor planning, or general code-quality workflows.

Purpose

This guide defines a focused engineering quality gate for architecture boundary review and standards-backed implementation review. It helps the user decide whether the task needs structure and boundary review, official-guidance implementation review, or both in sequence. It is not the full code-review hub and does not cover test coverage, regression risk, refactor planning, general code-quality review, or code generation.

When to use this

Use this section to decide whether this workflow is the right fit before you configure prompts, policies, or reference material.

Use case
The review is limited to architecture and implementation correctness
Use this when the approval question is whether design boundaries are correct and whether implementation follows official guidance.
Use case
You need to choose between two focused review paths
Use this when the task may require Architecture Boundary Review, Standards-Backed Implementation Review, or both in sequence.
Use case
You need a focused gate before broader code-review work
Use this before opening the full code-review hub when the first decision is whether the issue is structural or standards-backed implementation correctness.

Decision guide

Choose the focused engineering gate path

Use this page only for the architecture plus implementation quality gate. For testing, regression risk, refactor planning, general code quality, or code generation, use the full code review hub.

Option 1 · Architecture boundary review
Run Architecture Boundary Review
Use this path when the primary issue is system structure: boundaries, layering, ownership, dependency direction, state flow, or interface separation.
Evidence boundary: Code, architecture context, dependency information, ownership boundaries, state flow, and interface evidence.
Best for: Module boundaries, dependency direction, layering, ownership, coupling, state boundaries, interface contracts, and boundary leakage.
Use when: The review question is whether the system shape or boundary is correct.
Open guide
Option 2 · Standards-backed implementation review
Run Standards-Backed Implementation Review
Use this path when the primary issue is whether code or configuration follows official framework, runtime, API, platform, or standards guidance.
Evidence boundary: Code or configuration plus official documentation, standards, platform guidance, or other authoritative source material.
Best for: Implementation correctness, API misuse, version-sensitive behavior, configuration correctness, and source-backed remediation.
Use when: The review question is whether the implementation is correct according to authoritative guidance.
Open guide

Workflow assets

Required workflow assets

Open the prompts, policies, and reference pages needed to run this workflow correctly.

Required policy
Engineering Quality Gate policy
Defines the focused gate for choosing and sequencing Architecture Boundary Review and Standards-Backed Implementation Review.
Type: Focused engineering gate policy
Controls: Gate scope, review-path routing, review order, evidence requirements, and separation of architecture findings from implementation findings.
Read policy
Required reference
Prompt layers and policy mapping
Explains where instruction rules, source material, runtime prompts, and verification gates belong.
Type: Configuration reference
Use when: Use when configuring this gate in ChatGPT, Claude, Gemini, or an internal AI system.
Open reference

Implementation procedure

Step-by-step implementation procedure

Follow the workflow in order. Each step gives one action and one verification check before continuing.

  1. Runtime prompt layer

    Confirm this is the focused gate

    Check whether the task is limited to architecture boundaries and standards-backed implementation correctness.

    Action
    Use the full code review hub instead if testing, regression risk, refactor planning, general code quality, or code generation is part of the task.
    Verify
    The review scope is architecture and/or implementation correctness only.
    Open full code review hub

  2. Runtime prompt layer

    Choose the dominant review path

    Select Architecture Boundary Review when the problem is structure. Select Standards-Backed Implementation Review when the problem is correctness against official guidance.

    Action
    Choose one path first instead of merging both review contracts into one prompt.
    Verify
    The selected path matches the dominant engineering question.

  3. Reference layer

    Provide the right evidence for the selected path

    Architecture review needs structural evidence. Standards-backed implementation review needs code or configuration plus authoritative guidance or a clear source boundary.

    Action
    Attach the relevant code, configuration, architecture context, dependency information, official documentation, or supplied source material.
    Verify
    The supplied evidence is sufficient for the selected review path.

  4. Runtime prompt layer

    Run the selected procedure

    Open the selected procedure and run it with the prepared material.

    Action
    Use the architecture procedure for structure and boundaries. Use the standards procedure for implementation correctness against guidance.
    Verify
    The procedure output stays inside the selected review boundary.
    Open guide Open guide

  5. Verification layer

    Run both only when both are needed

    When both focused reviews are required, run Architecture Boundary Review first, then Standards-Backed Implementation Review.

    Action
    Do not combine both contracts into one unstructured review. Use two passes and keep findings separated.
    Verify
    Architecture findings and implementation findings are separated and supported by the relevant evidence.

Verification checklist

Use this checklist before accepting the output, publishing it, or using it as evidence for a downstream workflow.

Scope
The gate stayed focused
The review did not expand into test coverage, regression risk, refactor planning, general code-quality review, or code generation.
Routing
The selected path matches the dominant issue
Architecture review is used for structure and boundaries. Standards-backed implementation review is used for implementation correctness against authoritative guidance.
Evidence
The required material is available
Architecture findings are supported by structural evidence, and implementation findings are supported by code/configuration plus authoritative guidance or supplied source material.
Order
Dual review runs in the correct order
When both reviews are needed, architecture runs first, then implementation review.
Separation
Findings are not mixed
Architecture findings, implementation findings, missing evidence, and next actions are separated.

Next step