Fast decision models need trained intent and verified context, not just assembled context.

Decision models are having a moment. Jev, Cloudflare’s Clef and OpenAI’s Decisions API skip the verbose reasoning and return structured JSON with a confidence score. Developers love the speed and the determinism.

In a recent VentureBeat piece, Dattaraj Rao of Persistent Systems named the catch. These models don’t explain themselves. If the model won’t reason for you, he argues, you have to reason for it upfront, through context design.

Context matters. But we lived this problem on our AI-native operations platform, and my experience says context is not enough. A model never trained on why a disposition applies won’t reach it, however good the context. And no model, fast or verbose, can be relied on to tell you what it was actually thinking.

The ticket

An incident came in: a cloud VM on Azure was unavailable.

We asked our disposition model what to do. It returned automate: restart the VM.

Then we asked the obvious question. Why? What were you thinking?

There was no answer. A classification has no reasoning to recover.

What the right answer was

The first step should never have been a restart. It should have been a check.

  • Is the VM actually down? Check the Azure control plane.
  • If it’s up, why is it unreachable? Check the network path.

In this case the VM was running. The VPN was down. The “VM unavailable” ticket was a last-mile network symptom, not a compute failure.

A restart would have done nothing except add risk to a healthy machine. The correct disposition was eliminate.

Why the model said restart

The model learned from history, and history lied to it.

In most ticket data, “VM unreachable, restarted, resolved” looks like a success story. Often the restart had nothing to do with it. The network recovered on its own, or the ticket auto-closed. The label recorded the action, not the cause.

So the model learned a symptom-to-action correlation. Better context design on the ticket text alone would not have fixed that. The ticket simply did not contain the truth.

Three layers, not one

Rao frames context as the fix. In my experience it is one of three layers, and the least sufficient on its own.

Train on the why. Label historical dispositions with verified cause and the reasoning for eliminate vs automate vs human assist. Without this, eliminate is unreachable. Context given to a model that never learned the why is like teaching a parrot a new word: it repeats, it doesn’t understand.

Verify before deciding. Run deterministic checks first: control-plane status, network path (VPN, gateway, security rules). “VM running + VPN down” then cannot map to “restart.”

Make the why checkable. Train the model to produce its rationale before the disposition, anchored to verified evidence. If rationale and evidence disagree, the decision does not execute.

Don’t ask the model what it was thinking

Even then, the model can’t truly explain itself. A pure decision model has no reasoning to report. A generative model asked “why” afterward writes a plausible reconstruction, not a readout of what drove the output. Research on chain-of-thought faithfulness has shown stated reasoning often leaves out the real cause.

So responsibility for the why sits with human assist, and the harness must give humans something to reason with:

  • Confidence: calibrated, with a threshold that routes to a human
  • Evidence state: what was verified and what wasn’t
  • Precedents: the historical tickets the decision most resembles. Here it would have exposed the contaminated “restart, resolved” history
  • Conflicts: disposition vs evidence, such as restart while the VM shows running

Confidence alone would not have caught our case. The restart was likely a confident call.

The model decides. The harness exposes. The human deduces and corrects. Each correction becomes training on the why.

From one ticket to an elimination program

“Eliminate” is rarely a single-ticket decision. It comes from historical intelligence: seeing that a class of VM-down alerts is really a recurring network cause. That pattern becomes a transformation program:

  • 1. Remove the alert that generates the misleading ticket.
  • 2. Reconfigure detection to check the cloud control plane and the network path together.
  • 3. Re-point the action to what actually fixes it: recreate or restore the VPN, not restart the VM.
  • 4. Re-label history with verified root cause, so the next model doesn’t learn the same wrong lesson.

The ticket disappears. Not because we automated it faster, but because it should never have existed.

The takeaway

Decision models make explainability the builder’s job. In enterprise operations, that job is not prompt engineering. It is training the why, verifying state before anything decides, and building a harness that shows humans what a decision rested on.

Speed without verified context just gets you to the wrong restart faster.

Sources

This article is part of the Enterprise Intelligence series on building organization-specific intelligence that drives peak business performance.