What does the incident history say?

Before we read the architecture, we read the incidents. A year of postmortems, sorted and counted, tells us where the system actually bends, which is frequently not where the diagram says it should. Diagrams record intent. Incidents record physics.

What do we count?

Four things, none sophisticated. Recurrence: which components appear in multiple incidents, because the second appearance is a pattern and the fourth is an architecture finding wearing an operations costume. Class: config change, dependency failure, capacity, code defect, because the distribution is a spending guide (a shop whose incidents are 60% config changes does not need a better test suite first). Detection source: monitoring, engineer, or customer, because "customer" as a leading detector prices the observability gap precisely. And time-to-mitigate versus time-to-understand, because a long gap between the two means the system is hard to reason about under stress, which is a design property, not a staffing one.

The public record shows how much a single document can carry: Roblox's 73-hour outage postmortem is a better lesson on coupling observability to the system being observed than any textbook chapter we could assign. Reading a company's own folder delivers that education about their own building.

What does an empty folder mean?

We are asked this often enough to answer it here. Systems with no incident history exist; a low-traffic brochure site, an enterprise architect portfolio, say, has nothing to review because there is nothing to fail. Everything else has history or has a reporting culture problem, and the distinction matters to a review: a year of silence over a system with real traffic usually means incidents are being handled informally, below the threshold of writing, which is where patterns go to stay invisible. In diligence settings we treat a suspiciously clean folder as a finding in itself.

What would have to be true for the folder to mislead?

Two conditions, both checkable. Survivorship: postmortems exist only for what was noticed, so the folder under-represents slow degradations and quiet data corruption; we compensate by also sampling support tickets, which catch what monitoring forgave. And blame distortion: in cultures where postmortems assign fault, the documents optimize for defensibility, and the narrative section becomes fiction with timestamps. The fix is old and well-documented in the SRE literature on blamelessness; until it lands, trust the timeline fields and discount the prose.

Our closing habit, transferable to any team: once a quarter, one engineer reads every incident from the last year in one sitting and presents the three patterns. It costs an afternoon. It is the cheapest architecture review that exists, and the system wrote most of it for you.