Interview. It is 03:00 and the engineer paged for a service you designed has never seen it before. Tell me what single page they need in front of them, what you deliberately leave off it, and how you know it is still true.

What the interviewer is testing

Whether you write documentation for a reader and a moment, or for completeness. Most architecture documentation fails not because it is wrong but because it answers a question nobody is asking at the time they read it. The 03:00 reader has one question: is this mine, and what may I do about it?

What goes on the page

Six things, fitting one screen:

1. What the service promises, in one line, with its target and the business consequence of breaking it. This tells the reader how hard to push and whether to wake anyone.
2. The dependencies, with direction and the timeout and retry applied to each. The first thing a paged engineer must decide is whether the fault is here or downstream, and the timeout numbers are what distinguish a slow dependency from a dead one.
3. The three graphs that separate the common failure modes, linked, in the order to look at them. Not a dashboard with forty panels.
4. The degradation levers: each flag or switch that sheds load or turns a feature off, with its blast radius and who is allowed to pull it at 03:00 without approval.
5. The revert: the exact command, and how long it takes to be in effect.
6. Who to wake, and for what. Named roles, not a team alias.

What to leave off

The component inventory, the class diagram, the technology choices and the reasons behind them. The rationale matters, and it belongs in a decision record that the 03:00 reader will never open, unless the safe use of a lever depends on it. Leave off anything that duplicates configuration, because a page that restates values the code owns is stale within a sprint and a stale page is worse than no page: it gets trusted once.

How you know it is still true

Validated by use, not by review. Two mechanisms: it is the only artefact allowed during a game day, so anything missing is found in daylight by someone who is not under pressure; and every postmortem asks one question, "was the page right?", with an edit required in the same hour if it was not.

A page with no edits in six months and two incidents behind it is stale, regardless of how good it looks. That is the signal to check, and it costs nothing to compute. Hold the page to 90 seconds of reading, so that the edit which adds something also removes something.

Common weak answers

• "We have a runbook." With no statement of who reads it, when it was last correct, or which question it answers first, this is an artefact rather than an answer.
• "A full C4 model." Context and container diagrams are useful to a new joiner in week one and almost useless to a paged engineer, who needs permissions and thresholds rather than structure.
• "Generate it from the service catalogue." The generated dependency graph is genuinely good and does not say which dependency is allowed to be slow, or who may turn it off. The judgement content is the part that cannot be generated, which is why it is the part to write.
• "It's all in the wiki." The reader has four minutes and a phone.