Separate the score from the action

Find the line in your system where a model's output becomes a consequence for a person, and look at what is actually there. In most systems it is a single expression — a score comes back, and a few characters later, if score > 0.8, the account is frozen, the application is denied, the case is escalated. That expression looks like plumbing. It is not plumbing. It is the entire decision, compressed into a comparison and buried in a function that nobody reviews as a decision, because it does not look like one. The model gets a design doc and a review board. The threshold gets a code review from someone checking whether the branch is correct, not whether it should exist.

The problem is that a model does not decide anything. A model estimates. It produces a number that means, roughly, here is how likely this looks to me. Acting on that number — treating a 0.8 as grounds to refuse someone — is a separate thing entirely. It is a choice: about what the number is worth, about where to draw the line, about what to do on each side of it. When you fuse the estimate and the choice into one line of code, you have not simplified the system. You have made one of the two decisions disappear. There is now an inference and a side effect, and no artifact anywhere that says we decided to act — because the acting was never represented as a decision, only as the automatic downstream of a score.

The if-statement that ate the decision

Consider what that fusion destroys, because it is more than tidiness. Accountability breaks in three specific places. The first is governance: the real choice — the threshold, the policy, the action taken — is now expressed as code, so it is governed like code. It ships in a pull request, it changes in a hotfix, it lives wherever the branch lives. The one parameter that most directly determines who gets refused is the one parameter that never passes through the process you would use to govern a consequential decision, because it is disguised as an implementation detail.

The second is the record. When the score and the action are the same event, you cannot record why this action separately from what the model estimated, because there is only one thing to record. The log says the score was 0.83 and the account was frozen. It cannot say the model estimated 0.83 and we chose to freeze because policy P treats anything above 0.8 as grounds to act — because that second sentence corresponds to no object in the system. The reasoning for the action was never distinct from the number; it was compiled into the comparison and lost.

The third is change. Because the estimate and the action policy are the same code, you cannot touch one without touching the other, and you cannot audit one apart from the other. Want to make the cutoff more lenient after a bad quarter? You are now editing the file the model team owns. Want to review whether the action was justified without re-litigating whether the model was accurate? You cannot, because the record does not separate them. Two questions that belong to two different owners have been welded into one line that belongs, by accident, to whoever last touched it.

A threshold buried in an if-statement is a policy decision that no one signed and no one can find.

Two decisions, two owners, two records

So the directive is to keep them apart, structurally, as a matter of how the system is built. The model produces a score and nothing else — that is its entire job, and it ends at the number. A separate, explicit decision policy takes the score plus the surrounding context and maps it to an action. And the decision record captures both: the estimate the model produced, and the choice the policy made, as two distinct facts about one event. Not one fused outcome, but an estimate and an action, side by side, each legible on its own terms.

The reason this matters is not architectural elegance; it is ownership. The score belongs to the people who can speak to it — the ML team, who can tell you what the model was trained on, how it is calibrated, what its error looks like. The action policy belongs to whoever is accountable for the consequence — the person who has to answer for what happens to someone who is refused, and who therefore should be the one deciding where the line sits and why. These are different competencies and different responsibilities, and fusing them forces one owner to answer for the other's work. When the cutoff lives in the model's codebase, the ML team owns a moral choice they never made and cannot defend. When the model's calibration lives inside the action, the accountable party owns a statistical artifact they cannot evaluate. Separate the layers and each decision returns to the person who can actually stand behind it.

What the separation buys you

What you get for the separation is concrete, and you feel it the first time something goes wrong. You can change the action policy without retraining — move the operating point, add a context condition, route certain cases to a human, all without touching the model, because the model was only ever producing a number and the number has not changed. You can audit the choice apart from the estimate — ask whether the action was justified given what the model said, which is a different question from whether the model was any good, and now they have different answers in different places. And you can say, of any outcome, the two sentences that a fused system can never produce: the model estimated X; we chose to do Y because of policy P. Two sentences, two owners, two records. That is what accountability sounds like when the layers are intact.

Underneath all of it is the claim this series keeps returning to: a decision is not a score. A score is an estimate, hedged and probabilistic, honest about its own uncertainty. An action is a verdict — final, consequential, borne by a person. When you hardwire one to the other, the hedged estimate silently becomes an unappealable verdict, and the probabilism that was the model's honesty becomes the cover for a choice nobody admits to making. The 0.8 was never a decision to refuse anyone. Someone decided that 0.8 would refuse people. Keeping the score and the action in separate layers, separately recorded and separately owned, is how you keep that someone visible — and how you stop a probability from hardening, by default and without a signature, into a fate.

— Dispatches · Summit Cognitive