Leadership, governance and adoption
AI Killed the Concept of the Minimum Viable Product
Seek the Minimum TRUSTED Product to Achieve AI Solution Uptake
The promise of Artificial Intelligence in the public sector is not merely the automation of tasks; it is the responsible delegation of cognitive labour. As executives and business architects, we invest in these technologies with a specific strategic intent: to allow human expertise to be re-allocated from routine data processing to high value adjudication and complex problem-solving.
However, this transfer of duty relies entirely on one metric: Trust.
A popular solution development approach is to develop and deploy a Minimum Viable Product (MVP). In traditional IT development, the MVP is a proven strategy. It focuses on delivering the smallest set of features necessary to go live, gathering user feedback, and iterating. "Viability" in this context is binary: does the software function? Does the button submit the form? Does the database store the record?
But when we apply this binary logic to the probabilistic world of AI, we encounter a dangerous failure mode.
In the context of government decision-making, an AI solution that is merely "technically viable" is often operationally useless. For example, if a predictive model for Grants and Contributions (G&C) screening is "live" but produces an error rate that makes the human user uneasy, we have not created efficiency. We have created a parallel workload.
Consider the operational reality on the floor. If a user cannot trust the AI’s assessment to be correct within a known, specific margin of error, they will feel compelled to re-verify the AI's work themselves. The computation cost is incurred, but the human labor cost is not reduced.
This is the MVP Trap in government AI. We declare victory because the system is deployed and technically functioning, yet the realized return on investment (ROI) is negative because the "Trust Threshold" was never met. The human user has not delegated the task; they have simply added "checking the robot" to their list of duties.
To realize the true value of AI, in the GC, we must refine our architectural standards. We must stop defining our rollout strategies by what the software can do, and start defining them by what the human is willing to stop doing. This requires a fundamental shift from building a Minimum Viable Product to delivering a Minimum Trusted Product (MTP).
The distinction is not semantic; it is structural. An MVP asks, "Does it run?" An MTP asks, "Is it accurate and explainable enough for an executive to defend the delegation of this decision?" Until we answer the second question, we remain stuck in a cycle of shadow verification, where AI serves as a novelty rather than a capacity multiplier.
The Hidden Cost of 'Shadow Verification'
To understand why the MVP model fails in high-stakes government environments, we must look at the workflow from the perspective of the individual public servant.
When we introduce an AI solution that is merely "viable"—meaning it functions technically but lacks a proven, high-fidelity trust metric—we place the employee in an impossible position. They are armed with a new tool, but they remain bound by their Duty of Care.
If an analyst knows that an AI tool has a "viable" but imperfect accuracy rate (e.g., 60%), they cannot ethically or procedurally rely on its output for critical decisions. The risk of a False Negative (denying a benefit to an eligible Canadian) or a False Positive (approving a fraudulent claim) is too high.
Consequently, the analyst adopts a behavior I call Shadow Verification. They run the AI, receive the recommendation, and then proceed to perform the full manual assessment anyway to confirm the result. The AI has not replaced the task; it has merely added a step to the process.
Case Study: The Grants & Contributions Paradox
Consider a hypothetical Grants & Contributions (G&C) program designed to screen incoming funding applications.
The MVP Approach: An AI model is deployed to "triage" applications, flagging them as Red (High Risk) or Green (Low Risk). The model is "viable" because it integrates with the Case Management System and processes files overnight.
The Operational Reality: A Senior Program Officer receives a file marked Red. Because the model has not been certified as a Trusted Product (proven to have a lower error rate than human review), the Officer cannot simply reject the file. They must open the documents, review the submission, and document their rationale to ensure procedural fairness.
The Result: The Officer spends 45 minutes reviewing the file. This is the exact same amount of time they would have spent if the AI didn't exist.
In such an MVP deployment where trust is low, the manual effort saved is zero, while the overhead of running the system increases. The solution is technically a success (it runs bug-free), but operationally a failure (it doesn't save time).
This dynamic reveals the central flaw of applying startup logic to government operations: Adoption is not the metric; Delegation is. Until the solution is robust enough for the human to stop doing the work, we have not achieved value.
Defining the Minimum Trusted Product (MTP)
If "Viability" is the wrong standard for AI in government, what is the right one?
An Minimum Trusted Product (MTP) is not just a model that "runs"; it is a model that a human is willing to stop double-checking. For a solution to cross the threshold from MVP to MTP, it must satisfy three operational pillars that are specific to the public sector context:
Variance Control (The "Better Than Human" Test): The AI’s error rate must be quantified, stable, and demonstrably lower than the historical error rate of the human process it augments. If we cannot prove the AI is more accurate than the tired analyst at 3:00 PM, we have no business asking the analyst to trust it.
Explainability (The "Audit" Test): The system must provide a rationale for its output that satisfies a future Access to Information (ATIP) request. In government, a "black box" prediction is a liability. Trust requires that the "Why" be as accessible as the "What."
Risk Alignment (The "AIA" Test): The level of trust required must scale with the consequence of the decision.
This third pillar is where we leverage existing government architecture. The Treasury Board’s Directive on Automated Decision-Making provides the framework we need via the Algorithmic Impact Assessment (AIA). The MTP threshold is not static. For a Level I decision (Internal Services), the trust bar is lower. For a Level IV decision (Benefits Determination), the MTP standard requires near-perfect explainability and human-in-the-loop fail-safes.
The Architectural Shift: MVP vs. MTP
For the executive, the shift to MTP requires a change in the questions we ask at the project board level. We must stop asking "Is it done?" and start asking "Is it trusted?"
The following matrix contrasts the two approaches:
The bottom line: An MVP is a technical milestone. An MTP is a business outcome
Robust Evaluation as an AI ROI Strategy
If the goal is the Minimum Trusted Product, then the mechanism to achieve it is Robust Evaluation.
In traditional software development, "testing" is often a functional checklist: Did the user log in? Did the page load? If the code executes without crashing, it passes Quality Assurance.
With AI, this functional approach is dangerously insufficient. An AI model can run perfectly, executing code and consuming resources, while being completely wrong. To build an MTP, we must elevate "Evaluation" from a technical QA task to a strategic business gatekeeper.
To certify a product as "Trusted," evaluation must be adversarial. We must actively try to break the model by feeding edge cases, complex files, and other anomalies that typically trip up junior analysts. Furthermore, the model's performance must be benchmarked directly against human performance.
Conversely, in an MVP culture, a "good enough" model is often released with the promise of patching it later. In an MTP culture, the Evaluation Phase is a hard gate. If the evaluation metrics (Precision, Recall, Fairness) do not meet the pre-defined Trust Threshold, the solution does not deploy.
This rigour is the only way to avoid the "Shadow Verification" trap. By holding the line at the Evaluation Gate, we ensure that when the tool finally reaches the hands of a user, it is an asset they can rely on, not a guess they have to double-check.
The Prize: Reallocating Human Intelligence
Why does this distinction between MVP and MTP matter? It matters because the "Trust Gap" is the single greatest bottleneck to realizing the workforce benefits of AI.
The strategic intent of AI in government is not about replacing employees. It is about solving the capacity crunch. We are asked to deliver more services, with greater speed, to a growing population, often with flat or shrinking budgets. The only way to solve this equation is to radically reallocate where our human talent spends its time.
This is where the MTP becomes the key to workforce strategy. It allows us to shift the role of the employee from Verifier to Adjudicator.
In an MVP scenario, where trust is low, the employee acts as a Verifier, spending their day checking the machine's judgement. This is a low-value, high-fatigue role that leads to burnout.
In an MTP scenario, where trust is established and quantified, the employee evolves into an Adjudicator. Because the AI is trusted to autonomously handle the routine, low-risk cases, the human officer's day is now dedicated to the complex, nuanced, or high-risk cases that require human empathy and judgment.
We often speak of "Human in the Loop" as a safety mechanism. Under the MTP framework, we refine this. The human shouldn't be in the loop for every decision; they should be the Escalation Point for difficult decisions.
The Executive Mandate: Trust as Currency
As we navigate the adoption of Artificial Intelligence across the Government of Canada, we stand at a critical architectural juncture. We can continue to apply the "software mindset"—prioritizing speed and the Minimum Viable Product—and risk building a digital infrastructure that our employees are afraid to use. Or, we can pivot to the "delegation mindset," prioritizing accuracy, explainability, and the Minimum Trusted Product.
The shift to MTP requires a different mindset. It requires leaders to delay a launch because trust metrics are insufficient, even if the code works. It requires Business Owners to demand robust, adversarial evaluation against ground-truth data before they sign off on User Acceptance.
For the public service AI investment leaders, the path forward is clear. In your next Steering Committee, change the interrogation:
Stop asking: "Is the solution live?" or "Are the features complete?"
Start asking: "What is the calculated error rate compared to our human baseline?" and "Is it trusted enough to delegate the decision?"
When we insist on the Minimum Trusted Product, we uplift our workforce by removing the drudgery of verification, and we preserve the public trust by ensuring that the algorithms serving them are accurate, fair, and accountable.
Originally published on LinkedIn, December 8, 2025.