Run the architecture boundary review — procedure

Procedure for architecture classification, layering and boundary analysis, and minimal structural remediation from inspected materials.

Purpose

Use this procedure when the review question is whether the architecture structure, layers, boundaries, ownership, dependencies, interfaces, or state flow are supported by the inspected materials. The procedure prevents unsupported architecture claims and keeps recommendations limited to the available evidence.

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 main question is architectural structure
Use this when the task is about architecture structure, layers, module boundaries, ownership, dependency direction, interface contracts, coupling, or state ownership.
Use case
Architecture claims must be evidence-based
Use this when architecture findings must be supported by supplied files, file trees, diagrams, snippets, or design excerpts.
Use case
The output should propose a minimal change set
Use this when the answer should identify boundary issues and recommend the smallest defensible architecture change set.

Workflow assets

Required workflow assets

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

Required prompt
Facts-only artifacts-only system prompt
Keeps the review grounded in inspected materials and blocks unsupported architecture claims.
Type: System prompt
Belongs in: Instruction layer
Required prompt
Architecture boundary review system prompt
Defines the architecture review scope, evidence rules, and output contract.
Type: System prompt
Belongs in: Instruction layer
Required prompt
Architecture boundary review user prompt
Runs the architecture review with the current goal, inspected materials, constraints, and optional boundary rules.
Type: User prompt
Belongs in: Runtime prompt layer
Optional prompt
Read all provided artifacts first
Use when the supplied material is small enough to read fully and the run must confirm complete input coverage.
Type: Prompt component
Belongs in: Runtime prompt layer
Optional prompt
Scan all artifacts exhaustively
Use when the supplied material is a repository snapshot, ZIP, or many files and the run must avoid selective inspection.
Type: Prompt component
Belongs in: Runtime prompt layer
Optional prompt
Analyze before answering
Use when the review needs an additional evidence and conflict pass before final output.
Type: Prompt component
Belongs in: Verification layer
Optional prompt
Terminology consistency control
Use when architecture terms, boundary terms, or implementation terms need consistent definitions.
Type: Prompt component
Belongs in: Verification layer
Required policy
Architecture boundary review policy
Defines the review boundary for architecture structure, layering, ownership, dependency direction, interface contracts, coupling, and evidence handling.
Type: Review policy
Controls: Architecture evidence, boundary findings, source handling, minimal change planning, and confidence reporting.

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

    State the review target

    Say what should be evaluated: architecture structure, boundary correctness, dependency direction, state ownership, interface boundaries, or another specific architecture concern.

    Action
    Provide the review goal, inspected materials, constraints, and optional intended boundary rules.
    Verify
    The target is architectural, not a general implementation, security, or performance review.
  2. Instruction layer

    Load the provided-material evidence boundary

    Apply the facts-only artifacts-only system prompt so the review stays grounded in inspected materials by default.

    Verify
    The run does not use external or memory-based architecture claims unless explicitly allowed.
  3. Instruction layer

    Load the architecture review scope

    Apply the architecture boundary review system prompt.

    Verify
    The review scope is limited to architecture structure, layering, boundaries, ownership, dependency direction, interfaces, state ownership, and coupling.
  4. Runtime prompt layer

    Load the runner

    Apply the architecture boundary review user prompt and append the goal, materials, constraints, and optional boundary rules.

    Verify
    Goal, materials, and constraints are present before the run starts.
  5. Runtime prompt layer

    Add coverage controls only when needed

    Use exhaustive scanning for repository snapshots, ZIPs, or many files. Use read-all handling when the input is smaller but must be inspected completely.

    Action
    Add only the input-coverage component that matches the material size.
    Verify
    The run declares what was inspected and does not imply complete coverage without a coverage control.
  6. Verification layer

    Run the review in the required output order

    The output must include context snapshot, evidence-based architecture classification, boundary findings, change set plan, and confidence.

    Action
    Keep output sections separated and evidence-bound.
    Verify
    Architecture classification is marked NOT VERIFIED when supplied material is insufficient.
  7. Verification layer

    Check the boundary of the result

    Confirm that the output uses only inspected materials for architecture evidence, does not invent hidden architecture, stays inside architecture scope, and proposes minimal changes.

    Action
    Revise or stop when the result exceeds the selected evidence boundary.
    Verify
    Findings are scoped, supported, and minimal.

Verification checklist

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

Inputs
Goal, materials, and constraints are present
If any required input is missing, the review reports insufficient evidence instead of continuing.
Evidence
Architecture claims are supported by inspected materials
The review does not invent architecture intent, module ownership, hidden dependencies, or missing file content.
Scope
Findings stay within architecture review scope
The review does not drift into framework guidance, security review, performance tuning, or broad rewrite planning.
Output
The output follows the required section order
The answer separates context snapshot, architecture classification, boundary findings, change set plan, and confidence.
Recommendation
The change set is minimal and architecture-focused
Recommendations propose the smallest defensible architecture change set for the observed boundary issue.

Next step