architecture-review-gate

어떤 스킬인가요?

Use when independently reviewing or verifying an architecture specification, RFC, ADR, diagram, migration plan, AI or agent design, production-readiness proposal, architecture metrics, or post-incident structural causes. May frame review criteria or recommend bounded remediation, but does not own greenfield design or repository changes.

설치 방법

프로젝트 폴더에서 아래 명령어를 실행하고, 설치할 에이전트를 선택하세요.

설치 명령을 직접 실행해야 적용됩니다. 지원 에이전트와 필요한 권한·라이선스는 제작자의 안내를 확인하세요.

스킬 원문 파일

interface:
  display_name: "Review Software Architecture"
  short_description: "Independent review of architecture decisions and evidence"
  default_prompt: "Use $architecture-review-gate in Think, Review, Change, or Verify mode for an independent architecture evidence gate."

# Architecture Review Checklist

## Gate A — Problem and Fitness

- [ ] Problem and stakeholders precede technology.
- [ ] Quality attributes are measurable scenarios.
- [ ] Workload covers range, peak, burst, growth, skew, and uncertainty.
- [ ] Constraints, assumptions, unacceptable failure, and decision owner are explicit.

## Gate B — State and Boundaries

- [ ] State is classified as authoritative, derived, ephemeral, sensitive, or rebuildable.
- [ ] Invariants, transactions, consistency, ordering, duplication, cancellation, and unknown outcomes are explicit.
- [ ] Every boundary buys independent change, scale, failure, governance, or security capability.
- [ ] Ownership, retention, deletion, residency, backup, and restore are explicit.

## Gate C — Failure and Assurance

- [ ] Retries, deadlines, queues, pools, concurrency, fan-out, and recovery load are bounded.
- [ ] Shared dependencies and correlated failure domains are mapped.
- [ ] Threats, privileges, identities, secrets, abuse, and tenant boundaries are reviewed.
- [ ] Tests cover logic, integration, concurrency, load, recovery, and adversarial failure.
- [ ] Every applicable critical blocker was checked independently.

## Gate D — Delivery and Operation

- [ ] Code, schema, configuration, and infrastructure changes support mixed versions and safe repair.
- [ ] Canary, stop conditions, rollback/roll-forward, backfill, and reconciliation exist where needed.
- [ ] Telemetry connects user outcomes to requests, workflows, data, dependencies, cost, and owners.
- [ ] On-call, runbooks, restore drills, capacity envelope, and next bottleneck are evidenced.

## Gate E — Economics, Complexity, and Evolution

- [ ] Cost includes infrastructure, people, incidents, coordination, licensing, support, and migration.
- [ ] Complexity Ledger covers capability, alternatives, obligations, failure, knowledge, security, performance, cost, and operations.
- [ ] Reversibility, expected lifetime/deletion, compatibility, and exit path are explicit.
- [ ] Every decision has evidence, a validation trigger, owner, and review date.

## Evidence and Decision Integrity

- [ ] Every dimension has an evidence state and quality; missing is distinct from contradicted.
- [ ] Source type, study design, scale/context, counter-evidence, validity threats, and stable citation are recorded for consequential external claims.
- [ ] Source claims are separate from reviewer inferences.
- [ ] Blockers remain non-compensable; the vector is primary.
- [ ] Any optional numeric summary is transparent, sensitivity-aware, non-authorizing, and free of universal thresholds.
- [ ] A separate adversarial/sensitivity pass was completed and reports the challenges run, findings changed, and verdict sensitivity; it is not merely a future test list.

## Incident and Metric Addendum

- [ ] Incident analysis separates trigger from enabling conditions and traces decision → hidden dependency → trigger → propagation → blast radius → detection → recovery constraints → structural correction.
- [ ] Metrics document definition/unit, source/data quality, intended decision, confounders, gaming risk, owner, and review/retirement.
- [ ] Architecture metrics are not used to rank individual engineers.

# Architecture Review Report

## Verdict

- Decision gated:
- Verdict: PASS / CONDITIONAL / BLOCK / INSUFFICIENT EVIDENCE
- Confidence and limits:
- Model/version:
- Accountable decision owner:
- Review date and reviewers:
- Optional numeric summary, decision purpose, and sensitivity (omit when not defensible):

## Architecture Reconstruction

- Current state:
- Target state:
- Transition state:
- State authority and trust boundaries:
- Critical journeys and dependencies:

## Five-Gate Evidence Vector

| Gate | Dimension / protected condition | Evidence state | Evidence quality | Evidence and counter-evidence | Finding | Required proof |
|---|---|---|---|---|---|---|

### Excluded Dimensions and Reasons

## Critical Blockers

### Finding

- Evidence:
- Source claim / verified fact / reviewer inference:
- Failure mechanism:
- Impact and affected journey/data:
- Severity/confidence:
- Required condition:
- Owner:
- Proof required:

## High and Medium Findings

## Requirement-to-Decision Gaps

## Complexity Ledger Review

- Ledger supplied: yes / no

| Decision/requirement | Capability and alternatives | Introduced obligations | Failure/knowledge/security/performance/cost | Reversibility/lifetime | Evidence/validation trigger | Owner/review date |
|---|---|---|---|---|---|---|

## Invariants, Data, Workflows, Scale, and Overload

## Reliability and Recovery

## Security, Privacy, Tenancy, and Abuse

## Operations, Delivery, Migration, Cost, and Metrics

### Metric Governance

| Metric | Definition/unit | Source/data quality | Intended decision | Confounders/gaming risk | Owner | Review/retirement |
|---|---|---|---|---|---|---|

## Evidence Challenge

| Claim | Source type/study design | Scale/context | Counter-evidence | Threats to validity | Source claim | Reviewer inference | Confidence | Stable citation |
|---|---|---|---|---|---|---|---|---|

## Evidence Missing

## Adversarial Review and Reviewer Disagreements

## Approval Conditions

| Condition | Owner | Proof | Review trigger |
|---|---|---|---|

## Positive Evidence to Preserve

# Post-Incident Architecture Review

## Incident and Decision

- Incident/window:
- Decision being reviewed:
- Affected journeys, data, tenants, or regions:
- Accountable owners:
- Evidence supplied and missing:
- Confidence limits:

## Verified Timeline

| Time | Event | Evidence | Fact / inference / unknown |
|---|---|---|---|

## Causal Chain

| Link | Evidence | Confidence | Counter-evidence / unknowns |
|---|---|---|---|
| Architecture decision | | | |
| Hidden dependency | | | |
| Initiating trigger | | | |
| Propagation mechanism | | | |
| Blast radius | | | |
| Detection | | | |
| Recovery constraints | | | |
| Structural correction | | | |

## Trigger Versus Enabling Conditions

- Initiating trigger:
- Structural enabling conditions:
- Why another trigger could recur:

## Five-Gate Evidence Vector

| Gate | Incident evidence | Failed or preserved condition | Required proof |
|---|---|---|---|

## Complexity Ledger Comparison

- Ledger supplied before incident: yes / no
- Obligations predicted:
- Obligations missed:
- Capability still justified:
- Reversibility and lifetime implications:
- Updated validation trigger, owner, and review date:

## Structural Corrections

| Correction | Causal link changed | Owner | Validation | Recurrence signal | Due/review trigger |
|---|---|---|---|---|---|

## Non-Structural Actions

List training, documentation, or personnel/process actions separately. Do not present them as sufficient when enabling architecture remains unchanged.

## Metric Changes

| Metric | Definition/unit | Source/data quality | Intended decision | Confounders/gaming | Owner | Review/retirement |
|---|---|---|---|---|---|---|

## Verdict and Remaining Risk

# Contextual Evidence-Vector Review Example

This abbreviated example reviews `review-input-critical.md`. It demonstrates a vector-first decision in which blockers remain separate from evidence quality.

## Review Contract

- **Decision gated:** approve implementation of a multi-region commerce platform.
- **Critical journeys:** price calculation, order acceptance, event publication, authorization, and regional failover.
- **Unacceptable failure:** financial error, lost or duplicated side effects, cross-tenant access, divergent write authority, or unrecoverable release.
- **Evidence supplied:** one short proposal; no workload model, contracts, measurements, tests, Complexity Ledger, or recovery evidence.
- **Decision horizon:** implementation approval.

## Five-Gate Evidence Vector

| Gate | Dimension / protected condition | Evidence state | Evidence quality | Finding | Required proof |
|---|---|---|---|---|---|
| A | Requirement and workload fit | claimed | low | “because they scale” does not establish workload, bottleneck, or independent-deployment need | measurable scenarios, ranges, sensitivity, and alternative comparison |
| B | Financial/state authority | contradicted | high | floating-point prices and independent database/broker writes violate required correctness | exact money model, atomic invariants, coordinated publication, reconciliation |
| B | Multi-region write authority | claimed | low | active-active is named without routing, conflict, fencing, failback, or repair semantics | authority model and failure-tested protocol |
| C | Authorization and trust | contradicted | high | gateway-only authorization and implicit internal trust leave downstream boundaries exposed | service/data-boundary authorization and tenant tests |
| C | Messaging and overload | contradicted | high | retries and queues are explicitly unbounded | deadlines, attempts, capacity, backpressure, replay, and repair proof |
| D | Recovery and delivery | claimed | low | backups and direct deployment are named without restore, RTO/RPO, compatibility, rollback, or forward repair | representative restore and release rehearsal evidence |
| E | Lifecycle obligations | missing | none | no Complexity Ledger, cost, reversibility, lifetime, owner, or revision trigger is supplied | owned ledger and evidence-based review trigger |

## Critical Blockers

1. Floating-point financial values can violate exact monetary semantics.
2. Database and broker effects are dual-written without atomic coordination or repair.
3. Retry and queue paths are unbounded.
4. Authorization is not enforced at service and data boundaries.
5. Active-active writes lack authority, conflict, and fencing semantics.
6. Backup is presented without restore evidence.
7. Delivery lacks compatibility and rollback/roll-forward evidence.

These blockers are not compensated by strengths elsewhere. **Verdict: BLOCK.** Confidence is high for statements explicit in the proposal and low for unstated implementation details.

## Complexity Ledger Review

No ledger was supplied. The review cannot verify capability gained, alternatives, introduced concepts/state/protocol/configuration/dependencies, operational responsibility, new failure modes, knowledge needs, security/performance/cost effects, reversibility, expected lifetime, evidence, validation trigger, owner, or review date.

## Evidence Challenge

The proposal's “scales” and “multi-region” statements are author claims, not measured evidence. The reviewer's conclusion that write authority is unsafe is an inference from missing protocol detail; the gateway-only authorization and unbounded retry findings are verified contradictions because the proposal states those behaviors directly.

## Adversarial Pass

A second pass asks whether the review overemphasizes correctness and security. It does not change the result: workload fit, recovery, delivery, regional authority, and lifecycle evidence are independently inadequate, and critical blockers remain regardless of prioritization. No numeric summary is useful because it would add no decision information and could obscure the non-compensable failures.

## Smallest Approval Conditions

- Define exact monetary representation and atomic order invariants.
- Use transactional outbox/CDC or an explicit idempotent workflow with reconciliation.
- Bound queue capacity, attempts, deadlines, concurrency, and backlog behavior.
- Enforce actor, tenant, resource, and action authorization server-side.
- Select one write-authority model and define routing, fencing, conflict, failover, failback, and reconciliation.
- Supply representative restore, migration, release, workload, and failure evidence.
- Add an owned Complexity Ledger entry with reversal, lifetime, and validation triggers.

# Post-Incident Structural Review Example

This fictional example shows how to separate an initiating error from the architecture that amplified it.

## Incident and Evidence

A production credential rotation placed new storage credentials in staging and removed the old production credential. For 38 minutes, all writes and 31% of reads failed. Evidence includes the change record, secret-manager audit log, dependency traces, alert timeline, and operator transcript.

## Causal Chain

| Link | Finding | Evidence state |
|---|---|---|
| Architecture decision | one shared object store and credential set served upload, configuration, and asset paths | implemented: deployment/configuration and dependency map |
| Hidden dependency | authentication and static asset delivery indirectly depended on the same credentialed path | observed: traces during incident; absent from architecture diagram |
| Initiating trigger | old production credential was removed after the replacement was written to staging | observed: audit log |
| Propagation | clients retried writes while unrelated critical paths lost shared storage access | observed: retry and dependency metrics |
| Blast radius | all writes and 31% of reads failed across three products | observed: journey SLIs |
| Detection | availability alerts fired after seven minutes; no semantic rotation check existed | observed: alert timeline and missing control |
| Recovery constraints | rollback required manual environment identification; retries added load after restoration | observed: operator transcript and queue metrics |
| Structural correction | environment-bound credential automation, staged synthetic validation, bounded retries, dependency isolation, and tested rollback | designed: owner and tests assigned; not yet validated |

## Trigger Versus Enabling Conditions

The deletion was the trigger. Enabling conditions were environment ambiguity, manual rotation, shared critical-path concentration, missing semantic validation, unbounded retry amplification, and an untested rollback path. Replacing or retraining the operator would leave these conditions available to another trigger.

## Five-Gate Findings

- **A — Problem and fitness:** the rotation's required availability and acceptable blast radius were never defined.
- **B — State and boundaries:** a shared dependency crossed product boundaries without explicit ownership or isolation.
- **C — Failure and assurance:** failure propagation and retry load were not tested; the trigger and blast radius are now observed.
- **D — Delivery and operation:** configuration lacked code-equivalent staging, validation, and rollback controls.
- **E — Economics, complexity, and evolution:** no Complexity Ledger recorded the shared dependency, operational duty, reversal path, or validation trigger.

## Verdict and Conditions

**Verdict: BLOCK repeated rotation until conditions are validated.** This is not a general release block for unrelated changes.

1. Platform owner automates environment-bound rotation and proves staged synthetic read/write checks.
2. Product owners remove authentication and static assets from the shared failure path or prove bounded degradation.
3. Reliability owner caps retry attempts and concurrency, then demonstrates recovery without load amplification.
4. Operations owner rehearses rollback and records time to detect, mitigate, recover, and understand.
5. Architecture owner creates a Complexity Ledger entry with expected lifetime, cost, reversibility, review date, and recurrence trigger.

## Governed Metrics

| Metric | Definition/unit | Intended decision | Confounders/gaming | Owner | Retirement |
|---|---|---|---|---|---|
| Rotation validation coverage | production credentialed paths passing synthetic read/write checks / all critical paths, percent per rotation | allow promotion to revoke-old phase | stale inventory or tests that bypass actual policy | platform security | review quarterly; retire when mechanism changes |
| Shared-dependency blast radius | affected critical journeys / mapped critical journeys, percent per exercise | prioritize isolation work | incomplete journey map or synthetic-only exercises | reliability | review after each topology change |

These metrics evaluate controls and system trends. They must not rank the operator or any individual engineer.

# Architecture Proposal

Use microservices, Kafka, Redis, and MongoDB because they scale. Store prices as floating point. The API writes to the database and then publishes to Kafka. Retries continue until success. The queue is unlimited. Redis is the source of truth. Exactly-once delivery is guaranteed. Internal services trust each other. Backups run every night. Use active-active multi-region writes. Authorization is handled by the frontend and gateway. Deploy directly when coding is finished.

# Architecture Specification

## Decision Summary

Use a modular monolith with PostgreSQL, Redis as a non-authoritative cache, and an outbox-backed event stream. The decision is reversible and reviewed at ten times current peak load.

## Scope and Evidence

Actors, tenants, critical journeys, system boundary, constraints, owners, and non-goals are explicit. Observed facts are separated from assumptions. Each unknown has an owner and validation experiment.

## Requirements, Workload, and Invariants

P99 write latency is 300 ms, availability is 99.95%, RTO is 30 minutes, and RPO is 5 minutes. Peak load is 2,000 requests per second, 500 writes per second, and 20,000 concurrent sessions. Money uses integer minor units. Inventory cannot become negative. Tenant data cannot cross boundaries.

## Options and Ownership

The proposal compares a modular monolith, microservices, and serverless functions across correctness, ownership, latency, blast radius, operability, migration, and cost. Order, payment, inventory, identity, and notification modules own their data and contracts. Server-side authorization is enforced at each boundary.

## Data and Workflows

PostgreSQL is authoritative. Transactions enforce order and inventory invariants. Optimistic concurrency uses version columns. Redis has TTL, invalidation, stampede protection, and safe miss behavior. Database and broker writes use a transactional outbox and idempotent consumers. API and event contracts define validation, authorization, errors, deadlines, quotas, versioning, delivery, ordering, replay, and dead-letter handling.

## Failure, Recovery, and Operations

Remote calls have deadlines and bounded retries with backoff, jitter, retry budgets, and degraded behavior. Queues and concurrency are bounded. The failure matrix covers infrastructure, dependency, data-corruption, deployment, and operator failures. SLOs, telemetry, ownership, runbooks, restore drills, game days, canaries, compatibility windows, reconciliation, rollback, and roll-forward are defined with validation owners.

## Security and Cost

The threat model covers identity, least privilege, tenant authorization, encryption, secrets, audit, SSRF, injection, dependency trust, privacy lifecycle, abuse, and incident response. Unit cost and dominant compute, storage, egress, queue, and observability costs are modeled across growth scenarios.

# Contextual Architecture Evidence Vector

Use this reference after establishing the review contract and reconstructing the architecture. Build a decision-specific evidence vector instead of applying universal categories, weights, or release thresholds.

## Contents

- Non-Negotiable Rule
- 1. Freeze the Review Frame Before Judging
- 2. Use the Five Gates
- 3. Define Each Dimension
- 4. Assess Evidence Dimension by Dimension
- 5. Inspect the Complexity Ledger
- 6. Challenge the First Pass
- 7. Decide Without Fake Precision
- 8. Report Provenance

## Non-Negotiable Rule

The vector makes trade-offs and evidence maturity visible. Strong evidence in one dimension cannot compensate for a critical blocker or a failed required condition in another. A scalar, when justified at all, is supplementary and never approval-bearing.

## 1. Freeze the Review Frame Before Judging

Derive the frame from:

- the decision being gated and its accountable owner;
- critical user and operator journeys;
- measurable requirements, invariants, constraints, and unacceptable failures;
- state classes, tenancy, data sensitivity, and trust boundaries;
- workload, dependency, cost, and organizational assumptions;
- failure impact, reversibility, blast radius, and uncertainty;
- current, target, and transition states; and
- the maturity horizon: exploration, implementation, migration, or production release.

Do not reshape dimensions or decision conditions after seeing a weak result. If new evidence reveals an omitted requirement, version the frame and explain the change.

## 2. Use the Five Gates

Select dimensions within these gates. Merge, split, or exclude dimensions only with a stated reason.

| Gate | Review question | Required artifact | Decision test |
|---|---|---|---|
| A — Problem and fitness | What problem, stakeholder, measurable requirement, and constraint justify this design? | prioritized requirements and quality-attribute scenarios | success and unacceptable failure are decidable |
| B — State and boundaries | What is authoritative, derived, ephemeral, sensitive, rebuildable, and independently governed? | context, component, data, interaction, and ownership models | every boundary buys a named capability and state semantics are explicit |
| C — Failure and assurance | What can fail, duplicate, reorder, become ambiguous, or be compromised, and what proves recovery? | failure analysis, threat model, tests, and recovery plan | behavior is explainable for slow, unavailable, duplicated, or compromised dependencies |
| D — Delivery and operation | How are code, schema, configuration, infrastructure, capacity, and recovery operated safely? | rollout, observability, capacity, ownership, and readiness plans | the system can be deployed, diagnosed, and restored without its original authors |
| E — Economics, complexity, and evolution | Does capability gained justify lifecycle obligations under uncertainty? | ADR/RFC, Complexity Ledger, cost/reversal analysis, validation trigger | the decision is affordable, reversible enough, owned, and revisable from observed evidence |

## 3. Define Each Dimension

For every applicable dimension, record:

| Field | Required content |
|---|---|
| Dimension | decision-specific concern |
| Gate | A, B, C, D, or E |
| Why applicable | requirement, invariant, risk, or constraint |
| Protected condition | outcome that must remain true |
| Full-evidence anchor | evidence sufficient for this decision horizon |
| Partial-evidence anchor | useful but incomplete evidence |
| Failure anchor | contradiction, unsafe behavior, or unacceptable uncertainty |
| Required maturity | minimum evidence state for the decision |
| Evidence expected | artifact, measurement, test, configuration, runbook, or owner |

List exclusions and explain why they do not affect this decision. Do not reward irrelevant completeness.

## 4. Assess Evidence Dimension by Dimension

Use these states consistently:

- **Observed:** representative production measurement, drill, or incident evidence.
- **Validated:** integration, load, security, migration, restore, or failover evidence in a relevant environment.
- **Implemented:** inspectable code, configuration, schema, policy, contract, or test.
- **Designed:** documented mechanism, owner, and validation path.
- **Claimed:** assertion without supporting evidence.
- **Inferred:** reviewer conclusion derived from incomplete evidence.
- **Contradicted:** supplied evidence conflicts with the claim.
- **Missing:** required evidence was not supplied.

For each dimension, cite the evidence, classify its state and quality, explain the finding, name uncertainty and counter-evidence, and identify the smallest proof or change needed. Keep evidence quality separate from blocker status: strong evidence can prove a blocker, while weak evidence can create an evidence gap without proving a defect.

## 5. Inspect the Complexity Ledger

Require an explicit ledger for high-impact decisions. Record its absence rather than silently reconstructing one. Check:

- decision, requirement, capability gained, and alternatives;
- introduced concepts, states, protocols, configurations, and dependencies;
- operational responsibility and new failure modes;
- knowledge requirement and ownership concentration;
- security, performance, and cost effects;
- reversibility and migration path;
- expected lifetime or deletion date;
- evidence and assumptions;
- validation trigger, owner, and review date.

The ledger is qualitative and prospective. Do not assign universal complexity points or add incomparable obligations into a synthetic total.

## 6. Challenge the First Pass

Run a separate adversarial pass:

- Which requirement, stakeholder, state, dependency, or transition was omitted?
- Did a technology name substitute for outcome evidence?
- Did one control receive credit in multiple dimensions?
- Did absence become an assumed control or a proven defect?
- Did the review hide a high-consequence weak dimension behind broad strengths?
- Is a shared dependency or correlated failure domain missing?
- Would counter-evidence or a different operating context reverse the conclusion?
- Does an independent critical pattern force a block?

For consequential decisions, use an independent reviewer with the same frozen contract and evidence. Compare dimension selection, blocker recall, evidence classification, verdict, and approval conditions. Resolve disagreement through evidence or accountable human judgment.

## 7. Decide Without Fake Precision

- **PASS:** no blocker; every required condition meets its evidence maturity; residual risks are owned.
- **CONDITIONAL:** no blocker; bounded evidence or remediation conditions remain with owner, proof, and review trigger.
- **BLOCK:** a critical blocker exists or a required condition fails.
- **INSUFFICIENT EVIDENCE:** the frame or decisive evidence is too incomplete for a responsible verdict.

Report the vector, blockers, verdict, confidence, and evidence limits separately.

If stakeholders need a numeric summary, first state its decision purpose. Publish its dimensions, mapping, assumptions, and sensitivity to plausible alternatives. Do not require weights to total 100, present a universal pass threshold, average away blockers, rank unrelated architectures by one number, or use the number as the verdict.

## 8. Report Provenance

Distinguish:

- source claims from reviewer inference;
- verified facts from unvalidated claims;
- supporting evidence from counter-evidence;
- evidence absence from evidence contradiction; and
- model/reviewer identity and confidence limits.

Honest uncertainty is more useful than fabricated precision.

# Critical Failure Patterns

## Correctness

### Floating-point money

Binary floating point cannot safely represent many decimal values. Use integer minor units or fixed-precision decimal with currency, scale, rounding, and overflow rules.

### Missing enforcement point

A stated invariant is not a control. Identify the exact transaction, constraint, conditional write, lock/version check, ledger rule, or single-writer boundary that enforces it under concurrency.

### Unsafe dual write

Writing the database and broker independently creates ambiguous partial success. Use a transactional outbox/CDC, idempotent state machine with reconciliation, or a justified distributed transaction.

### Exactly-once handwave

Broker delivery does not prove end-to-end effect exactly once. Define boundary, deduplication identity/lifetime, transaction, replay, consumer crash behavior, and proof.

## Boundedness

### Infinite retry or unlimited queue

Retries amplify outages; queues convert overload into delayed failure. Require maximum attempts/deadline, retry budget, capacity, admission, backpressure, expiry, DLQ/quarantine, and user behavior.

### Unbounded fan-out or concurrency

Calculate worst-case amplification and cap it per request, tenant, dependency, and process. Include cancellation and partial-result policy.

## Authority and isolation

### Cache as authority

A cache can be lost, stale, evicted, or partitioned. If it holds authority, the design must explicitly provide durability, consensus/transaction semantics, backup, recovery, and audit; otherwise make it derived.

### Gateway-only authorization

A gateway authenticates and filters broad access, but downstream services and data boundaries still enforce actor, tenant, resource, and action authorization.

### Internal equals trusted

Use workload identity, least privilege, authenticated/encrypted transport where required, scoped credentials, and service-side authorization. Network placement is context, not authority.

## Multi-region

Active-active writes require conflict semantics, ownership/routing, fencing, replication lag behavior, split-brain handling, failback, residency, and reconciliation. Without them, failover can produce divergent authority.

## Recovery

Backups without restore evidence are inventory, not recovery. Require retention/isolation, corruption scenario, access, restore steps, RTO/RPO measurement, dependency order, and reconciliation after recovery.

## Delivery

Irreversible schema/data changes need expand-migrate-contract, compatibility windows, backfill/reconciliation, cutover gates, and rollback or roll-forward. “Deploy directly” is not a release strategy.

## AI and agents

Block high-impact tool use when the model can choose arbitrary authority, arguments are untyped, prompt text is the only guardrail, memory crosses users/tenants, delegation is unbounded, eval gates are editable by the candidate, or no approval/audit/kill switch exists.

# Evidence and Challenge Guide

## Claim-Centric Evidence Record

Treat the unit of review as an atomic claim, not a bookmark or document. For every material external claim, record:

| Field | Required content |
|---|---|
| Claim ID and claim | One proposition the source directly supports |
| Source ID and stable citation | DOI, standard number, durable URL, or versioned artifact |
| Provenance | title, authors, year, and organization |
| Source type | theory, experiment, system paper, standard, incident, book, case study, vendor documentation, or local artifact |
| Study design | proof, controlled experiment, survey, observation, benchmark, case report, or engineering record |
| Scale and context | sample/system size, workload, organization, technology, and preconditions |
| Evidence | data, proof, trace, test, configuration, or argument supplied |
| Counter-evidence | contradictory sources, observations, or failed replication |
| Threats to validity | selection, confounding, measurement, publication, recency, and scale limits |
| Confidence | high, medium, low, or contested, with reason |
| Architecture implication | reviewer interpretation kept separate from the source claim |

Never turn a source's correlation into causation, local result into universal rule, or vendor capability into configured runtime behavior. Quote and paraphrase accurately within applicable copyright limits.

## Evidence Hierarchy

Prefer stronger evidence when available:

1. reproducible tests, measurements, traces, restore/failover results;
2. deployed configuration, schemas, contracts, policy, and code paths;
3. versioned architecture decisions and runbooks aligned with implementation;
4. incident reports and operational records;
5. owner statement or vendor documentation;
6. reviewer inference;
7. unsupported assertion.

Label the evidence class in material findings.

Evidence rank does not erase relevance or validity limits. A reproducible benchmark on an unlike workload may be weaker for the decision than a directly relevant incident record.

## High-value challenges

| Claim | Ask for |
|---|---|
| “Scales to 100k RPS” | workload shape, bottleneck model, test method, saturation point, dependency quotas |
| “Highly available” | journey SLO, topology, quorum/client behavior, failover test, degraded mode |
| “Zero data loss” | durability boundary, acknowledged-write semantics, RPO, corruption and restore evidence |
| “Exactly once” | precise boundary, transaction/deduplication proof, crash/replay behavior |
| “Secure” | threat model, identity/authz, tenant tests, secret/key lifecycle, incident evidence |
| “Multi-region” | write authority, routing, conflict, fencing, lag, failover/failback, residency |
| “Backed up” | restore drill, timing, permissions, dependencies, reconciliation |
| “Can roll back” | version compatibility, data effects, command/runbook, tested outcome |
| “AI is accurate” | task dataset, baseline, metrics, severe slices, repeated runs, online monitoring |
| “Agent is safe” | tool scopes, policy enforcement, approval, sandbox, injection eval, kill switch |

## Finding anatomy

Each material finding contains:

- **Claim/control reviewed**
- **Evidence** and location
- **Failure mechanism**
- **Impact and affected journey/data**
- **Severity and confidence**
- **Smallest approval condition**
- **Owner and proof method**
- **Source claim versus reviewer inference**
- **Counter-evidence and validity limits**

## Avoid false precision

Use ranges and confidence when evidence is incomplete. A quantified estimate with explicit assumptions is better than a precise number with hidden assumptions. Do not convert missing evidence into a factual defect; report the gap and why it matters.

## Closure evidence

A finding closes only when fresh evidence demonstrates the required postcondition. A code diff, agent report, or design promise is insufficient when the finding concerns runtime behavior, recovery, concurrency, migration, security, or performance.

## Source Challenge Sequence

For each consequential claim:

1. Restate the smallest claim actually supported.
2. Classify source type and study design.
3. Check sample/system scale and whether the reviewed context matches.
4. Search supplied material for counter-evidence and disagreements.
5. Name threats to validity and missing replication.
6. Separate the source claim from the reviewer's architecture implication.
7. Assign confidence and the next evidence that could change it.
8. Preserve a stable citation and artifact version so the challenge is reproducible.

# Evidence-Vector Calibration Guide

Use this dimension library to preserve broad production coverage without imposing fixed categories, weights, point allocations, or universal pass thresholds. Start from the five-gate review contract in `references/01-contextual-ai-review-rubric.md`, not from this list.

## Calibration Method

1. Select, merge, split, or rename dimensions to match the decision.
2. Tie every dimension to a requirement, invariant, risk, constraint, or obligation.
3. Define evidence anchors and required maturity before assessment.
4. Explain exclusions and avoid double counting.
5. Keep the resulting vector visible; do not collapse it into a mandatory score.

## Possible Dimensions

### Gate A — Problem and fitness

Consider stakeholders, critical journeys, non-goals, decision horizon, measurable quality scenarios, current-state evidence, assumptions, workload ranges, bursts, skew, growth, dependency limits, legal constraints, and specialist handoffs.

### Gate B — State and boundaries

Consider authoritative, derived, ephemeral, sensitive, and rebuildable state; invariants; state machines; transactions; concurrency; sources of truth; ownership; consistency; ordering; idempotency; unknown outcomes; data lifecycle; component and trust boundaries; communication semantics; and whether every boundary purchases independent change, scale, failure, governance, or security capability.

### Gate C — Failure and assurance

Consider partial failure, timeout and retry coherence, duplicate and delayed work, overload, bulkheads, degraded modes, shared dependencies, correlated failure, recovery load, reconciliation, RTO/RPO, restore/failover evidence, threat model, identity, authorization, tenant isolation, secrets, abuse, privacy, and logic/integration/concurrency/load/recovery/adversarial tests.

### Gate D — Delivery and operation

Consider telemetry linked to user outcomes, workflows, data, dependencies, cost, and owners; impact-based alerts; runbooks; on-call; capacity envelope and next bottleneck; compatible API/event/schema/configuration evolution; progressive rollout; canary and stop conditions; rollback/roll-forward; migration, backfill, reconciliation, cleanup; dependency upgrades; and restore drills.

### Gate E — Economics, complexity, and evolution

Consider development, infrastructure, licensing, support, incident, coordination, and migration cost; code, dependency, state, distribution, operations, configuration, security, and organizational complexity; knowledge concentration; capability gained; alternative simplicity; reversibility; compatibility and exit path; expected lifetime; temporary-path deletion; validation triggers; and owner/review date.

### AI and agent dimensions

When applicable, consider task suitability, baseline alternatives, model/prompt/index provenance, retrieval authorization, memory scope, typed outputs, tool identity and least privilege, policy outside the model, human approval, sandboxing, audit, budgets, termination, evaluation, fallback, prompt injection, data exfiltration, and kill switches. Keep these within the five gates rather than treating “AI” as an automatically compensating category.

## Calibration Questions

- What failure would make approval irresponsible?
- Which dimensions protect the most important invariant or journey?
- Which uncertainties could reverse the recommendation?
- Is transition-state risk visible, or only target-state quality?
- Does evidence maturity match the decision horizon?
- Is missing evidence distinguished from a proven defect?
- Would the same frame be fair to a simpler competing design?
- Is the Complexity Ledger present and complete enough to reveal lifecycle obligations?
- Is any metric being mistaken for the outcome it only approximates?

## Optional Numeric Summaries

Use a number only for a named decision where stakeholders can explain how it helps. Require:

- explicit mapping from evidence states to values;
- transparent assumptions and uncertainty;
- sensitivity to plausible alternative mappings or priorities;
- no universal threshold or normalized-weight requirement;
- blockers and required conditions evaluated separately; and
- the full vector presented beside the number.

Omit the number when dimensions are incomparable, evidence is sparse, or the summary would obscure a weak critical dimension.

## Multi-Reviewer Calibration

Give reviewers the same frozen contract and evidence, but not each other's conclusions. Compare:

- selected and excluded dimensions;
- blocker recall;
- evidence state and quality;
- complexity obligations;
- source claims versus reviewer inference;
- verdict and confidence; and
- approval conditions.

Do not average away disagreement. Resolve it with better evidence or an accountable decision owner.

# Fitness Gates, Incident Causality, and Metric Governance

Use this reference for production gates, post-incident structural reviews, and architecture fitness metrics. It adapts Sections 23.3, 27, 29–35 and Appendices B, C, and E of the supplied research paper into reviewer behavior.

## Contents

- Five-Gate Review
- Complexity Ledger Review
- Post-Incident Structural Review
- Metric Governance
- Review Completion Check

## Five-Gate Review

Run the gates in order because later evidence depends on earlier meaning. Do not give each gate an automatic weight or average a failed condition into unrelated strengths.

### Gate A — Problem and Fitness

Require problem, stakeholders, measurable behavior, constraints, quality scenarios, and unacceptable failure. Ask whether a reviewer can tell what success means without referring to technology brands.

### Gate B — State and Boundaries

Require the simplest viable option, state classification, invariants, ownership, communication semantics, consistency, and a named capability for every boundary. Ask whether authoritative and derived state, transaction scope, time, ordering, duplication, cancellation, and unknown outcomes are explicit.

### Gate C — Failure and Assurance

Require failure analysis, detection, recovery, threat model, privilege model, and tests aligned to logic, integration, concurrency, load, recovery, and adversarial input. Ask what happens when each dependency is slow, unavailable, duplicated, reordered, or compromised.

### Gate D — Delivery and Operation

Require compatible change for code, schema, configuration, and infrastructure; observable user outcomes and workflows; bounded capacity; owner/on-call/runbooks; backup restore; and rollback or forward repair. Ask whether a capable operator can deploy, diagnose, and restore the system without its original authors.

### Gate E — Economics, Complexity, and Evolution

Require total lifecycle cost, a Complexity Ledger entry, compatibility and migration paths, reversibility, expected lifetime, owner, review date, and evidence-based validation trigger. Ask whether the measurable capability gained justifies all introduced obligations under uncertainty.

## Complexity Ledger Review

Inspect every field rather than accepting “complexity considered”:

| Area | Reviewer question |
|---|---|
| Decision and requirement | What mechanism changes, and which measurable requirement necessitates it? |
| Capability and alternatives | What becomes materially better, and what simpler options were considered? |
| Introduced complexity | Which concepts, states, protocols, configurations, and dependencies now exist? |
| Operational responsibility | What must be deployed, monitored, patched, backed up, restored, and retired? |
| Failure modes | What can fail now that could not fail before, including correlated failure and recovery load? |
| Knowledge | Which skills must be acquired and retained, and where is knowledge concentrated? |
| Security | What privileges, attack surfaces, data movement, identities, or trust boundaries are added? |
| Performance | What changes in latency, throughput, memory, storage, network, and capacity limits? |
| Cost | What build, runtime, license, support, incident, coordination, and migration costs arise? |
| Reversibility | What exit path, data portability, compatibility, and migration difficulty exist? |
| Lifetime | Is the mechanism transitional, tactical, or strategic; when is temporary machinery deleted? |
| Evidence and trigger | Which measurements, experiments, sources, assumptions, and observations could reverse the decision? |
| Accountability | Who reviews the decision, and when? |

Reject invented universal complexity points. Compare vectors and changes over time. A mechanism may reduce code complexity while increasing state, distribution, operational, configuration, security, or organizational complexity.

## Post-Incident Structural Review

Build this chain from evidence:

`architecture decision → hidden dependency → initiating trigger → propagation mechanism → blast radius → detection → recovery constraints → structural corrective action`

For every link, cite an incident timestamp, trace, change record, configuration, dependency map, runbook action, or explicit inference.

### Separate trigger from enabling conditions

- **Trigger:** the event that initiated the incident, such as a credential deletion, deployment, dependency failure, load spike, or operator command.
- **Enabling conditions:** architectural properties that allowed propagation or delayed containment, such as shared critical dependencies, weak configuration controls, retry amplification, incomplete isolation, accumulated state, absent semantic detection, insufficient rollback, or recovery that added load.

Correct the enabling conditions. Training, replacing a person, or reverting one command does not prevent a different trigger from exploiting the same structure.

### Structural questions

- Which prior decision created or accepted the dependency?
- Why was the dependency hidden from topology, telemetry, ownership, or recovery plans?
- Which isolation boundary failed or never existed?
- How did retries, queues, caches, control planes, or recovery work amplify impact?
- Which user-visible or semantic signal detected the problem, and what was missed?
- What constrained rollback, failover, reconciliation, or restoration?
- Which correction changes dependency, isolation, rollout, boundedness, detection, or recovery semantics?
- What validation proves that correction, and what recurrence signal remains?

Do not force a single root cause when multiple enabling conditions interacted. Distinguish verified causal links from plausible contributors and unknowns.

## Metric Governance

Architecture metrics are diagnostic signals, not an architecture score. Prefer vectors and within-system trends interpreted alongside domain and organizational change.

For every metric record:

| Field | Required content |
|---|---|
| Name, definition, and unit | exact numerator/denominator, population, window, aggregation, and unit |
| Data source and quality | instrument, coverage, freshness, missingness, bias, and validation |
| Intended decision | specific action or question the metric informs |
| Known confounders | domain change, incident mix, staffing, seasonality, migration, instrumentation change |
| Gaming risk | behavior that improves the number while degrading the system |
| Owner | accountable interpreter and maintainer |
| Review and retirement | review cadence, invalidation trigger, and removal date/condition |

Use multiple signal families where relevant:

- **Structural:** dependency cycles/depth, fan-in/fan-out, propagation cost, change coupling, ownership fragmentation, smell trends.
- **Delivery:** lead time, deployment frequency, deployment rework/change failure, recovery time, reliability.
- **Developer experience:** satisfaction, build/test time, onboarding, interruption, cognitive load, and ease of debugging.
- **Operational/economic:** SLO and error-budget state, incident severity/blast radius/recurrence, detection/mitigation/recovery/understanding time, restore success, queue age, replication lag, capacity headroom, unit cost, platform toil, and temporary compatibility-path age.

Never rank individual engineers with architecture, delivery, or developer-experience metrics. Do not turn a proxy into a quota. Retire a metric when its definition, boundary, decision use, or validity no longer holds.

## Review Completion Check

A formal review is complete only when:

- all applicable gates expose their evidence state and failed conditions;
- blockers remain separate and non-compensable;
- the Complexity Ledger is inspected or its absence is reported;
- source claims are distinguishable from reviewer inference;
- incident reviews identify enabling conditions and structural proof;
- metrics have governance metadata and no individual-ranking use; and
- every approval condition has an owner, proof, and review trigger.

---
name: architecture-review-gate
description: "Use when independently reviewing or verifying an architecture specification, RFC, ADR, diagram, migration plan, AI or agent design, production-readiness proposal, architecture metrics, or post-incident structural causes. May frame review criteria or recommend bounded remediation, but does not own greenfield design or repository changes."
---

# Review Software Architecture

## Overview

Perform an independent, adversarial architecture review. Reconstruct the system from evidence, challenge the riskiest decisions, distinguish missing evidence from actual defects, and block approval when a critical invariant, security boundary, recovery path, or operational control is absent.

**Core principle:** Review architecture as an evidence-backed vector of qualities and obligations. No scalar summary can waive a critical failure.

```text
NO APPROVAL WITHOUT FRESH EVIDENCE THAT:
- requirements and assumptions are explicit;
- critical invariants have enforcement points;
- resources and retries are bounded;
- failure and recovery are designed and rehearsable;
- security and tenant boundaries are enforced end to end;
- delivery, rollback, ownership, and validation are real.
```

## When to Use

Use this skill for:

- architecture RFC and ADR review;
- production-readiness and launch gates;
- design due diligence;
- monolith, microservice, event-driven, or multi-region proposals;
- data, API, queue, cache, migration, and disaster-recovery review;
- AI/agent architecture review;
- post-incident structural review;
- architecture fitness-function and metric review;
- comparison of current and target architecture.

The review is independent. Do not rewrite the architecture or make repository changes unless the user explicitly changes the task.

## Select the Operating Mode

| Mode | Use when | Required result |
|---|---|---|
| **Think** | The independent review contract or rubric must be framed before assessment | decision being gated, frozen dimensions, evidence anchors, and blocker policy |
| **Review** | An architecture artifact or repository is ready for the default independent assessment | evidence-separated findings, blockers, confidence, and approval conditions |
| **Change** | The user explicitly requests remediation after the independent verdict | bounded recommendations or a handoff to the owning design/domain skill; no silent self-rewrite |
| **Verify** | A finding or approval condition is claimed resolved | fresh evidence, reassessment, and residual risks |

If the user names a mode, use it. Otherwise default to Review for an existing artifact and state the inference in one sentence. Combined work proceeds **Think → Review → Change → Verify**, but the independent verdict remains distinguishable from authoring and remediation. Think may stop with the review contract; Review may stop with findings. Change must not claim completion before Verify, and Verify must never convert missing evidence into a pass.

## Reviewer Independence

1. Read the requirement and evidence before the author’s conclusion when possible.
2. Reconstruct critical flows and invariants independently.
3. Treat diagrams, claims, benchmarks, and agent reports as untrusted until corroborated.
4. Separate:
   - **defect** — design violates a requirement or safety/correctness rule;
   - **evidence gap** — claim may be valid but is not demonstrated;
   - **risk** — uncertain future harm requiring owner and mitigation;
   - **preference** — stylistic alternative with no material outcome difference.
5. Do not reward complexity, technology prestige, or document length.

## Required Context Loading

- Use [contextual architecture evidence vector](references/01-contextual-ai-review-rubric.md) for every formal gate.
- Use [critical failure patterns](references/02-critical-failure-patterns.md) for blocker review.
- Use [evidence and challenge guide](references/03-evidence-challenge-guide.md) for claim verification.
- Use [rubric calibration guide](references/04-rubric-calibration-guide.md) when selecting dimensions, evidence anchors, decision conditions, or multi-model review.
- Use [fitness gates, incident causality, and metric governance](references/05-fitness-gates-incidents-and-metrics.md) for formal gates, post-incident review, or architecture metrics.
- Use [strong review input](examples/review-input-strong.md) and [critical review input](examples/review-input-critical.md) to calibrate the evidence expected before judging a proposal.

## Review Workflow

Apply the phases according to mode: Think freezes the review contract before assessment; Review produces the independent verdict; Change occurs only after explicit user authorization and is recorded separately from the verdict; Verify re-runs the evidence gate and marks every unavailable check as missing evidence.

### Phase 0 — Establish Review Contract

Record:

- review mode and decision being gated;
- business owner and technical owner;
- required launch date or decision horizon;
- evidence supplied and evidence unavailable;
- critical journeys, data classes, tenants, and failure impact;
- applicable compliance or specialist review boundaries.

Do not infer approval criteria from the proposed technology.

### Phase 1 — Reconstruct the Design

Create a compact model of:

- actors, system boundary, external dependencies, and trust boundaries;
- runtime components, protocols, data ownership, and deployment topology;
- critical synchronous and asynchronous paths;
- authoritative stores, caches, replicas, indexes, and event logs;
- operational owners and control plane;
- current state, target state, and transition state for migrations.

When the document and implementation disagree, report both and identify the effective behavior.

### Phase 2 — Trace Requirements to Decisions

For each architecturally significant requirement, identify:

- motivating requirement, invariant, risk, or constraint;
- selected decision and realistic alternative;
- trade-off and consequence;
- measurement or validation method;
- reversal or review trigger.

A decision with no traceable motivation is unsupported. A requirement with no decision or control is uncovered.

Organize the trace through five gates without treating them as equally weighted categories:

- **A — Problem and fitness:** measurable requirements, constraints, stakeholders, and unacceptable failure;
- **B — State and boundaries:** authority, invariants, communication semantics, and the capability purchased by each boundary;
- **C — Failure and assurance:** partial failure, detection, recovery, security, and test evidence;
- **D — Delivery and operation:** safe change, observability, capacity, ownership, and restore ability;
- **E — Economics, complexity, and evolution:** lifecycle cost, obligations, reversibility, lifetime, and revision triggers.

Report each gate's evidence state and decision test. Do not average a failed gate into stronger evidence elsewhere.

### Phase 3 — Challenge Correctness and Data Semantics

Inspect:

- business invariants and their atomic enforcement;
- state machines and legal transitions;
- source of truth and ownership for every critical entity;
- transaction and consistency boundaries;
- concurrent updates, conflicts, idempotency, deduplication, and ordering;
- duplicate, delayed, out-of-order, and lost messages;
- ledger, reconciliation, repair, and audit for money/inventory/quota/entitlement;
- schema, key, index, partition, retention, deletion, backup, and restore semantics.

A workflow diagram without failure and repair behavior is incomplete.

### Phase 4 — Challenge Distribution and Scale

Demand evidence for:

- service boundaries and independent ownership/deployment needs;
- capacity estimates with peak, burst, skew, growth, and sensitivity;
- latency budget and tail behavior;
- partition keys, resharding, hot keys, noisy neighbors, and celebrity tenants;
- queue bounds, backlog drain, consumer capacity, DLQ, and replay;
- connection, thread, memory, disk, file-descriptor, and dependency quotas;
- admission control, backpressure, load shedding, and degraded modes;
- retry amplification and timeout propagation.

Autoscaling and orchestration do not substitute for bounded overload behavior.

### Phase 5 — Challenge Failure and Recovery

Walk these failures where relevant:

- process, node, zone, region, network partition;
- database, broker, cache, DNS, certificate, identity provider, and external API;
- bad deploy, incompatible schema, configuration error, secret rotation;
- data corruption, operator error, backlog, quota exhaustion, and cost spike.

For each, require detection, containment, user impact, degraded behavior, recovery, reconciliation, owner, RTO, RPO, and proof method.

Replication is not backup. Backup is not recovery evidence. Multi-zone is not regional disaster recovery.

### Phase 6 — Challenge Security, Privacy, and Abuse

Inspect identity and authorization at every service and data boundary, not only UI or gateway. Verify tenant propagation and isolation in APIs, caches, queues, jobs, search, object storage, logs, analytics, backups, and support tooling.

Review secrets, encryption and key lifecycle, input/output validation, SSRF, injection, file upload, dependency trust, audit, data minimization, retention, deletion, residency, rate limiting, abuse, fraud, incident response, and privileged operator paths.

For AI systems, also review prompt injection, tool authority, memory scope, data exfiltration, eval integrity, budgets, approval, traces, and kill switches.

### Phase 7 — Challenge Delivery and Operations

Verify:

- SLIs/SLOs and error-budget actions tied to user journeys;
- logs, metrics, traces, correlation, cardinality, retention, and privacy;
- alerts tied to impact, runbooks, escalation, and on-call ownership;
- compatible API/event/schema evolution;
- expand-migrate-contract, backfill, reconciliation, cutover, rollback, and roll-forward;
- progressive delivery, feature flags, canaries, and stop criteria;
- restore drills, game days, capacity tests, chaos tests, and migration rehearsals;
- cost drivers, unit economics, budgets, lock-in, and exit paths.

### Phase 8 — Assess the Evidence Vector and Decide

1. Read `references/01-contextual-ai-review-rubric.md` and derive decision-specific dimensions from the five gates, ASRs, invariants, failure impact, regulatory context, change scope, and supplied evidence.
2. Before assessing the proposal, publish and freeze each applicable dimension, why it matters, its evidence anchors, required evidence maturity, and the condition it protects. Explain exclusions.
3. For every dimension, cite evidence and classify it as observed, validated, implemented, designed, claimed, inferred, contradicted, or missing. Keep evidence quality separate from blocker status.
4. Inspect the proposal's Complexity Ledger. If none exists, report the absence. Review at least: decision, requirement, capability, alternatives, introduced concepts/state/protocol/configuration/dependencies, operational responsibility, failure modes, knowledge, security, performance, cost, reversibility, expected lifetime, evidence, validation trigger, owner, and review date.
5. Perform an adversarial second pass. Challenge omitted dimensions, hidden dependencies, duplicated credit, unsupported inference, technology favoritism, and whether stronger evidence changes the conclusion. This is a completed review pass, not a list of future adversarial tests: report what was challenged, what changed, and why the verdict did or did not move.
6. Review every applicable pattern in `references/02-critical-failure-patterns.md` independently. A critical blocker forces **BLOCK** regardless of strengths elsewhere.
7. Assign one verdict:
   - **PASS** — no blocker, every required decision condition is met, and evidence maturity is sufficient;
   - **CONDITIONAL** — no blocker, but named evidence or remediation conditions remain;
   - **BLOCK** — a critical blocker exists or a required decision condition fails;
   - **INSUFFICIENT EVIDENCE** — the review contract or decisive evidence is too incomplete for a responsible verdict.
8. State confidence, model identity/version when available, evidence limitations, and which conclusions are source claims, verified facts, reviewer inferences, or unvalidated claims.

Keep the dimension vector primary. A numeric summary is optional only when the decision owner has a defensible use for it, the derivation and assumptions are transparent, no universal threshold is implied, and sensitivity analysis shows what changes under plausible alternatives. It never determines approval.

### Phase 9 — Review Incidents and Metrics When Applicable

For a post-incident review, trace:

`decision → hidden dependency → trigger → propagation → blast radius → detection → recovery constraints → structural correction`

Separate the initiating trigger from the architectural enabling conditions. Do not substitute retraining or replacing the triggering person for structural correction.

For every architecture metric, require definition, unit, source, data quality, intended decision, confounders, gaming risk, owner, and review/retirement date. Use metric vectors and within-system trends; never use architecture metrics to rank individual engineers.

Perform this review through the active AI model and the supplied references.

## Critical Blockers

Block approval when any applicable condition is unresolved:

- money or balances use floating-point arithmetic;
- an invariant has no atomic enforcement point;
- database and broker are dual-written without atomic coordination or repair;
- a queue, retry loop, fan-out, cache, connection pool, or concurrency path is unbounded;
- cache or search index is accidental authority without durable recovery;
- exactly-once is claimed without a precise boundary and effect proof;
- active-active writes lack conflict, ownership/routing, and fencing semantics;
- internal network location substitutes for workload identity and authorization;
- tenant authorization exists only at UI/gateway;
- backups have no restore rehearsal and stated RTO/RPO;
- irreversible migration/deploy lacks compatibility window and rollback/roll-forward;
- consequential AI tools lack deterministic policy, scoped authority, approval, and audit;
- critical recovery, security, or load claims have no validation method.

## Severity Model

| Severity | Meaning | Release effect |
|---|---|---|
| **Critical** | likely data loss, invariant breach, cross-tenant access, unauthorized consequential action, unrecoverable outage, or invalid release claim | block |
| **High** | major user impact or operational failure with no adequate containment | block or explicit executive risk acceptance |
| **Medium** | material weakness with bounded workaround | condition with owner and date |
| **Low** | maintainability, clarity, or optimization opportunity | follow-up |

Prioritize by impact and exploitability/frequency, not count.

## Companion Skills and Standalone Safety

| Type | When | Companion | Missing companion behavior |
|---|---|---|---|
| **Handoff** | A general production architecture must be created or revised | `system-architecture-harness` | Finish the independent verdict without pretending the redesign was completed. |
| **Handoff** | An AI subsystem must be created or revised | `ai-agent-system-architecture` | Finish the independent verdict and identify missing AI design depth. |
| **Recommended** | Code-level release evidence must be assessed | `quality-release` | Classify the evidence gap and do not infer release readiness. |

If a companion is unavailable, complete the independent verdict from visible evidence, name the missing design or verification depth, and recommend the exact technical ID or `independent-architecture-review` installation group. Never claim unavailable material was read, invent evidence, or lower a blocker to compensate for missing depth.

## Output Contract

The selected mode is authoritative. Include only applicable fields below; a planned check is a validation path, not verification evidence.

Scale the output to the active mode: Think returns a frozen review contract; Review returns the independent verdict and findings; Change returns bounded remediation or an explicit owner-skill handoff; Verify returns fresh reassessment evidence. Keep those artifacts separate in a combined flow.

Produce sections in this order:

1. **Verdict, confidence, model disclosure, and decision being gated.**
2. **Architecture reconstruction** — concise current/target model.
3. **Five-gate evidence vector** — dimension, protected condition, evidence state, evidence quality, finding, and required proof.
4. **Critical blockers** — evidence, impact, failure scenario, required condition.
5. **High and medium findings** — ranked, deduplicated, actionable.
6. **Requirement-to-decision and Complexity Ledger gaps.**
7. **Invariant, data, workflow, scale, and overload findings.**
8. **Reliability, recovery, and post-incident causal findings.**
9. **Security, privacy, tenancy, and abuse findings.**
10. **Operations, delivery, migration, cost, and metric-governance findings.**
11. **Evidence reviewed, evidence challenged, and evidence missing.**
12. **Adversarial and sensitivity second-pass findings** — challenges run, result changes, and verdict sensitivity.
13. **Approval conditions** with owner, proof, and due/review trigger.
14. **Positive evidence** worth preserving.

Use [review report template](assets/architecture-review-report-template.md) for a file artifact. Use [post-incident review template](assets/post-incident-architecture-review-template.md) for an incident. Use [review checklist](assets/architecture-review-checklist.md) for a compact gate artifact. Read [the contextual review example](examples/contextual-review-example.md) or [post-incident structural review example](examples/post-incident-structural-review-example.md) when calibrating a first review.

## Stop Conditions

Stop and request/recover evidence rather than inventing it when:

- the reviewed artifact is unavailable or materially incomplete;
- diagrams omit labels, ownership, protocols, or trust boundaries needed for the decision;
- repository behavior cannot be reconciled with the architecture claim;
- workload, incident, restore, security, or migration evidence is referenced but not supplied;
- the reviewer would need legal, compliance, safety, or domain certification beyond architecture review;
- approval depends on a live test that has not been run;
- the author asks the reviewer to lower a gate instead of resolving the risk.

Do not stop merely because the design is complex. Report verified findings and explicit evidence gaps.

## Review Quality Rules

- Cite the exact evidence for every material finding.
- Explain the failure mechanism, not only the preferred pattern.
- Do not list generic best practices that do not affect this design.
- Merge repeated symptoms under the root architectural cause.
- State when a finding is an inference.
- Give the smallest sufficient approval condition; do not prescribe a rewrite reflexively.
- Verify fresh test, restore, load, migration, or policy evidence before claiming a blocker is resolved.