feedback_architecture_review_scope.md


1
2
3
4
5
6
7
8
9
10
11
12
13
14

---
name: feedback-architecture-review-scope
description: "When asked for an architectural review, keep it structural — don't lean on incident narrative as evidence or hook"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 2607e018-d4ad-4ec6-bb68-5f1d0f9a3906
---

When the user asks for an "architectural review," give structural analysis — how components relate, what the design trades off — not an incident post-mortem. Corrected 2026-08-07: a doot service-gateway review leaned on that day's outage (and an earlier 3-day incident) as the framing device and evidence for a "blast radius" argument; the user said "I'm not interested in an incident review, I believe I asked for an architectural review."

**Why:** Incidents are useful *inputs* the reviewer can reason from privately, but citing them as the review's evidence/narrative conflates "this specific bug happened" with "this is a structural property of the design" — and the user reads the two as different documents entirely.

**How to apply:** State structural costs/tradeoffs (e.g. "an in-process gateway means one process's failures take independent services down with it") as properties of the design, not as "here's what broke and when." If a past incident is genuinely relevant, it's fine to have privately informed the analysis — just don't put it in the document unless asked for a post-mortem specifically.