Instrument the decision, not the model

Look at where your system is instrumented. You will almost certainly find that the telemetry clusters around the model. Latency on the inference call, token counts, the score distribution, drift on the feature vector, an alert when the endpoint returns an error. All of it real, all of it useful, and all of it pointed at the wrong object. Because when someone comes back in a year and asks why this person was refused, you will not be asked to reproduce a latency graph. You will be asked to reconstruct a decision — the specific inputs it rested on, the policy that was in force, the cutoff it was measured against, the moment the score stopped being a number and became a verdict. And that, in most systems, is the one thing nobody logged.

This is a build decision, and you are the one making it, usually without noticing. The model is the part with the interesting failure modes, so it is the part that attracts the dashboards. The decision is the boring part — a comparison, a branch, a write to a table — so it slips through uninstrumented. But the model only ever estimates. The institution acts. The act is the thing with consequences for a real person, and the act is therefore the thing that owes a record. Instrument the estimate and you will know everything about how the number was produced and nothing about the decision it was used to justify.

So the directive is simple to state and specific to implement: capture the decision as a first-class event, not as a side effect of capturing the inference. At the moment your code turns a score into an outcome, write down what that outcome rested on — the actual input values the decision used, the version of the model and the policy in force at that instant, the threshold or rule that was applied, and a timestamp you can trust. Not a pointer to "the current config," which will have moved by the time anyone reads the record. The values as they were, frozen at the point of decision, bound together as one account of one act.

The reconstruction test

There is a clean way to know whether you have done this right, and you can apply it before you ship. Pick a decision your system made yesterday. Now, using only what you persisted — not the live system, not the current config, not your memory of how it worked — try to reconstruct exactly why that decision came out the way it did. If you can lay out the inputs it saw, the model and policy that processed them, the line it was measured against, and the resulting outcome, all from the record, you have instrumented the decision. If you find yourself reaching for the running system to fill in a gap, you have instrumented the model and left the decision unrecorded.

Most systems fail this test in the same two places. The first is the input: the score is logged, but the feature values that produced it are gone, fetched live at inference time from a store that has since changed. You kept the answer and discarded the question. The second is the policy: the threshold or the rule is treated as ambient configuration, current at read time, so a decision made under last quarter's cutoff gets reconstructed against this quarter's — and reconstructs wrong. Both failures share a root cause. You logged what the model did, which felt like logging the decision, and it was not.

The model is what you debug. The decision is what you defend. Instrument the thing you will have to defend.

Notice what this is not. It is not a demand for more logging in general — more volume is usually the enemy of a usable record, not the friend. It is a demand for the right record: a small, bounded, exact account of each consequential decision, captured at the point of decision, complete enough to stand on its own. You are not trying to reproduce the universe. You are trying to make one act reconstructable by someone who was not there and does not trust you. That is a narrower and more achievable target than "observability," and it is the one that matters when a decision is contested.

Where to put the hook

Concretely: the right place for the instrumentation is the seam where the score crosses into action — the function that takes a model output and an applicant and returns an outcome. That seam is where the decision actually happens, and it is usually a few lines of unglamorous glue code that nobody thought to watch. Wrap it. Have it emit one record per decision, written before the outcome is returned, containing the inputs the branch read, the model and policy identifiers and versions, the operating point applied, the outcome, and the time. Make the write part of the decision path, not a best-effort log line that can be dropped under load — because a record that is missing exactly when the system is under stress is missing exactly when a contested decision is most likely to have been made.

Do this and you change the system's posture without changing its behavior. The same scores produce the same outcomes; what is different is that each outcome now leaves behind an account that can answer the only question that will ever be asked of it adversarially — why this one, and on what basis. That account is cheap to build at the seam and effectively impossible to reconstruct after the fact, which is the whole reason it has to be a build decision and not a forensics project. You will not retroactively know what the threshold was last March. You can only know it if you wrote it down in March, at the moment it decided someone's case.

The model will keep getting the attention, and that is fine — it should be monitored, tuned, watched for drift. But monitoring the model is operations. Instrumenting the decision is accountability, and they are not the same work. When you sit down to add telemetry, ask which object you are pointed at. If every hook you have is on the inference and none is on the act, you have built a system that can tell you how it computed and not what it did. Move one hook. Put it on the decision.

— Dispatches · The Field Manual · Summit Cognitive