The four altitudes
Collapsed summary, step list, full trace, raw payload are not four screens but one component family with one data source — and deciding which fact lives at which altitude is the whole information-design problem.
You have a schema now, and every field on it carries a tag saying whether it was emitted, derived or asserted. Open it and read down the list. attempts: 2. durationMs. gen_ai.request.model. toolArguments, as a string, because attributes cannot hold objects. A cost figure you tagged asserted because a runtime does not know what you pay.
Every one of those has to appear somewhere or be deliberately withheld, and this lesson is the decision procedure for that. It is the whole information-design problem in the course, and it is not a visual question. Nothing here is about how the panel looks.
The four altitudes
This course names four. They are not four screens and not four components; they are four projections of the one schema you wrote in the last module.
- 01 — Collapsed summary. One line. Did this work, and can I move on?
- 02 — Step list. One row per logical operation. What did it do, in order, and where did it struggle?
- 03 — Full trace. The real tree, every attempt, complete arguments and results. Exactly what happened here?
- 04 — Raw payload. The unrendered records, in the runtime’s own field names. What did the runtime literally emit?
The full version of each — what belongs, what does not, who reads it, and the specific failure mode that altitude invites — is the altitudes reference page, which is written to be reopened rather than read once. This lesson is the reasoning behind it.
The four are this course’s own taxonomy. No source names them, and no research validates the number. They are a construct built to make one decision repeatable, and the rest of this lesson is the argument for why the construct survives contact with the one piece of research that bears on it directly.
The test: name the reader, then name what they do next
A fact is at the right altitude when you can name the person who meets it there and the action it changes. If you cannot name an action, the fact is decoration, and decoration pushes something useful further down the page.
Nielsen Norman Group put the role split plainly in a 2026 article on explanations inside enterprises: “Because these technical roles bring different goals, expertise, and contexts, explainability cannot be one-size-fits-all”. The article separates a governance lead, who wants global explanations about the system, from a builder, who wants local and interactive ones, from a domain expert, who wants local and static with somewhere to give feedback. Same system, three explanations. NN/g is a consultancy that sells training and research on this material, and its byline on that page differs from the byline on its own topic index, which is why this course cites the organisation rather than an author.
Google’s People + AI Guidebook gives the budget rule that follows from it: “The best approach is not to attempt to explain everything – just the aspects that impact user trust and decision-making”, and it names progressive disclosure as the companion technique that keeps the rest reachable instead of absent. Google sells AI products, so take the guidebook as published design research from a party with a commercial position, not as a disinterested standard.
Read those two together and the altitude question stops being “how much detail?” and becomes two smaller questions with checkable answers. Which reader is this for. What does it change.
Four is more levels than the usability research recommends
Here is the tension, stated rather than hidden, because you will meet someone who knows this finding and the wrong time to hear it is in a review. Nielsen’s 2006 article reports that “designs that go beyond 2 disclosure levels typically have low usability because users often get lost when moving between the levels.”
Four altitudes is twice that. The finding is not on your side.
The honest resolution is not to argue with the research, and it is not to pretend the fourth altitude is really part of the third. It is to notice that these four are not four levels of one control:
- Altitudes 01 and 02 are the product surface. Moving between them is a single disclosure, performed in place, by a reviewer who is already looking at the run. One level, one control, exactly the shape Nielsen’s article is about.
- Altitudes 03 and 04 are an inspector. A separate destination, entered on purpose, usually by a different person with a different goal, often after something already looked wrong.
Building all four as nested expanders inside one panel is precisely the design Nielsen’s finding warns about, and it is the default thing that happens when nobody makes this decision. Building two disclosures on the surface and a two-level inspector behind an explicit door is a different structure that happens to contain four depths.
One data source, four projections
The rule that keeps the family from drifting apart is the same one the first module spent four lessons earning: every altitude renders from the same schema, and no fact may appear at a higher altitude that cannot be traced to something at altitude 04.
This is not architectural tidiness. It is the only mechanism that catches an invented fact before a reviewer does. If the step list says a call took 400ms and the raw payload has two timestamps that subtract to 380ms, one layer is lying, and a shared source narrows the search to the projection. If the summary says the run succeeded and no span carries an Ok status — which, per the tracing specification, is the normal case, since instrumentation SHOULD leave status Unset unless there is an error — then the word “succeeded” is a rule you wrote, not a field you read, and it needs to be written down somewhere a colleague can find it.
The practical consequence for the component: altitudes are not components with their own fetches. They are functions of one run object. A projection that needs a field the run object does not have is telling you the schema is incomplete, which is a cheap thing to discover and an expensive thing to paper over.
Three placements worth arguing about
Abstract rules are easy to agree with. Here are three facts from a real schema, placed, with the reasoning that decides each one.
Token counts. Emitted per model call as gen_ai.usage.input_tokens and gen_ai.usage.output_tokens, so they are real and free. Altitude 03. A reviewer at altitude 02 cannot act on a token count — there is no decision that changes on 1,200 versus 1,900 — and putting it in the step list costs a column that the slow-step duration needs more. The person who acts on token counts is looking for an expensive step, and they are already in the inspector when they do.
Retry attempts. Altitude 02, and arguably 01. This one goes upward rather than down, which is the direction that needs defending. A run that recovered from a failure is a different object from a run that never failed, and the person deciding whether to accept the output is exactly the person whose decision changes. Bury it at altitude 03 and the failure is not merely hidden, it is undiscoverable by anyone who had no reason to look.
The model name. Altitude 03, or 04. It feels important, because it is the most legible piece of the run to an engineer, and it is the first thing every trace panel puts in the header. Apply the test: which reader changes their action on reading it? A reviewer approving an extraction does not switch models. An engineer debugging a bad output does, and that engineer is in the inspector. The model name in the collapsed summary is a fact about your stack shown to somebody making a decision about their data.
Where people get burned
The gravity of this system pulls facts upward, and the pull is social rather than technical. Every stakeholder wants their number in the summary, and every number in the summary is free to add and invisible to remove. The summary is the scarcest space in the whole component, and the discipline that protects it is a written altitude assignment you can point at, with a named reader and a named next action per fact. Without one, the collapsed state becomes a dashboard, and a dashboard is what altitude 02 was for.
Check your recall
Answer from memory — no scrolling back.
Hands on
Assign every field in your schema to an altitude
Done when: ARTIFACT.md’s “Altitude assignments” section holds a table with one row per field in your schema, each row naming an altitude, the reader who meets it there, and the action that reader takes because of it — plus a short list of fields you decided not to render anywhere.
- Open your schema from the last module and list every field, including the derived and asserted ones. Do not group or summarise yet. A field you skip because it is “obviously fine” is the field this exercise exists to catch.
- For each field write three cells: the altitude, the reader, and the action. The action must be a verb a person performs — approve, reject, escalate, re-run, open the inspector, copy this and paste it into a bug report. “Understand the run” is not an action and it is the phrase that hides every bad placement.
- Now count altitude 01. If more than four facts landed in the collapsed summary, cut until four remain. The constraint is artificial on purpose — it forces the argument to happen now rather than in a design review.
- Write the fourth list: fields that do not get rendered at any altitude. Framework-internal spans, parser steps, the run id nobody reads. Deciding not to show something is a decision, and an unwritten one gets re-litigated every time somebody new opens the schema.
- Mark the boundary. Draw a line in the table between altitudes 02 and 03 and label it as the door. Everything above it is the product surface; everything below it is the inspector. That line is the whole answer to Nielsen’s finding and it should be visible in your notes, not implied.
- Bring the table into the chat, particularly the altitude 01 rows and the do-not-render list. Those two are where the argument is, and a placement you cannot defend out loud is a placement that will move later under pressure from whoever asks loudest.
What this does not cover
This lesson decided where facts go. It did not write a single one of them. The collapsed summary in particular has a problem the placement rule cannot solve on its own: one line has to state whether a run worked, and the run may have half worked, and the status field cannot tell you. That is the honest one-liner lesson, which comes next and is the shortest and most dangerous surface in the component.
Altitude 02’s hard cases — a retried call as one row, parallel siblings that must not read as a sequence, a run still arriving — are the step tree lesson after it. Altitude 03 and 04’s shared problem, that complete tool arguments are the most useful and most dangerous thing in the trace, is the tool-call inspector lesson that closes this module. And whether to show a confidence number at all, which the People + AI Guidebook treats under its own heading, waits for the citations and confidence module, where there is enough research to answer it properly.
Read this next — primary source
Progressive DisclosureJakob Nielsen, Nielsen Norman Group, 3 December 2006 — fetched 2026-09-05. Free to read; NN/g sells training and research reports on the practice the article describes, so read it as an argument from a firm with a commercial interest in the discipline, not as a neutral survey.
Twenty years old and still the sharpest statement of the problem, because it is about the split rather than the widget. Nielsen’s claim is that progressive disclosure improves learnability, efficiency and error rate, and that all of the difficulty sits in deciding which features are initial and which are secondary — the same decision this lesson calls altitude assignment. Read it in full for two things this lesson only borrows from: the worked examples of splits that went wrong, and the two-level finding you are about to design past. It is short, and it is the document you will want to hand to whoever asks why your panel does not simply show everything.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.