# What is decision intelligence?

Decision intelligence means using evidence to choose what to do, then checking whether it worked. If customer onboarding is slow, it helps you find where customers get stuck, compare possible fixes and measure the result after a change.


> By Saad Bin Shafiq, founder of Nodes · Sep 27, 2026
> Canonical: https://www.nodes.inc/blog/decision-intelligence


---
**Illustrative example:** A team sees more incomplete applications than usual. It could mean applicants do not understand the instructions. It could mean an integration stopped recording documents. Or the documents could be missing. The symptom is the same in a dashboard. The next action depends on which explanation survives inspection.

## Define the decision before diagnosing the problem

“The applications are incomplete” is an observation. The decision might be whether to rewrite instructions, repair an integration, contact applicants, change the review queue, or wait for more evidence. Name the person who owns that choice and the result they are accountable for. Decide which applications, locations, and period are in scope.

Set a baseline from the process as it ran before the change. Count when each case arrived, which requirement was marked missing, when a person reviewed it, and how long it stayed in each queue. Separate a missing value from zero, late data, and an unmatched record. An aggregate rate can hide a specific feed failure or a rule change affecting only one group.

Ask what success would look like before choosing a remedy. A lower incomplete status count may reflect better applications, a corrected data feed, or a changed rule. The business result may be fewer avoidable contacts and faster decisions without skipping required checks. The baseline should cover those measures as well as the visible status.

## Can AI explain why part of our business is underperforming?

AI can bring together records from different teams to investigate what changed and where a problem starts. Missed sales targets, for example, may involve lead quality, staffing or slow customer setup. Treat the explanation as a hypothesis to check before deciding on a fix.

### Compare explanations that lead to different actions

Keep at least two plausible explanations and one piece of evidence that could disprove each. This prevents the first tidy story from becoming the plan.

| Possible explanation | Evidence to inspect | Finding that would weaken it |
|---|---|---|
| Instructions are unclear | Applicant questions, repeat uploads, version of the instructions shown | The affected applicants received clear current instructions and submitted the right file. |
| The integration missed a document | Source attachment, identity match, feed history, mapping changes | The source system also has no document for the same person and case. |
| A required document is absent | Current rule, case type, reviewer notes, source records | The document exists and satisfies the rule, but sits in another queue. |

The table is a test plan, not a claim that those are the only causes. A rule change, staffing delay, or different case mix could matter. If the records disagree, preserve the disagreement with dates and a named exception owner. Ask which source is authoritative for this field and whether the conflict would change the choice. Do not fill the gap with a model's best guess.

Connected records make this investigation possible. The applicant in an intake system, a document in storage, and a reviewer note can refer to the same case while carrying different timestamps and permissions. [A context graph](/blog/what-is-a-context-graph) is one way to preserve those links and their origins. The graph label alone does not establish that they are correct.

## Compare the options on the same clock

When the evidence points toward an explanation, the team still has a choice. It might act now, wait for a defined period, run a small investigation, or make no change. Estimate costs and possible benefits over the same period. Include implementation effort, recurring software and human work, delay, and reversibility. Future costs on both the action and waiting paths are estimates; the unchosen future remains counterfactual. [The cost-of-action guide](/blog/cost-of-inaction-is-the-hard-half) provides the fuller comparison.

In the example, repairing the integration may be justified if source files exist but fail to appear in the review queue. A small replay of affected cases could show the size of the problem before production changes. Rewriting instructions would not fix a lost attachment. If the available evidence cannot distinguish the causes, gathering more evidence is a legitimate decision. Record what finding would change that choice and when the owner will revisit it.

Give a recommendation its uncertainty and contrary evidence. If the estimate is too weak to price, say so. Precision can make an unsupported number look earned. A decision owner should be able to inspect the assumptions, challenge a source, or choose a different option.

## Carry authority into the work

A decision to act names who may approve the change and which identity can perform it. Routine steps may run within standing authority, while consequential or newly scoped work can require review of the actual plan. A prior approval cannot expand current permissions. If a plan changes from “create a task to inspect these cases” to “alter a production rule,” that is a different action.

After approval where required, verify the external effect. Did the mapping repair pass its tests? Did the review queue receive the expected records? A generated plan and a successful tool response are different events. If a write result is unknown, reconcile the destination before retrying. Record failures and declined proposals alongside successful actions.

## Check the result before teaching the next case

Observe the process after the change over an agreed period. Did fewer valid applications become stuck? Did the team spend less time chasing files? Were required checks still completed? Compare the new cases with a credible baseline and note changes in volume, staffing, or rules that could explain part of the result. A better outcome after a repair is useful evidence; it does not by itself prove the repair caused the improvement.

A [Decision Trace](/glossary/decision-traces) can connect the original question, dated sources, alternatives, human judgment, authority, action confirmation, and later observation. A proposed lesson becomes reusable only after its scope and evidence are evaluated. A result in one application process should not silently become company policy for every other process.

[Nodes Engine](/platform) connects permitted company evidence, investigates a question or authorized signal, compares options, coordinates approved work, and retains its Decision Trace. Connector verifies the needed sources and operations; AI FDE helps configure and test the workflow. These are working products. The incomplete-application story here is illustrative, and its exact integrations and effects would need customer-specific validation.

For a first decision-intelligence exercise, choose one repeated problem with a named owner. Write down the current baseline, two competing explanations, the evidence that would weaken each, and the next check date. That is enough to make a later recommendation inspectable.

## Sources

- [Nodes platform](https://www.nodes.inc/platform)

*Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.*