Engineering Quality Gate — focused policy

Policy for using the Engineering Quality Gate as a focused architecture plus standards-backed implementation review gate.

Scope and review order

Use this policy when the review scope is intentionally limited to architecture boundaries and standards-backed implementation correctness.

  • Architecture + implementation only
    This policy routes the review to Architecture Boundary Review, Standards-Backed Implementation Review, or both in sequence.
  • Not the full code-review hub
    Use the full code-review policy when the task includes test coverage, regression risk, refactor planning, general code quality, or code generation.
  • Architecture first when both are needed
    If both focused reviews are required, run Architecture Boundary Review first, then Standards-Backed Implementation Review.

Policy rules

These rules define the focused gate before a concrete review procedure runs.

  1. Rule 1 · Use this gate only for focused engineering review
    The gate is valid only when the task is about architecture boundaries, layering, ownership, dependency direction, standards-backed implementation correctness, or both.
  2. Rule 2 · Select one dominant review path first
    Choose Architecture Boundary Review when the dominant issue is structural. Choose Standards-Backed Implementation Review when the dominant issue is correctness against authoritative guidance.
  3. Rule 3 · Do not merge review contracts
    Architecture findings and standards-backed implementation findings must remain separate. If both reviews are needed, run them as two passes.
  4. Rule 4 · Require the right evidence for each path
    Architecture review requires structural evidence. Standards-Backed Implementation Review requires code or configuration plus authoritative guidance or a clearly supplied source boundary.

Choose the active review policy

The Engineering Quality Gate policy routes the review. The selected child policy controls the concrete review run.

Option 1 · Architecture
Architecture Boundary Review
Use this when the primary issue is module boundaries, layering, dependency direction, ownership, coupling, state boundaries, interface contracts, or boundary leakage.
Open Architecture Boundary Review policy →
Option 2 · Implementation
Standards-Backed Implementation Review
Use this when the primary issue is whether code or configuration follows official framework, runtime, API, platform, standard, or other authoritative guidance.
Open Standards-Backed Implementation Review policy →

Use a different policy when the scope is broader

This focused gate must not absorb adjacent engineering workflows.

Full code-review policy
Use when the task includes test coverage, regression risk, refactor planning, code quality, code generation, or broader review routing.
Open policy →
Test coverage and regression risk
Use when the task is about missing tests, weak assertions, fixture or mock drift, test setup gaps, or regression-sensitive behavior.
Open workflow →
Code quality and best practices
Use when the task is readability, maintainability, naming, modularity, error handling, framework conventions, or general implementation quality.
Open prompt →

Verification checklist

Use this checklist before accepting that the focused gate was applied correctly.

  • Scope stayed focused
    The run did not expand into testing, regression risk, refactor planning, general code quality, or code generation.
  • Path matched the dominant issue
    Architecture review was used for structure and boundaries. Standards-backed implementation review was used for authoritative-guidance correctness.
  • Evidence was sufficient
    Architecture findings were supported by structural evidence, and implementation findings were supported by code/configuration plus authoritative guidance or supplied source material.
  • Findings stayed separated
    Architecture findings, implementation findings, missing evidence, and next actions were not merged into one undifferentiated review output.