- In short
- The four-layer request logging model captures, for every production Claude call, the request (model version, input token count, prompt identifier), the response (output token count, latency, stop reason), the context (user role, session ID, cache status), and the outcome (whether downstream systems accepted the output). Each layer answers a different question during an incident investigation, and missing any one leaves a blind spot that cannot be reconstructed after the fact.
Four layers, four different questions
When a production Claude system misbehaves, the investigation is only as good as what was logged before the incident. The exam's foundational observability model names four layers that together let you reconstruct what happened: the request, the response, the context, and the outcome. The reason it is four and not one is that each layer answers a different question, and no single layer answers all of them. Skimp on any layer and there is a class of incident you simply cannot investigate afterward, because the evidence was never captured.
This is a remember-level knowledge point, so the specific contents of each layer matter. But the deeper point is the design stance: you decide what to log by asking what questions you will need to answer during an incident, and you build the instrumentation to answer them before the incident arrives.
- Four-layer request logging model
- A logging design that captures four layers for every production Claude call: the request (model version, input token count, prompt identifier), the response (output token count, latency, stop reason), the context (user role, session ID, cache status), and the outcome (whether downstream systems accepted the output). Each layer answers a distinct incident question.
What each layer holds
The request layer records what went in: the model version, the input token count, and a prompt identifier. This is what lets you tie an incident back to a specific model version and prompt, essential when a model update or a prompt change is the suspect. The response layer records what came out: the output token count, the latency, and the stop reason. Stop reason in particular tells you whether the model finished normally or was cut off, which distinguishes a truncation from a complete-but-wrong answer.
The context layer records the circumstances: the user role, the session ID, and whether caching was applied. This is what lets you group an incident by user or session and check whether a stale cache was involved. The outcome layer records what happened next: whether the downstream system accepted the output, and any rejection signals. This is the layer teams most often omit and the one that catches the failures the others cannot see.
Why the outcome layer is the one people miss
An LLM system rarely fails by crashing; it fails by producing a response that looks fine but is subtly wrong. The request, response, and context layers can all look healthy for exactly such a response, the call succeeded, the tokens are reasonable, the latency is fine, while the output is nonetheless wrong in a way that only shows up when a downstream system rejects it or acts on it incorrectly. The outcome layer is what surfaces that. Logging whether the downstream system accepted the output turns an invisible quiet failure into a recorded signal you can alert on and investigate.
This is why 'log the errors and timeouts' is insufficient. Errors and timeouts are the loud failures; the dangerous ones are the successful-looking responses that are wrong, and only the outcome layer catches them. Request-plus-response logging without the outcome layer leaves the quiet failures entirely unmonitored.
What the exam trips candidates on
Two traps. The first is logging only errors and timeouts while skipping successful-looking responses that are actually subtly wrong, which leaves the quiet-failure class unmonitored. The second is treating request and response logging as sufficient without also capturing downstream outcome signals, which is the same blind spot from a different angle. The credited answer logs all four layers and specifically includes the outcome layer.
Worked example
A team logs the request and response for every Claude call, plus all errors and timeouts. An incident arises: for two weeks, a fraction of the agent's outputs were quietly rejected by the downstream CRM as malformed, but no one noticed until a manager asked why CRM updates had dropped. Why did the logging miss this, and what was missing?
The logging missed it because it captured only the layers where this failure was invisible. The request layer looked normal, a valid model version, reasonable input tokens. The response layer looked normal too, the call succeeded, output tokens and latency were unremarkable, and the stop reason was a clean finish, so nothing in request or response flagged a problem. And because the calls did not error or time out, the error-and-timeout logging never fired either. The failure was a successful-looking response that was subtly wrong, malformed for the CRM, which is exactly the class that request-plus-response-plus-errors logging cannot see.
What was missing is the outcome layer: whether the downstream CRM accepted the output, plus any rejection signals it returned. Had that been logged, each malformed output would have carried a downstream-rejection signal, and an alert on rising rejections would have surfaced the problem within hours instead of two weeks, and attributed it to a specific prompt version via the request layer. The fix is to add the outcome layer so downstream acceptance is captured on every call, completing the four-layer model. The lesson the scenario teaches is precisely why logging errors and timeouts is not enough: the quiet, downstream-only failures need the outcome layer to become visible at all.
Common misreadings to avoid
Misconception
Logging errors and timeouts covers the failures worth catching.
What's actually true
Misconception
Logging the request and response is enough to reconstruct any incident.
What's actually true
How this shows up on the exam
Expect a scenario where a quiet failure went unnoticed and a question about what logging was missing, usually the outcome layer. The reliable reading is the four layers, request, response, context, outcome, each answering a different incident question. This foundational knowledge point unlocks aggregate metrics vs per-request decomposition and observability as a precondition for agent autonomy, and it complements per-tenant key isolation, which the context layer's identifiers support.
A team logs requests, responses, and all errors and timeouts, but for two weeks missed that a fraction of outputs were quietly rejected by a downstream CRM. Which logging layer was missing?
People also ask
What should you log for a production Claude call?
Why log the downstream outcome, not just the response?
Is logging errors and timeouts enough?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.