Approve the Workflow, Not the Model

TL;DR for operators

Enterprise AI approval should attach to the complete workflow configuration, not to a model name or benchmark score. EnterpriseVal formalizes that idea by freezing the model, prompts, retrieval or memory, tools, guardrails, logging, and human-review design before evaluation.

The framework then tests six families of evidence—fidelity, utility, efficiency, reliability, assurance, and oversight—and uses precommitted thresholds with uncertainty to classify a workflow as Reject, Conditional, or Scale. Only candidates that survive those risk gates should be ranked, and the preferred candidate can change when the business changes the relative importance of its metrics.

Passing the technical gate is not the end of the decision. EnterpriseVal separately asks whether labour and quality benefits exceed inference, integration, review, rework, and residual-error costs.

Its bank pilot shows that this process can be put into practice. It does not yet show that the reported gates are statistically qualified, that one tested model is generally superior, or that the estimated productivity gains translate into realised value.

A benchmark winner may not be the workflow you should approve

Consider an enterprise team choosing between two GenAI candidates for the same credit workflow. One produces fewer unsupported statements. The other retrieves more required guidance. Their prompts may differ, their retrieval systems may expose different evidence, and human reviewers may catch errors at different rates.

Choosing the higher model score does not resolve the deployment decision.

The relevant object is the working system that employees and customers will actually encounter. EnterpriseVal¹ makes this explicit. It represents the evaluated configuration as the model and sampling settings, prompts and policies, retrieval and memory, tools and permissions, guardrails and verification, logging, and human roles. That configuration is frozen for the evaluation. Change one of those components, and the paper’s logic treats the result as a different system requiring renewed evidence.

This matters because enterprise risk often resides in interactions among components. A capable model paired with weak retrieval can cite the wrong evidence. A strong generator paired with poor escalation rules can send questionable outputs farther into a process. A nominal human-review checkpoint contributes little if reviewers rarely detect the errors that matter.

The approval target is therefore a frozen socio-technical configuration: the full deployable workflow rather than an isolated model.

Scale requires every material risk metric to clear its threshold

Once the whole workflow becomes the unit of evaluation, a single aggregate quality score becomes difficult to justify.

EnterpriseVal organizes evidence into six families:

The framework does not allow exceptional performance in one family to compensate automatically for failure in another. Instead, material metrics receive an outer minimum threshold and an inner scale-ready threshold fixed before results are unblinded.

The proposed gate is conjunctive. Scale requires the conservative confidence bound for every gated metric to clear its inner threshold. Conditional means all metrics clear the outer threshold but at least one misses the inner threshold. Failure of an outer threshold produces Reject.

That design changes the governance question from “Which candidate has the highest score?” to “Has this particular workflow produced enough evidence to remain inside every material risk tolerance?”

The distinction is especially relevant when more autonomous or consequential systems are evaluated. EnterpriseVal increases required evaluation intensity with autonomy and consequence and extends higher-autonomy evaluation toward trajectories, tool failures, recovery behaviour, policy violations, interventions, and cost per successful task. Those agentic extensions are proposed rather than validated in the bank pilot.

Ranking comes after risk acceptance

The credit-memo pilot illustrates why gating and ranking should remain separate.

Human grading produced the following point estimates:

There is no universal winner in those numbers. Gemini leads on several fidelity-oriented measures; Llama leads substantially on guidance recall.

EnterpriseVal makes that dependence explicit through its Efficacy Index, which normalizes performance relative to the precommitted thresholds and then applies charter-defined weights. Under equal weights, Llama 4 ranked higher, 2.59 versus 2.45. When the weights shifted toward fidelity, Gemini 2.5 ranked higher, 2.62 versus 2.37.

For an enterprise buyer, that reversal is more informative than declaring either model “best.” Candidate preference depends on what the workflow is required to protect after minimum risk tolerances have been satisfied.

But the pilot cannot support a statistically qualified model-selection conclusion. The human-graded results lack reported sample sizes, confidence intervals, and inter-rater agreement statistics, and harness parity between the two model configurations was not documented. The paper therefore treats its point-estimate gate labels as illustrative rather than as completed deployment approvals.

Human review is a measured control, not a safety assumption

Enterprise deployment discussions often treat “human in the loop” as a control category. EnterpriseVal instead tries to make the control measurable.

Its oversight metrics include reviewer catch rate, false acceptance rate, unplanned intervention rate, and review burden. Reviewer performance then enters the proposed residual-risk calculation: a workflow with a given hallucination rate can leave very different residual exposure depending on how reliably reviewers detect those errors.

That creates an operational trade-off. Reducing review time improves the apparent labour case, but if a lighter review process lowers the catch rate, residual expected loss can increase.

For Cognaptus operators, the useful inference is that human oversight should be evaluated as part of the system architecture. The questions are not merely whether review exists, but which errors reviewers detect, how often they miss them, and how much capacity the review process consumes.

The bank pilot does not yet validate this residual-error approximation. It specifies the measurement problem more clearly than it resolves it.

Technical efficacy and economic value are separate gates

The same discipline applies to productivity claims.

In the procedure-transformation pilot, estimated manual effort averaged 27.4 hours per document across ten procedures. Refinement after pipeline v1 averaged 10.6 hours. For the seven procedures with v2 outputs, estimated manual effort averaged 25.0 hours and refinement averaged 2.9 hours—an 88% like-for-like reduction against that subset’s estimated manual baseline.

That is potentially material. It is not an observed causal productivity estimate.

The manual baseline was retrospectively estimated rather than directly timed, v2 covered seven documents, and the procedure experiment did not include fidelity grading. Lower refinement effort alone therefore cannot establish positive business value.

EnterpriseVal’s broader value model is designed to prevent that shortcut. Annual value adds labour-time savings and possible quality or avoided-loss benefits, then subtracts inference, integration, human review, rework, and expected residual-error loss.

This ordering matters. A workflow can clear quality requirements and remain uneconomic. It can reduce drafting time while creating expensive review work. It can also appear inexpensive until residual-error exposure is included.

For a scaling decision, technical efficacy, human-control performance, and economic value are related conditions rather than substitutes.

The pilot validates operability, not the gate itself

The strongest empirical conclusion from the paper is narrower than its framework.

Three heterogeneous functions inside a large regulated bank were able to define workflow-specific tasks, gold artefacts, metrics, thresholds, and governance outputs. That is evidence that the methodology is operationally implementable rather than merely conceptual.

Several validation steps remain open. The pilot does not provide statistically qualified gates, documented repeated-run reliability results, realised business value, or an exercised high-autonomy agentic evaluation. The procedure baseline is estimated, the credit-model comparison lacks harness-parity documentation, and the study comes from one institution with small workflow-specific task sets.

The method also assumes that defensible gold artefacts can be specified. That fits document-grounded workflows better than open-ended advisory tasks where acceptable answers may legitimately diverge.

EnterpriseVal should therefore be read as a structured decision protocol with preliminary operational evidence, not as a validated universal benchmark or a cross-company leaderboard. Its thresholds, weights, and gold evidence are deliberately firm-specific.

The practical contribution is the sequencing: define what is being deployed, freeze it, decide what failures matter, set thresholds before observing results, measure uncertainty and human controls, rank only acceptable candidates, and then ask whether the surviving workflow has positive value after its remaining risks and costs are priced in.

That is a more demanding standard than selecting the strongest model score. For consequential enterprise workflows, it is also much closer to the decision the organization actually has to make.

Cognaptus: Automate the Present, Incubate the Future.