Quick brief
A useful AI investment improves an owned decision and its resulting action, rather than stopping at a better prediction or faster summary. Design the evidence, decision rights, runtime, recovery and measures together, then expand only the decision classes whose observed outcomes justify it.
Full analysis
Revised 18 October 2026.
A contract-renewal team receives a strong AI-generated summary and still misses the renewal date. The summary was ready. The commercial owner had not reviewed the exception, the approval route was unclear, and nobody confirmed that the agreed change reached the contract system.
This illustrative example captures the distinction behind decision-centric AI: a better summary helps only as far as the organization can use it to reach a decision and carry that decision into action. The service needs the right evidence, someone with authority to decide, and a dependable path to the destination outcome.
I use Decision Velocity to examine that complete path. The aim is to reduce avoidable delay while preserving the quality, authority, and evidence the decision requires. A quick recommendation that waits indefinitely or triggers the wrong action has not improved the service.
Download the printable framework map.
Choose one decision the organization can own
Start with a decision that has a recognizable beginning, accountable owner, and observable result. “Improve procurement with AI” is too broad. “Decide whether to renew this supplier contract under the current terms, seek a change, or escalate an exception” gives the team a concrete unit of work.
Define the scope carefully. The renewal decision may depend on service performance, the proposed price, an approved budget, security review, and the notice deadline. Some cases will be routine; others will require specialist judgment. An explicit case boundary makes those differences visible before the team starts automating.
The business owner should explain what a good decision means and which tradeoffs are acceptable. Engineering can make a review faster, but it cannot infer the organization’s appetite for an unfavorable commercial term or a new data-handling arrangement. Those choices need an accountable decision-maker.
Avoid selecting a first workflow solely because it is easy to demonstrate. Choose one where the owner can provide representative cases, identify the destination outcome, and act on what the pilot reveals. A modest, well-owned process can teach more than an impressive assistant whose recommendations nobody is obliged to use.
Diagnose the architecture before blaming the model
A prediction may go unused because the model is wrong, the source evidence is incomplete or the application is too unreliable for the workload. It can also be technically useful while the organization has no route for acting on it. Those explanations lead to different investments; describing every failed pilot as a governance problem would obscure that distinction.
Look for the handoff where the work becomes uncertain. A churn score may reach marketing while nobody owns the retention offer. A fraud flag may reach an analyst who cannot suspend the payment. A maintenance warning may arrive before the team has the parts or access window needed for an intervention. These are illustrative possibilities, not accounts of deployments. In each case, improving prediction quality alone leaves an operating dependency unresolved.
Siloed pilots can make that gap harder to see. Each team reports a successful local output, while the complete case waits between teams. A central AI team can help with reusable components and evaluation, but it cannot define every business tradeoff from outside the process. Assign the outcome and escalation rights before assuming that a shared platform will resolve them.
The same distinction applies to generative AI. A research assistant can produce a valuable comparison without being authorized to negotiate a contract. Retrieval can ground that comparison in documents while leaving their authority unresolved. An agent can add action capabilities, yet still lack a permitted route to the destination. These are separate design decisions. They deserve separate tests and owners.
Select a decision without hiding the tradeoffs in a score
Compare candidate decisions on the same evidence. A weighted score can help structure discussion, but its weights reflect the organization’s judgment and can conceal a non-negotiable constraint. An unclear owner or prohibited data path should remain visible rather than disappear inside a high commercial score.
| Dimension | Question to resolve | Evidence before selection |
|---|---|---|
| Outcome value | What improves if this decision changes? | Baseline volume, loss/cost/value mechanism and affected people |
| Feasibility | Can the team obtain evidence and reach a controllable destination? | Source access, dependencies and actual supported operations |
| Time sensitivity | When does delay change the outcome? | Deadlines, event history and consequences of late action |
| Ownership | Who can change the process and accept residual risk? | Named business and operational owners with decision rights |
| Evaluation | Can the team distinguish a useful result from a plausible one? | Representative cases, acceptance rules and outcome labels |
| Obligations | Which conditions constrain the use? | Applicable entity, jurisdiction, intended use and specialist assessment |
Choose a tractable slice of a valuable decision, rather than calling the entire function a pilot. For renewals, that might be contracts with an established owner, complete evidence and a supported update interface. Keep excluded cases in the intake record so the pilot’s apparent performance is not confused with the whole portfolio.
Write a decision canvas before designing the assistant
For the synthetic renewal case, the canvas names the decision, owner, permitted outcomes, evidence, decision rights, action path, and measures. Keep it short enough that the business and technical owners can review it together. The Decision Velocity framework map provides a starting structure and a printable version.
The permitted outcomes might be renew under existing terms, negotiate specified changes, decline renewal, or escalate. The evidence includes the contract version, notice date, service record, proposed terms, current budget, and relevant reviews. Missing evidence should produce a visible unresolved state rather than a plausible assumption inserted into the recommendation.
Decision rights belong on the same canvas. State who may accept the existing terms, who may approve a price change, and which exceptions require another reviewer. The assistant can prepare a comparison and identify a conflict. Whether it can send a negotiation email or update a contract record is a separate permission.
Define completion at the destination. A draft decision is not a recorded approval; a recorded approval is not proof that a notice was sent or the contract record updated. Choose the completion event appropriate to the service and keep intermediate outcomes distinguishable.
A filled canvas for the renewal example
| Canvas field | Illustrative entry | Design consequence |
|---|---|---|
| Decision | Renew, negotiate, decline or escalate one supplier contract | Separate permitted outcomes and reasons |
| Owner | Commercial process owner; named operational stop authority | Someone can change the workflow and suspend execution |
| Inputs | Contract/version, notice deadline, price, performance, budget and specialist reviews | Missing or conflicting material evidence remains unresolved |
| Rights | Analyst proposes; authorized owner accepts defined terms; exceptions escalate | A recommendation is distinct from action permission |
| Destination | Contract record plus any required notice | Record update and notice delivery can complete separately |
| Completion | Defined outcome confirmed, authorized and supported by evidence | A generated summary is an intermediate event |
| Recovery | Investigate unknown destination results; repair partially completed work | Timeout does not authorize blind retry |
| Measures | Elapsed time, quality, review effort, cost, unresolved cases and control failures | Local response speed does not stand in for outcome improvement |
Review the canvas with the people who will use the service. A missing budget field might be an integration task; an unresolved right to accept a changed commercial term is a business decision. Writing both as “data needed” sends them to the wrong owner.
A second canvas tests whether the design transfers
A hypothetical property-claims triage service shows why the same canvas should not imply the same authority. It might assemble first-notice information, policy references, photos and a model’s fraud signal, then recommend a route. The insurer’s permitted disposition, customer rights and review obligations still require their own assessment. A high fraud score should not silently become authority to deny a claim.
Define the decision narrowly: route a claim to routine handling, specialist review or an unresolved-evidence queue. The claims process owner defines the permitted categories and outcome measures. The application records the policy version, evidence reviewed, material case values, proposed route, authorization mode and destination queue confirmation. If the service is later allowed to authorize a payment or denial, that is a new action boundary with different acceptance requirements.
Evaluate both routing quality and what follows it. A short triage time is of limited value if cases arrive in the wrong adjuster queue, require repeated transfers or delay a legitimate payment. Include customer effort, reviewed errors, rework and downstream completion alongside the model score. Stop new routing when required, while preserving the queued cases and evidence needed for recovery. This transfers the decision design without transferring the renewal workflow’s permissions or illustrative targets.
Trace the delays before promising an improvement
Map the existing path with actual event times and active work where available. Separate preparing the evidence, waiting for information, waiting for a reviewer, making the decision, executing it, and confirming the result. Include the cases that stall, fail, or return for rework.
Suppose the renewal summary takes two hours to prepare, but the exception review meets only on Thursday. Reducing preparation to ten minutes may make the analyst’s day easier without changing the contract’s completion date. The next intervention depends on the operating arrangement: earlier evidence, a different review cadence, a narrower exception class, or a permitted standing decision rule.
Parallel work can help when the dependencies allow it. Security and commercial reviews may be able to begin from the same complete evidence package. They cannot necessarily approve independently if one review changes the terms the other examined. Draw the actual dependencies instead of assuming every sequential step is waste.
Some waiting is protective or required. A cooling-off period, a necessary consultation, or a deliberate second review may serve a real purpose. Name the reason and decide whether the process is proportionate. Calling every delay friction can encourage the team to remove a control before understanding it.
Put AI where it changes the work
In the renewal example, AI may help identify the relevant clauses, compare proposed terms, assemble review evidence, and prepare a draft recommendation. Those tasks deserve their own acceptance conditions. A clause comparison should preserve the material differences and cite the correct versions; a smooth summary that misses a changed termination term should fail.
Use a simpler method where it is dependable. A notice deadline already stored in a validated field may need a date comparison, not a model’s interpretation. A permission check belongs in the application’s control path. Reserve model reasoning for the parts of the work where it is useful and test the complete configuration.
The model can also help a reviewer understand uncertainty. If two documents disagree about the renewal date, show the conflict and the source references together. Asking the assistant to choose a confident answer may reduce the visible number of unresolved cases while increasing the risk of a missed notice.
For bounded steps, compare a compact model, a capable managed baseline, and any reliable non-model approach. The small-language-model article describes that selection process. Model choice follows the task and operating constraints; it does not define the decision architecture.
Meeting follow-up inside an advisor’s work
Morgan Stanley’s June 2024 Debrief announcement describes a tool that, with client consent, generates meeting notes and surfaces action items for financial advisors. After a meeting, it drafts an email for the advisor to edit and send at their discretion and saves a note to Salesforce. It followed the firm’s September 2023 rollout of its internal research Assistant. These are the firm’s descriptions of its services, not an independent estimate of financial return.
The useful design point is the location of assistance: research and meeting follow-up inside an advisor’s work, with the advisor retaining the email’s edit-and-send decision. It still leaves measurement questions. Are notes accurate, how much review do they require, are action items completed, and what changes for clients? Those questions need evidence from the operating workflow beyond the rollout announcement.
Make the action boundary explicit
Once a reviewer decides, the workflow needs a controlled path to the destination. Show the precise action, target record, material values, and authorization. An approval to renew one contract should not be reused for a different supplier, price, or term after those values change.
Recheck the conditions that matter before execution. The approved contract version, budget, permissions, or governing policy may have changed since preparation. The Version Drift article explains how a well-sourced earlier recommendation can become unsuitable for the action now being attempted.
Handle partial completion honestly. If the contract record updates but the notification fails, the service has two different outcomes to reconcile. If a destination times out, establish whether the action happened before retrying. Use supported destination mechanisms for conditional updates and duplicate prevention where available, and route unresolved state to someone who can recover it.
Keep an effective stop and revocation path. Removing a tool from an interface is insufficient if an existing credential or queued job can still perform the action. Test the boundary the destination enforces. A business owner should know how to suspend the affected operation without losing the evidence needed to investigate.
Build a decision service around the existing systems
I use “decision factory” for a repeatable capability to design, run and improve these workflows. It is an architectural proposal, not a product category that makes an organization mature by purchase. Existing orchestration, case management and application controls may already provide much of it. The point is to connect their responsibilities around the decision.
Four planes help make that allocation concrete.
| Plane | Responsibilities | Boundary to test |
|---|---|---|
| Decision | Objectives, permitted outcomes, rules, constraints, model contributions and escalation | A generated recommendation cannot alter its own permissions |
| Integration and runtime | Case state, scheduling, destination calls, attempts and recovery | Accepted request, completed action and unknown result stay distinct |
| Trust and governance | Source applicability, identity, approval binding, evidence and change review | The executed action matches the authorized case and material values |
| Observability and economics | Event timing, outcomes, review effort, operating cost and incidents | Failed and pending work cannot disappear from the report |
A decision service can sit alongside a contract, claims or customer platform without replacing that system’s ownership of its records. It resolves the relevant workflow state, invokes the necessary rules or model, gathers authorization and submits the permitted operation. The destination remains authoritative for whether its protected change occurred. If the existing application can already perform those functions, extending it may be simpler than adding a sidecar.
The supporting components have distinct jobs. A policy service resolves applicable approved rules; a rules or optimization component handles specified constraints; inference provides the model contribution; a reviewer workbench presents evidence and material action values; an evidence store preserves the records needed for investigation. Connectors carry supported operations, while observability joins the events by case and attempt. None of these components should be treated as a source of authority merely because it appears in the architecture.
Interoperability needs more than a shared API shape. Carry stable case and source identifiers across services, define outcomes and errors consistently, and preserve the distinction between an assertion from another agent and an authenticated approval. An MCP connection can expose a capability, but it does not establish that this user may use it for this transaction. Business authorization belongs at the protected operation.
The reviewer workbench deserves the same attention as the model prompt. Show the target, proposed values, supporting versions, conflicts and uncertainty together. Let a reviewer correct or reject without losing context, and make escalations visible in a real queue. A workbench that hides material differences can make a nominally human-controlled process difficult to control.
Migrate the control path, not every platform at once
Begin by tracing one existing decision. Preserve the source systems and reliable model components that already work. Introduce stable events and an evidence path before increasing authority. Then separate the proposal from commitment, make source and approval checks enforceable, and exercise the destination’s recovery mechanisms.
| Migration move | Concrete artifact | Acceptance question |
|---|---|---|
| Inventory and bound | Decision canvas and current event trace | Can the owner identify intake, excluded cases and completion? |
| Connect evidence | Case/attempt identifiers, source versions and destination results | Can an investigator reconstruct a completed and a failed case? |
| Enforce rights | Scoped permissions, material approval binding and revocation | Can a changed or unauthorized action still commit through another path? |
| Improve reviewer flow | Evidence panel, correction, escalation and override records | Can the reviewer make a timely informed decision at expected volume? |
| Prove and expand | Shadow comparison, limited operation and change tests | What observed evidence supports the next case class or authority level? |
Do not promise exact generative replay merely because inputs and model names were saved. Provider versions, nondeterminism, unavailable dependencies and changed external state can prevent reproduction. Preserve the original observable result and configuration; distinguish reconstructing what happened from obtaining an identical output in a later rerun. A simulation or organizational digital twin can test specified scenarios, but cannot prove the absence of unmodeled failure.
Buy or build against these artifacts. Ask a supplier to demonstrate the changed-case rejection, evidence export, human correction and uncertain-outcome recovery using a representative case. Compare integration effort, operating responsibility, residency and exit constraints as well as license price. A bundled platform may reduce assembly work; a composable design may fit existing controls better. Neither warrants a universal cost or delivery-time promise.
Measure accepted outcomes and human effort together
The renewal team needs more than the number of summaries generated. Track completion time to the defined outcome, accepted and unresolved cases, review and rework effort, cost per accepted result, and material control failures. Keep the task population and acceptance rule visible so a change in case mix is not mistaken for a better system.
Avoid turning Decision Velocity into a single impressive score before the measures are trustworthy. A weighted index can hide a serious quality failure behind a time improvement. Keep the underlying measures available and give critical control failures their own treatment rather than averaging them away.
Human overrides deserve review, not automatic celebration or blame. A reviewer might correct a faulty recommendation, act on information the system never received, or make an error. Sample the reasons and outcomes. An override rate alone cannot tell the team which of those explanations applies.
The measurement article provides a worked timing example, including the case where faster preparation leaves the final completion time unchanged. The token-economics workbook connects accepted outcomes to model, tool, platform, and human-review costs. Neither calculation should turn released capacity into a cash-saving claim without an operating basis.
An optional Decision Velocity Index needs visible assumptions
The underlying measures should remain the primary report. If a team wants a compact index, the following is an illustrative design, not a validated cross-industry benchmark:
S = min(target median completion time / observed median completion time, 1)
Q = min(observed accepted-outcome rate / target rate, 1)
R = acceptable stress scenarios / evaluated stress scenarios
C = eligible cases with the defined governance controls / eligible cases
DVI = S × Q × R × CMeasure completion time from intake to the defined confirmed outcome, using comparable task definitions and fixed intake cohorts for the target and observed estimates. Report the completion fraction, failed outcomes and pending-case ages at the cutoff; a completed-only median can appear better when difficult cases remain unfinished. Leave S unresolved when a comparable cohort estimate is unavailable, rather than awarding a higher score for incomplete work.
Use positive completion-time and target-rate denominators, define eligible cases in advance, and keep each factor in the interval zero to one. A missing observation or zero denominator is unresolved, not automatically a perfect factor. Governance coverage is not the automation rate: a properly governed human-led case can be covered. Report automation separately.
For a synthetic stream with comparable cohort estimates, let the target median time from intake to confirmed outcome be 25 minutes and the observed median be 30 minutes. Let the accepted-outcome rate be 93% against a 95% target, all evaluated stress scenarios meet the chosen criteria, and governance coverage be 65%. The index is (25/30) × (0.93/0.95) × 1 × 0.65 = 0.5303, approximately 0.53. The timing and rates are illustrative, not industry targets or deployment results.
The number has substantial limits. Multiplication penalizes a low factor but still lets different failure patterns produce the same score. A factor clipped at one also hides improvement beyond target. The quality measure depends on the acceptance definition and outcome-label delay; the resilience factor covers only evaluated scenarios. A critical unauthorized action should trigger its own response even if the aggregate index rises.
Keep the factors, sample sizes, distributions, incidents and definitions beside the index. Do not call it economic return: it contains no financial value. Nor should portfolio aggregation imply that a high-performing renewal workflow offsets a severe clinical or payment-control failure. Use the index to ask where to investigate, with release and safety constraints evaluated independently.
Connect the decision stream to economics
An investment case needs a mechanism for value. Earlier renewal preparation might prevent a missed notice, improve negotiation readiness or release analyst capacity. Those are different benefits with different evidence. Count a prevented loss only against a defensible baseline, and avoid assigning the same benefit to faster preparation and faster completion twice.
In a purely illustrative monthly scenario, suppose attributable incremental benefit is $18,000 and incremental operating cost is $12,000 for the same defined stream. Net operating benefit is $6,000, and operating return relative to that cost is 50%. This excludes initial integration, migration, training and other setup costs, so it is not full investment ROI or a payback estimate. If those costs matter to the decision, include their timing and an appropriate financial assessment.
The review should show volume, accepted outcomes, review/rework, unsuccessful attempts and cost allocation. Separate measured facts from estimated avoided loss or future volume. Finance and the business owner can challenge the assumptions; the platform team supplies instrumentation rather than declaring every released hour a cash saving.
Use four phases to keep the pilot accountable
I organize this work as define, design, deploy, and defend. Define the decision and its owner. Design the evidence path, rights, handoffs, and failure responses. Deploy within an agreed scope after testing. Defend the service through monitoring, incident handling, change review, and continued evaluation.
The phases are a working discipline, not four documents to complete once. A pilot may reveal that the original decision scope was too broad or that the source owner cannot maintain the required information. Return to that design question rather than treating deployment as proof that it was resolved.
A shadow comparison can help before live action: prepare recommendations without allowing the system to execute, then compare them with reviewed outcomes. Check how the evaluation is performed, including case selection and reviewer knowledge. A shadow result does not reproduce every operational condition, and it cannot establish the reliability of an action path that was never exercised.
Limited live deployment needs an explicit expansion gate. The owner should review representative outcomes, unresolved cases, failure severity, review burden, cost, and recovery behavior. Expand only when the evidence supports the next scope. A calendar milestone or a successful demonstration is not an adequate acceptance condition by itself.
Make the phases produce inspectable artifacts
| Phase | Work product | Decision before proceeding |
|---|---|---|
| Define | Canvas, baseline, source owners, affected people and scope exclusions | Is this decision valuable, feasible and owned? |
| Design | Dependencies, rights matrix, reviewer flow, evidence contract and recovery | Can the team explain both completion and failed-path behavior? |
| Deploy | Tested configuration, limited scope, operator preparation and monitoring | What evidence supports this release and its authority envelope? |
| Defend | Incident review, outcome labels, overrides, source changes and cost assessment | Continue, repair, restrict, retire or expand? |
A first 90-day effort may aim to define and demonstrate one bounded workflow. A subsequent six-month plan might fund limited operation and resolve dependencies; a longer portfolio plan can reuse the controls across other decision classes. These are planning envelopes, not claims of typical delivery time or payback. A source or destination limitation can prevent the next stage regardless of calendar progress.
Maturity is visible in capability rather than model count. At first, the organization may have useful recommendations with no agreed outcome trace. The next step is a maintained case boundary and measured baseline. A controlled live service adds enforceable rights and recovery. A broader portfolio adds reusable evidence and change processes without erasing differences among decisions. A team can be mature in renewals while still exploring a clinical or credit use with different requirements.
Use controls whose failure behavior is explicit
| Control | Intended job | Test before expanding authority |
|---|---|---|
| Stop and revocation | Suspend protected work | Queued jobs, delegated identities and existing credentials cannot bypass the stop |
| Limits | Bound permitted operations and case exposure | Repeated or concurrent requests cannot evade the intended boundary |
| Independent approval where required | Separate conflicting responsibilities | One identity cannot satisfy both roles through two interfaces |
| Source and approval validity | Keep action tied to the governing rule and material values | Effective-date, case-value and permission changes cause the specified response |
| Fallback | Define behavior when a dependency fails | The fallback does not gain broader authority or silently use inapplicable evidence |
| Change control | Keep released models, rules and tools reviewable | Material changes trigger the chosen reevaluation and remain identifiable |
| Incident recovery | Resolve partial or uncertain outcomes | Operators can identify affected cases, contain new work and reconcile the destination |
These are engineering proposals for this design, not a universal legal checklist. The NIST AI RMF offers a voluntary risk-management structure, while actual obligations depend on the intended use and organization. The governance analysis connects obligations, roles and operating evidence in more detail.
Override records can make the learning loop useful. Record the proposed and final decision, the reviewer’s role, reason, material evidence and any unresolved disagreement. Distinguish correction of a model error from a policy exception, changed case fact or operational constraint. Repeated patterns can suggest a rule or model change; they do not justify automatically training on every override as if human judgment were always correct.
Change the operating model only as far as the evidence supports
Decision-centric work does not require every organization to appoint a Chief Decision Officer or replace its existing platform. Start with the owner and operating structure already accountable for the outcome. Create new coordination only where a real gap crosses those boundaries.
There are also decisions for which AI adds little value. A stable, fully specified rule may be better handled by ordinary software. A rare, highly contextual negotiation may benefit from research and preparation while remaining a human decision. The framework should help identify those boundaries rather than making every process an agent project.
For a first renewal pilot, I would want to see one complete case, one rejected recommendation, one changed-condition case, and one recovered failure, alongside the population-level measures. Those examples make the operating design inspectable. They do not replace broader testing, but they expose whether the team can connect the canvas to the service it is actually running.
Assign the operating roles before adding a new title
| Responsibility | Work to own | Boundary |
|---|---|---|
| Business decision owner | Objectives, allowed cases, tradeoffs and expansion decision | Cannot delegate accountability to a model score |
| Product/process lead | Canvas, dependencies, release scope and reviewer experience | Must resolve process changes with the people who operate them |
| Data/model lead | Sources, model evaluation and configuration changes | Technical metrics do not determine business permission |
| Risk/legal/security specialists | Applicable obligations, threat assessment and control requirements | Participation does not remove the need for a complete workflow owner |
| Platform/operations | Reliability, evidence delivery, access mechanisms and recovery | Service health is distinct from correct business outcome |
| Operator/reviewer lead | Queue capacity, correction, escalation and override interpretation | A human role needs usable information, time and authority |
An organization may combine these responsibilities or use its existing structure. If a Chief Decision Officer or decision forum is created, its mandate should include resolving ownership gaps, maintaining the portfolio, funding shared controls and reviewing material exceptions. It should not duplicate every release decision or insist on one autonomy pattern across unrelated uses.
Give the operating review a useful cadence
Daily operations may need queue ages, failed destination attempts and unresolved outcomes. A weekly workflow review can examine overrides, source discrepancies and repeated rework. A monthly business review can compare accepted outcomes, quality, costs and planned changes; portfolio decisions need the longer observation period appropriate to their value mechanism. Choose the cadence for the decisions being made, rather than filling every meeting with the same dashboard.
Several signals deserve investigation: growing bypass use, repeated evidence gaps, rising review queues, unowned exceptions and a widening difference between pilot and production outcomes. Examine model, source and workflow changes. Ask what changed, which cases are affected and whether authority should be restricted while the cause is resolved.
My longer-term ambition for a decision-centric enterprise is modest in one respect: people should be able to connect an AI investment to the work it changes and explain the important consequences. Reusable services, a decision function and stronger evidence can support that ambition. The operating structure and degree of automation should follow the decisions the organization needs to improve and the capabilities it can demonstrate.
That connection is the point of Decision Velocity. Improve the work that takes an organization from evidence to a justified decision and a confirmed outcome. The model is valuable when it helps that path work better, and the measures should be able to show where it did.
Discover more from Ajith Vallath Prabhakar
Subscribe to get the latest posts sent to your email.