Review system architecture and boundaries

Rules for reviewing system architecture, boundaries, dependency direction, ownership, and minimal structural remediation.

What this policy enforces

Use this policy when the dominant question is about the shape and boundaries of the system rather than implementation correctness against official guidance.

Review type
Architecture-focused review
This policy is centered on architecture classification, layering, dependency direction, boundary leakage, interface ownership, state ownership, and minimal structural remediation.
It is a boundary-first review model.
Scope boundary
System shape, not framework best-practice sweep
Use this policy when the dominant question is about system structure and architectural boundaries.
Do not use it as a general framework best-practice audit.
Output contract
Smallest defensible structural delta
Recommendations must stay evidence-bound and propose the smallest structural change that resolves the observed boundary problem.
No speculative rewrites.

Scope

These are the review domains this policy is designed to cover.

Architecture classification
Classify the architecture only when the materials support that classification.
Layering and dependency direction
Review whether layers and dependency flow are coherent and directional.
Interface and contract boundaries
Check interface ownership, contract drift, and boundary leakage.
Coupling and state ownership
Inspect coupling patterns and whether state ownership is structurally clear.
File-specific structural remediation
Translate findings into concrete file-level structural remediation steps when feasible.

Non-goals

This section prevents the policy from being used outside its intended structural boundary.

Out of scope
Not a general framework or library audit
Do not use this policy for a broad framework or library best-practice sweep.
Out of scope
Not a secure code review
Security review is out of scope unless the goal and materials explicitly support that review.
Out of scope
Not a performance tuning review
Do not use this policy for performance optimization unless the question is explicitly structural and evidenced.
Out of scope
Not a rewrite mandate for whole subsystems
Do not escalate to large rewrites by default when a smaller structural remediation is sufficient.

Rules (normative)

These rules define the minimum operating contract for an architecture boundary review.

R1
No simulation
Do not invent architecture intent, module ownership, hidden dependencies, or missing file content.
R2
Evidence-based architecture only
Classify the architecture only when the inspected materials support that classification.
Otherwise mark it NOT VERIFIED.
R3
Boundary-first findings
Findings must stay within architecture, layering, dependency direction, interface, state ownership, and coupling scope.
R4
Source handling
If a recommendation depends on an external framework convention, standard, or primary reference, cite it or mark that recommendation NOT VERIFIED.
R5
Minimal structural delta
Recommendations must propose the smallest structural change that resolves the observed boundary problem.
R6
Fail-closed
If goal, materials, or constraints are insufficient, output only:
INSUFFICIENT_EVIDENCE: <what is missing>
R7
Confidence required
Output one 0–100 confidence score based on evidence completeness and architectural clarity.

Use this policy with

Open the exact procedure, prompt, and control component that apply this architecture-boundary review policy.

Run the architecture boundary review — procedure
Use this procedure to run the architecture review with required inputs, evidence boundaries, workflow steps, and verification checks.
Open procedure →
Review Architecture and Boundaries
Use this runnable prompt when the task is architecture classification, layering, dependency direction, interface boundaries, state ownership, and minimal structural remediation.
Open prompt →
No Simulation / No Fabrication
Use this control component to prevent invented project files, dependencies, runtime behavior, command output, test results, or unsupported architecture claims.
Open component →