The Three-Week Recommendation
A CFO I worked with last cycle had a credit-policy change in flight. The shape of the change was straightforward: tighten the underwriting threshold for a specific borrower segment by roughly 40 basis points, in response to a six-week trend in 30-day delinquencies that the risk team had flagged. The recommendation was produced by the credit-risk function, sanity-checked by an internal model, debated for ninety minutes in a Tuesday committee, and formally approved on a slide that said "Approved — implement next cycle."
That was three weeks before I spoke with him. The threshold had not moved.
When I asked him what was happening, he gave me the answer I have heard more times than I can count, in language only slightly rearranged each time. The committee approved it. The risk team thought it was Operations' job to push the change into the credit-decisioning rules. Operations thought Risk owned implementation because Risk authored the recommendation. The General Counsel had asked a clarifying question in week two about whether the new threshold needed a notice obligation under the Equal Credit Opportunity Act, and that question had not been formally answered. Nobody had stopped the change. Nobody had implemented it either. And the delinquency trend the recommendation was responding to was, as of our conversation, still running.
This is not a failure of analysis. The analysis was, by my reading of it, careful. It was not a failure of approval. The approval is on a slide. It was not a failure of technical implementation: pushing a 40-basis-point threshold change into a rules engine is a half-day of work for an engineer who has done it before. It was a failure at the seam between recommendation and decision, and that seam is governance, not analytics.
Part 1 of this series argued that information-rich organizations stall because they keep building dashboards when the cognitive job has shifted to recommendations. This article makes the next argument, which is harder to internalize: even when the recommendation surface is well-designed and well-produced, the decision still does not happen, because no one in the room is accountable for it happening. The CFO above had a recommendation. He did not have a decision. The two are not the same artifact.
The rest of this article is about why that gap is structural rather than incidental, what closes it, and three things a leader can do about it next week.
Why the Seam Is Governance, Not Analytics
The instinct in most organizations, when a recommendation fails to become a decision, is to ask whether the recommendation was good enough. Was the data clean? Was the confidence interval defensible? Did the analysis miss something? This is the wrong reflex, and it is wrong in a specific way: it sends the team back to the descriptive and diagnostic rungs of the analytics ladder to do more work, when the failure mode is one rung above.
What goes wrong at the recommendation-to-decision seam is rarely a content problem. It is an ownership problem. A recommendation without a named human owner is, by default, the property of "the team," which is to say nobody in particular. When I ask the CFO above who owns the credit-policy change as a decision (not who authored the recommendation, but who personally loses sleep if it does not get implemented), the answer he gives me is "well, ultimately me, but in practice it sits between Risk and Operations." That phrase, in practice it sits between, is the diagnostic signature of the trust gap. It does not sit between two functions. It sits inside neither of them, which is the same thing as not existing.
Two literatures converge on this point and are worth naming explicitly.
The first is the decision-rights literature. Bain's RAPID framework, which assigns specific roles for who Recommends, who provides input or Agrees, who Performs, who has Input, and who Decides, was developed precisely because Bain consultants kept watching organizations approve things that nobody then executed. The framework's insight is not that the roles need to be elaborate; it is that the D role, the single Decide role, has to be one named person, not a committee, not a function, not "leadership." A recommendation without a named D is what the credit-policy change above is: a slide. The lighter sibling RACI framework makes the same point with different vocabulary, distinguishing Responsible from Accountable to force the question of which single human carries the consequence. Both frameworks are forty years old in some form, and both were designed for exactly this stall pattern.
The second is the regulatory literature, which is converging on the same conclusion from a very different direction. The EU AI Act's transparency and accountability provisions for high-risk AI systems require that automated decisions be explainable and that a human be in a position to oversee, override, and bear responsibility for them. The Decisioning Platform research I cited in Part 1 frames this as the "No Black Box" governance pillar — the requirement that "every decision is logged, audited, and explainable to the human user," and that this auditability becomes a brand-trust pillar rather than a compliance afterthought. (Teradata's framing of the Decision Intelligence layer and 4impactdata's Decision Intelligence taxonomy both arrive at adjacent versions of the same point: as the System of Intelligence layer takes on more decision logic, the governance layer around it becomes the bottleneck.) What the regulatory frame names directly that the consulting frame implies is that auditability requires a named human owner. You cannot audit a decision back to a committee.
These two literatures are talking about the same mechanism in two registers. The consulting literature says: recommendations sit because nobody is accountable for them. The regulatory literature says: when the system gets sophisticated enough to recommend at scale, you are legally required to name the accountable human anyway. The convergence is not coincidental. It is a recognition that the recommendation-to-decision step is the highest-leverage place in the entire workflow to put a single human, with explicit authority and explicit downside.
The mechanism by which the trust gap stalls organizations is, in my experience, almost banal. A recommendation arrives at a meeting. The meeting approves it directionally. No single human in the room walks out with personal accountability for the recommendation becoming a decision. So nobody loses sleep. So nothing happens. The next meeting brings new recommendations. The previous recommendation drifts toward its own quiet expiration, often re-litigated three weeks later as if it were a new question. I have watched this pattern in credit-risk committees, in pricing committees, in vendor-selection committees, and in marketing-spend reallocations. The recommendation is not the problem. The absence of a named D is the problem.
There is a sharper version of this point that the EU AI Act forces, which I think is worth pulling out. As more recommendations get produced by systems rather than by people, the stakes of the missing D rise, because the production cost of a recommendation collapses while the implementation cost stays the same. An AI-driven decisioning surface can produce twenty well-reasoned recommendations a week per leader. If the recommendation-to-decision conversion rate is, say, 30%, the leader is now sitting on fourteen unactioned-but-approved recommendations per week. That is not a backlog; it is what an organization looks like when it has confused approval for accountability.
The fix is not better recommendations. The fix is governance, and specifically, governance at the seam.
What Decision Seeking Actually Looks Like
I want to be precise about what the governance fix looks like, because the word governance is overloaded enough to be useless. I do not mean a steering committee. I do not mean an oversight board. I do not mean a quarterly review process. I mean a specific operational pattern that sits underneath every recurring AI-recommendation surface. The pattern has three components, and I have found that all three are necessary; any one of them on its own collapses back into the trust gap.
Component one: a single named human owner. Every recurring recommendation surface (the weekly credit-policy ranking, the daily marketing-spend reallocation proposals, the monthly vendor-cost optimization view, the quarterly underwriter-cutoff review) has exactly one named human whose job description includes converting that surface into decisions. Not a function. Not a committee. A person, with a name. The person does not have to be the highest-ranked executive in the room. They do not have to be the analyst who produced the recommendation. They have to be the one who, when asked "did the decision happen?", cannot deflect to anyone else. This is the D in RAPID, named explicitly and reproducibly per recommendation surface. The Tower of Babel article earlier in the journal made an adjacent argument about how shared definitions are a precondition for cross-functional reasoning; the equivalent at the recommendation-to-decision seam is that shared accountability is a precondition for cross-functional execution. You cannot share accountability. You can only assign it.
Component two: explicit authority and explicit downside. The named owner has documented authority to act on the recommendation without re-litigating it through a committee, and documented downside if they consistently fail to act. The authority piece is straightforward and is mostly a documentation exercise: write down the decision-rights envelope ("the named owner can approve credit-policy threshold changes within ±50 basis points without committee re-review"). The downside piece is harder, and is where most organizations flinch. If the named owner faces no consequence for sitting on twenty recommendations, then naming them is a ritual. If the recommendation-to-decision conversion rate on their surface shows up in their performance review, even informally, the conversion rate moves. I cannot point you to a peer-reviewed study for this; this is a stated opinion from working with a few dozen organizations on similar questions, and I would describe it as the most consistent pattern I have observed. Authority without downside produces theater. Downside without authority produces resentment. Both have to land on the same person.
Component three: dissent on record, with rationale. This is the component organizations most often skip, and skipping it is, in my experience, how recommendations die quietly. The pattern is straightforward: every recommendation that the named owner declines to act on gets a one-paragraph written rationale. Not an objection in a meeting. Not an emoji on a Slack thread. A written rationale, attached to the recommendation in the system of record, explaining why the named owner is dissenting from this particular recommendation in this particular cycle. This sounds like bureaucracy. It is not. It is the single cheapest mechanism I know for distinguishing a thoughtful no from a passive nothing happened, and the two are radically different. A thoughtful no is a decision. A passive nothing happened is the trust gap. Without the dissent-on-record discipline, the two look identical from the outside, and the organization loses the ability to learn from either.
The dissent-on-record pattern also closes a regulatory loop that is increasingly mandatory rather than optional. Under the EU AI Act's high-risk system requirements, the audit trail for human oversight of automated decisions has to show not just that a human reviewed, but what they did and why. A recommendation that was approved-but-not-acted-on with no rationale is, under that frame, a worse audit trail than a recommendation that was explicitly declined with a written reason. The compliance frame and the operational frame point to the same artifact.
I would add a fourth component if I were writing the longer version of this argument: measured conversion rate, the fraction of recommendations on a given surface that became decisions in the cycle they were produced. I am pulling that out into the action section because it is the single most useful diagnostic instrument an organization has for finding its own trust gaps, and most organizations are not measuring it.
The pattern as a whole (single owner, explicit authority and downside, dissent on record) is what I mean by decision seeking. It is the operational counterpart to the recommendation-seeking shift described in Part 1. The recommendation surface tells the leader what to consider. The decision-seeking pattern tells the organization who is accountable for what happens next. Without both halves, the seam stays open and recommendations sit.
A note on technology: nothing about the pattern above requires new software. It requires a documented decision-rights register and a discipline about written dissent. I have watched organizations try to buy this in the form of a workflow tool, and I have watched the workflow tool turn into another dashboard that nobody acts on. The substrate matters less than the contract.
What I do not yet know
I have watched the dissent-on-record discipline work in three engagements I can think of clearly. I have also watched it fail in one: a vendor-selection committee where the explicit dissents became a paper trail used to re-litigate decisions in subsequent cycles, which produced more theater, not less. The mechanism that made it fail is not yet clear to me.
My current hypothesis is that the discipline only works when paired with a hard cycle deadline. The recommendation either becomes a decision in the cycle it was produced or it expires. When the deadline is soft, the dissent paper trail becomes raw material for re-litigation rather than a forcing function. I am running a small version of this experiment in a current engagement to see whether the hard-deadline version holds under stress.
If you have run this kind of governance pattern and have a counterexample, either a hard-deadline version that failed or a soft-deadline version that worked, I would genuinely like to hear it. The mechanism behind why one version converts and another does not is the kind of thing where operator notes from a half-dozen people are worth more than a literature review.
What's next in the series
→ Part 1: From Dashboards to Recommendations. Why information-rich orgs stall.
→ Part 3: The Last Mile is Action. Closing the decision-to-execution gap.
→ See the full framework: The Decision Effectiveness Framework.