Most enterprises govern machine-learning models as technical assets. Yet the financial, operational, legal and human consequences arise from the decisions those models are permitted to trigger. That distinction is now a C-suite accountability issue.
Credit models, fraud models, clinical risk models, pricing models and eligibility models have been shaping consequential decisions for years. Their outputs usually arrive as clean, precise numbers, which makes it easy to miss the harder question: what is the organization actually allowed to do with that estimate?
Classical machine learning and generative AI look different at the surface, but both are forms of probabilistic AI. Both produce estimates, and both leave the organization responsible for deciding what those estimates are allowed to do. That is why WEKID applies just as directly to a risk score as it does to an answer from a language model.
A model may be accurate enough to flag a transaction or recommend an intervention and still lack the authority to deny a benefit, interrupt care or shut down a production line. The same model can support several decisions while requiring a different level of human control for each one. The WEKID framework is an open governance standard built on five epistemic layers: Data, Information, Knowledge, Experience and Wisdom. It separates the questions of evidence and authority through two models. The Epistemic Maturity Model evaluates the evidence behind the output, and the AI Decision Authority Model determines how much action that evidence can support once consequence, reversibility and accountability are considered.
Between the two sits what WEKID calls the Trust Bridge. It is the point where an output is brought together with its evidence, assumptions, uncertainty and intended action before anyone decides how much authority to give it.
This article stays with conventional predictive systems rather than language models or agents. It covers what the Epistemic Maturity Model scores when the output is a number, how the Trust Bridge evaluates a prediction with no reasoning attached, and how decision authority is assigned when one model supports decisions with very different consequences.
What the record actually shows
Start with the record, because the argument only works if the cases carry it.
The WEKID Failure Library catalogs 45 publicly documented incidents across 24 sectors, each mapped to the layer where the knowledge broke down and the authority outcome the framework would have produced. The cases people reach for when they talk about AI failure are the generative ones, the fabricated citations and the chatbot handing out advice it had no business giving. Those are the visible end of the catalog. They are not the expensive end.
The six cases that follow were chosen using one rule: no language model appears in any of them. Every one is a conventional predictive system of exactly the sort most enterprises already run in production. Read them watching for one thing: where did each case actually break? In most of them, accuracy was not the primary failure. Even where model performance was poor, the larger breakdown occurred upstream in the evidence or downstream in the decision process.
Organization names are masked in the public catalog so the focus stays on the governance lesson rather than the organization. The named organizations, individuals, sources and timelines sit in the Executive Brief. Each case below links to its full entry.
WF-038, Overreliance on a Flawed Prediction Model, is the one I'd pin above every model risk desk. A proprietary sepsis-prediction algorithm, embedded directly in an electronic health record and running at hundreds of hospitals, was externally validated by researchers who had not built it. The vendor reported an AUC of 0.76 to 0.83. AUC is a common measure of how well a model separates higher-risk from lower-risk cases, with 1.0 representing perfect separation and 0.5 little better than chance. Measured independently, the model came out at about 0.63. It missed roughly 67% of sepsis cases while generating alerts on about 18% of all hospitalizations, often too late to be useful, which worked out at roughly 109 alerts to catch a single missed case. The catalog files it as an Information-layer failure: poor-quality signals entering high-stakes clinical workflows without sufficient local validation.
WF-003, Automated Hiring and Screening Bias. An experimental recruiting tool, trained on about ten years of past résumés drawn from a predominantly male applicant pool, learned to penalize résumés containing the word "women's" and to downgrade graduates of two all-women's colleges. The team edited out those specific terms, then lost confidence the model was neutral anywhere else, and scrapped it. The failure pattern the catalog records is exact: misinterpreted historical data embedded in decision logic. The model was inferring future fitness from past selection, which is a different quantity wearing the same name.
WF-005, Government Benefits Eligibility Errors. A state unemployment system made 40,195 fraud determinations by algorithm alone across roughly two years, with a state-reviewed error rate around 85%. A later Auditor General review of a 22,000-case sample found that about 93% involved no actual fraud. Quadruple penalties, garnished wages, seized tax refunds, ruined credit, bankruptcies, foreclosures. The catalog treats it as an Experience-layer failure and the reasoning deserves quoting: scale magnifies the cost of being wrong, and the faster a system acts, the more important it is that it can recognize what it does not know.
WF-015, Correct Predictions Applied Beyond Their Authority. Algorithmic home-value forecasts used to buy houses at scale. The models performed acceptably in stable conditions and deteriorated once the market turned volatile, by which point the business had overpaid for thousands of homes. Roughly $881 million of losses on the iBuying operation, a $304 million inventory write-down in a single quarter, and about 2,000 jobs. The governance interpretation is the cleanest statement of this article's whole thesis that I've seen anywhere: the model was not necessarily broken, its decision rights were.
And then two from opposite ends of the economy with an identical shape. WF-006, Predictive Policing and Risk Scoring, covers recidivism and hot-spot scores deployed into law-enforcement and judicial settings without adequate transparency, appeal, or contextual interpretation. WF-050, Algorithmic Denial of Post-Acute Care, covers a predictive tool used to determine when patients should stop receiving post-acute care, where the complaint alleged that roughly nine of every ten appealed denials were overturned, and that only about 0.2% of denials were ever appealed at all. Criminal justice and health insurance have almost nothing in common operationally. Both cases are the same failure: a population-level prediction used to override an individual judgment.
The table below separates what each model produced from what the enterprise allowed that output to become. It shows that the decisive breakdown was rarely the algorithm itself: the failures occurred when historical patterns were mistaken for knowledge, vendor performance was accepted without local validation, operating controls arrived too late, or probabilistic scores were granted more decision authority than the evidence and consequences justified.
| Case | The model was | What actually failed | Layer |
|---|---|---|---|
| WF-003 Automated hiring and screening bias | Learning the historical data faithfully | Past selection inferred as merit, then embedded in decision logic | Knowledge |
| WF-038 Overreliance on a flawed prediction model | Reported by its vendor at 0.76 to 0.83 AUC | Independently measured at 0.63, with no local validation before deployment | Information |
| WF-005 Government benefits eligibility errors | Applying its rules exactly as written | Verification and appeal arrived after the consequences did | Experience |
| WF-015 Correct predictions applied beyond their authority | Acceptable in the conditions it was built for | Prediction confidence mistaken for decision authority | Wisdom |
| WF-006 Predictive policing and risk scoring | Producing probabilistic risk scores | Those scores treated as actionable judgments, with no route of appeal | Wisdom |
| WF-050 Algorithmic denial of post-acute care | A population-level prediction | Used to override an individual clinical judgment | Wisdom |
Look closely at the final column. It identifies where each failure occurred in the WEKID hierarchy, and none originated as a simple accuracy problem. One failed at Information, one at Knowledge, one at Experience, and three at Wisdom. In those three cases, the model itself was not the primary failure; the enterprise decision boundary was.
Which means the reflex response, which is a better model, a bigger model, or a fairness metric bolted onto the evaluation script, is aimed squarely at the part of the problem that was already under control.
The academic record points in the same direction, although it describes the problem in technical terms that can make it sound narrower than it is. D’Amour and colleagues called it underspecification: two models can achieve almost identical results on a held-out test set, meaning data deliberately withheld from training, and still behave very differently when conditions change. A strong benchmark score therefore does not establish that the model learned the relationship the organization believes it learned. Geirhos and colleagues described the related problem of shortcut learning, in which a model succeeds by exploiting an easy correlation rather than the durable signal its builders intended. The prediction may look sound until the shortcut disappears, reverses or reaches a population in which it never held.
Other findings locate the same weakness elsewhere in the pipeline. Kapoor and Narayanan showed how data leakage can produce apparently impressive results by allowing information about the outcome to enter the model before that information would have existed in real use. Sculley and colleagues described the operational fragility of machine-learning systems as CACE, or changing anything changes everything: a new feature, retraining run, data source or threshold can alter behavior elsewhere in the system and invalidate evidence gathered against the previous release. Sambasivan’s work on data cascades showed how weaknesses in collection, labeling and representation compound as they move downstream, often surfacing only after deployment because attention and investment concentrate on the model rather than on the evidence beneath it.
The vocabulary differs from the language used around generative and agentic AI. Traditional machine-learning research talks about underspecification, distribution shift, shortcut learning, leakage and data cascades. Agentic-AI discussions are more likely to talk about hallucination, tool misuse, context failure, guardrails and excessive autonomy. Those labels can lead organizations to treat these as separate governance problems and build one control system around model performance and another around agent behavior. But the terms identify failures at different points in the same sequence: inputs are accepted as evidence, that evidence is used to form a prediction or conclusion, and the result is granted authority to affect the world.
That is the comparison being made here. It is not a claim that a predictive model and an autonomous agent work the same way. It is a comparison between the evidence supporting their outputs and the decision authority an organization grants those outputs. In both cases, the governance failure occurs when capability moves ahead of the evidence, experience and judgment required to bound it.
Probabilistic by construction
This pattern is not accidental. It follows from the nature of machine learning itself: a probabilistic estimate becomes consequential only when an organization connects it to a decision.
A deterministic system encodes rules that a person wrote. If X, then always Y. You use it where the rules are known. Machine learning gets used precisely where they aren't, where the phenomenon is too complex or too noisy or too incompletely observed for anyone to write them down, and what it produces in place of a rule is a likelihood. A vision model doesn't know there's a cat in the image. It assigns the image a score that may be interpreted as a 94% probability, provided the model has been properly calibrated. A forecast doesn't promise rain, it puts 70% on it. That isn't a limitation of current technique. It's the reason the technique is being used at all.
Three things follow, and each one lands on a different layer.
The training process includes randomness. Most models learn by repeatedly adjusting themselves against shuffled portions of the data. The route to the final model is partly random by design. Train the same design on the same data twice and you can get two models that draw slightly different boundaries and behave differently when they encounter something new. They aren't two copies with different serial numbers. They are two different models. This is why Experience can't simply be inherited after retraining, and why a retrained model is a new release rather than a patch.
Classification is a probability plus a threshold, and the threshold is a human artifact. The model scores an email at 0.85. Whether that email lands in the spam folder depends on a number somebody chose, whether that's 0.5 or 0.7 or whatever survived the last argument about false positives. The estimate belongs to the machine. The cut belongs to the organization, and it encodes an entire position on the relative cost of the two kinds of error. It's almost never documented as a decision, almost never revisited, and almost never owned by anyone still on the team. In WEKID terms a threshold isn't configuration. It's the exact point at which evidence gets converted into authority, and it deserves to be governed like one.
Generative AI shares this probabilistic foundation. A language model generates text by calculating a probability distribution over possible next tokens and selecting from it. That's what everything above describes, at a different scale and behind a rather more conversational interface. The distinction people routinely draw between "AI" and "just machine learning" isn't a distinction between a probabilistic system and a deterministic one. It's a distinction between two probabilistic systems, one of which hides its uncertainty behind fluent prose while the other hides it behind a nice clean number.
Which brings us to the exception, and the exception is where the trap is.
Many trained models are configured to behave deterministically when generating a prediction. With the model version, inputs and operating environment held constant, the same input produces the same score. The same can be true of a language model configured always to select its most likely next word. This consistency is real and useful because it makes repeatable testing possible. It's also one of the most misleading facts about deployed machine learning.
Because reproducibility of the score gets read as reliability of the decision. The pipeline is deterministic. The logs are deterministic. The score is stable and the service never throws. None of which tells you anything at all about whether the estimate is any good, whether the record being scored resembles anything in training, or whether the quantity being estimated is the quantity anybody actually cares about. A deterministic wrapper around a probabilistic estimate doesn't remove the uncertainty. It makes it invisible, and it makes the whole apparatus look like a rules engine to everyone standing downstream of it.
| Property | Deterministic rule engine | Machine learning system | What the framework does about it |
|---|---|---|---|
| Origin of the logic | Written by a person who can be asked why | Estimated from data by a process nobody observed | Data and Information become scored layers rather than assumptions |
| Repeatability of the build | Same code, same behavior | Same data, no fixed seed, different model | A retrain is a new artifact, and the authority grant restarts at zero |
| Nature of the output | A determination | A likelihood, plus a threshold somebody chose | The threshold is where evidence becomes authority, so it gets governed as a decision |
| Behavior when wrong | Fails visibly, throws, rejects, halts | Returns a well-formed, confident, wrong number | Gates get scored in advance, because they can't work as exception handlers |
| What it can certify about itself | That the rule was applied as written | Only that the computation ran | Self-attested evidence can inform, but it cannot authorize action |
None of this is an argument against probabilistic systems. It's an argument that you can't govern a probabilistic system with the controls built for a rules engine, and that most enterprise ML is governed today by exactly those controls. The service is available, responds quickly, accepts data in the expected format and produces no software errors. Every one of those indicators can report green while the model is quietly wrong.
Why only one of them gets the attention
If they're the same paradigm, it's worth asking why the governance conversation only really covers one of them. The answer isn't technical. It's about how each one reached people.
Large language models arrived as a consumer product, in a search box, and that lineage matters more than it usually gets credit for. The interface people were handed was the one they already used to look things up, so they judged it the way you judge a search engine, which is by asking whether it gave them the right answer. Hundreds of millions of people used one, and a fair proportion of them personally watched it be confidently, fluently wrong. AI failure stopped being an abstraction in a policy paper and became something you could experience over a coffee.
That's healthy in one way and quietly distorting in another. Everything about that experience is visible, individual, immediate and reversible. You see the output. You're the person who asked for it. You can tell when it's wrong, push back on it, or just ignore it. The cost of the error lands on you, and it's usually small.
Classical ML has none of those properties, because it has no consumer surface at all. Nobody opens a credit risk model. It reaches people through an institution, so through a bank, an insurer, a hospital, an employer or a benefits agency. The procurement is business to business and the consequence is business to consumer, and the two ends of that never meet. You're the subject of the decision without being the user of the system. You don't see the score, you frequently don't know a model was involved, and there's no regenerate button on a declined application.
The asymmetry that actually matters is volume and direction. A language model gets one answer wrong for one person, who then asks again. An enterprise model applies the same inference uniformly, in the same direction, to everybody who matches the pattern, thousands of times a day, without variation. Consistency is a virtue in software and a hazard in judgment. Forty thousand fraud determinations in WF-005 were not forty thousand independently reasoned decisions. They were one flawed decision process applied forty thousand times. And none of the cases in this article were consumer AI failures, which is precisely why they took years to surface and cost so much more by the time anybody noticed.
So the agenda we've ended up with covers hallucination, provenance, watermarking and content safety. All of that is real and worth doing. Almost none of it asks whether a model was entitled to make a decision about someone in the first place. The visible failures set the agenda. The consequential ones didn't get a vote.
The number that looks like a decision
If they're the same paradigm, governing them still differs in one respect, and it's a difference of surface rather than substance.
A generative output is an artifact you can argue with. It has claims in it, and hedges, and stated assumptions, and a visible chain of reasoning that may well be wrong but is at least there. The Trust Bridge parses that surface: claims, recommendations, procedures, assumptions, tool outputs, uncertainty markers. There's something to take apart.
A machine learning output is a float. It has no surface at all. It arrives with no hedge, no assumption, no stated scope, and no hint whatsoever that the record being scored sits outside anything the model has ever seen. It's small, it's clean, it's well formed, and it looks exactly the same when it's wrong.
That's why the seam closes. In a generative system there's visible distance between the output and the action, because somebody has to read the output. In an ML system the distance is a line of code, if score > 0.7, and once it's written nobody ever looks at it again. The judgment has been made permanently by whoever set the threshold, and it appears nowhere in the record.
A probability is not a judgment. It's evidence about a judgment, and the moment it's wired to an action the judgment has already been made by whoever wired it.
WEKID's own Failure Library names this one directly. Among the recurring Wisdom layer patterns it catalogs is treating probabilities as judgments. That isn't a description of a language model. It's a description of a logistic regression connected to a decline letter. The governance note on WF-006 puts it in six words: probabilities are not verdicts, and a system that cannot tell the two apart should not hold authority anywhere a verdict is required.
What the Trust Bridge parses when the output is a number
The way out is to recognize that the parsed object in classical ML isn't the prediction. It's the decision unit, meaning the prediction bundled together with the evidence that gives it any standing. Every component of the generative parse has an exact counterpart. It just has to be assembled deliberately rather than read off the output.
| Trust Bridge component | Generative system | Classical ML equivalent |
|---|---|---|
| Claim | An asserted fact in the text | The point prediction or class label |
| Uncertainty marker | Hedging, stated confidence | The probability assigned, the expected range of error, and how much several versions of the model disagree |
| Assumption | An unstated premise behind the answer | Whether this case resembles the people, events or conditions represented in the training data |
| Tool output | Retrieval hit, API result | The input values and a trace back to the source systems from which they came |
| Reasoning trace | The stated chain of argument | Which inputs most influenced the prediction, and whether that explanation remains stable after retraining |
| Recommendation | The proposed course of action | The business rule the score is about to trigger |
The cadence changes too, and this is where most implementations come unstuck. A generative output gets scored each time because every response is a fresh artifact. Many properties of an ML model can be judged only across a group of predictions over time, not from one prediction in isolation. You cannot detect drift, meaning a meaningful change in the data or operating conditions, from a single record. The workable pattern therefore uses two clocks: periodic scoring of the model and the population it serves, plus an efficient check on every prediction. That per-record check asks whether confidence clears the approved threshold, required inputs are present and current, and the case resembles the conditions represented in the training data. Everything else gets established upstream, and then it expires.
The five layers, scored against pipeline evidence
The Epistemic Maturity Model, Model One in the WEKID standard, scores the artifact across five layers: Data, Information, Knowledge, Experience and Wisdom. It gates rather than averages. No layer is allowed to sit more than one rung above the layer beneath it, and the weakest layer binds the result. Polished validation documentation can't rescue an unsound inference, and a sound inference can't rescue a fabricated label. A hard gate is a requirement that must be satisfied before an output can advance to the next WEKID layer. Strong performance elsewhere cannot compensate for failing that requirement.
Data, or are the inputs what they claim to be
Start with the inputs. Are they in the expected format? Are missing values visible, or quietly being filled with defaults? Did every input exist at the moment the real decision would have been made? Does production data still resemble the data used for training? Can every input be traced back to its source? This is where data leakage lives, meaning information the model would not have had in real use slipped into training or testing. Leakage is one of the most common reasons a model looks excellent in development and turns out to be worthless in production.
Hard gates: production inputs no longer match what the model was trained on, information about the outcome leaked into the inputs, a data source can't be traced, or missing values are silently treated as zero.
Information, or does the data mean what the model assumes it means
This is the layer nobody staffs, and the one WF-038 was filed under. It covers the gap between the thing an organization wants to know and the measurable substitute used to train the model. Fraud is not the same as a chargeback was filed. Equipment failure is not the same as a work order was raised. Patient need is not the same as cost. It also asks whether the people, sites or operating conditions now being scored resemble those represented in training.
Hard gates: the model is applied to a group or setting outside its training experience, the measurable substitute no longer represents the real outcome, or an input is older than the organization has said it may safely be.
Knowledge, or is the conclusion sound and bounded
It isn't enough for the model to rank higher-risk cases above lower-risk ones. Its probabilities also have to mean what they say. If a model assigns 70% risk to a group of cases, roughly seven in ten should produce the outcome. That's calibration, and it has to be checked for meaningful groups rather than only across the whole population. Testing should also remove or vary important inputs to see whether the model is relying on a shortcut. And the organization needs a written statement of where the model may be used, because two models with the same test score may behave very differently outside the conditions in which they were tested. The explanation matters too. If retraining changes which inputs appear to drive the result, the organization should not pretend that either explanation is settled knowledge.
Hard gates: the prediction depends mainly on a misleading substitute for the outcome, predicted probabilities stop matching real outcomes for a deployed group, or the model is used outside its documented bounds, such as moving a global model into a distinct local market or transferring it to a new hospital, plant or asset class without validation.
Experience, or has it actually been operated
This is the pivot, and it's the layer most ML programs skip entirely. Test the model against a full business cycle, including the difficult periods rather than only the convenient window. Run it in shadow mode, making predictions on live activity without allowing those predictions to trigger action. Compare the current model with a credible alternative. Test what happens when an input service fails or a sensor drops out. Most importantly, capture what happened after deployment and connect those outcomes back to the model's decisions. Laboratory results are not operating experience.
A digital twin can strengthen this evidence by allowing a model to operate against a realistic representation of the business environment before it is given authority over the real one. The twin can expose the model to complete business cycles, stressed conditions and rare events that may not appear during a convenient validation period. It allows the organization to observe how the model and the surrounding decision process behave without placing customers, operations or assets at risk.
But evidence from a digital twin is still point-in-time evidence. As customers, processes, data and operating conditions change, the model should be tested again against the twin and compared with live performance. Otherwise, the organization may continue relying on a decision system whose supporting evidence has quietly decayed.
Hard gates: no shadow period before action authority, no tested fallback when required inputs are unavailable, or development results with no observed real-world outcomes.
Wisdom, or should this be delegated at all
Asymmetric cost analysis of false positives against false negatives in real units rather than symmetric loss. Disparate impact testing. A working contest and appeal route. A named accountable human. This is the layer WF-050 and WF-006 both failed, and they failed it before a single line of model code was written.
Hard gates: a material consequence decision with no human accountability route, a score converted straight into an adverse action with no reason anybody can be given, or oversight removed because it was slowing throughput down.
Evidence the builder didn't supply
The most load-bearing constraint in the whole framework is that the evidence mustn't come from the party being judged. A maturity layer scored by the team that built the model is an assertion rather than evidence, and self-attested inputs cannot support autonomous authority however high they happen to be scored.
Model risk management worked this out fifteen years ago. The Federal Reserve and OCC's Supervisory Guidance on Model Risk Management, better known as SR 11-7, requires validation to be performed by parties independent of model development, and requires what it calls effective challenge, meaning critical analysis by people who have the incentives, the competence and the influence to actually challenge the result. The whole apparatus exists because supervisors watched developers try to validate their own models, and it doesn't work. Not through dishonesty, but through the ordinary operation of having already made up your mind.
WF-038 is what it looks like when that constraint is missing. A vendor-reported figure of 0.76 to 0.83 against an independently measured 0.63, with national deployment happening in between. The gap wasn't fraud. It was the entirely predictable difference between a number produced by the party that benefits from it and a number produced by a party that doesn't.
In the AI Decision Authority Model, Authority Levels, from AL-0 through AL-4, define how much decision-making power an AI output may receive. Here, the ceiling is the highest Authority Level the available evidence can support. Reaching that ceiling does not automatically grant that authority. Risk, consequence, reversibility and accountability may require a lower level.
Graded, and mapped to the ceiling it buys you:
| Evidence strength | What it looks like in an ML program | Ceiling |
|---|---|---|
| Declared | A claim in the model documentation, a performance score produced during development, or "the team validated it" | AL-0, informational only |
| Scanned | Automated checks, independently controlled or verified, for expected data, meaningful change over time and uneven results across groups | AL-1, constrained action |
| Tested | Independent validation on data the builder didn't choose, testing across a full business cycle, live shadow operation and comparison with an alternative model | AL-2, supervised action |
| Attested | Live production monitoring, captured outcomes, end-to-end traceability and recorded independent sign-off from an accountable party | AL-3, bounded autonomous action |
The rule that falls out of this is short. A model whose only evidence is a number its own builders reported is entitled to inform, and nothing else, no matter how good that number is.
Ceiling, floor, and why one model holds three authority levels
The AI Decision Authority Model, Model Two in the WEKID standard, answers the question the maturity score can't answer on its own. Maturity earns a ceiling, which is the most delegation this evidence has justified. Consequence imposes a floor, which is the minimum human authority these stakes demand. The assignment is always whichever of the two is more conservative. Strong evidence never overrides high stakes, and low stakes never excuse weak evidence. And an artifact that fails a hard gate never reaches the authority question at all, because the Trust Bridge halts first.
The model expresses that assignment through five Authority Levels:
- AL-0, Informational: the output may inform analysis, but nothing downstream may rely on it to act.
- AL-1, Constrained: the system may take whitelisted, reversible and impact-capped actions.
- AL-2, Supervised: the system may propose and stage an action, but a human releases each consequential decision.
- AL-3, Bounded Autonomous: the system may execute within an assigned scope, with logging, sampling review and rollback. This is the maximum autonomous delegation the framework permits.
- AL-4, Human Reserved: the decision remains with an accountable human, supported by the model's output and audit trail.
This is where the model-centric habit breaks. Organizations certify the model and then let it drive whatever downstream action happens to be convenient, which is how a system validated for triage ends up issuing determinations. Authority doesn't attach to the model. It attaches to the decision, and consequence varies decision by decision even when the model doesn't vary at all. WF-015 is the catalog's name for exactly this, and the title says it on its own: correct predictions applied beyond their authority.
Take a predictive-maintenance model that uses vibration data to identify failing pumps in a process plant. It scores well across all five layers. Sensor health is monitored and missing readings are accounted for. Recorded failures are checked against the maintenance system rather than assumed. The model appears to rely on vibration patterns associated with bearing faults rather than on a misleading substitute such as ambient temperature. And eighteen months of live shadow operation, where predictions were observed without triggering action, caught seven of nine real failures while producing 1.4 false alarms a month against a tolerance of two. The model is independently validated and monitored in production. That evidence earns a ceiling of AL-3.
Three decisions hang off it.
| Decision | Ceiling (evidence) | Floor (consequence) | Assigned |
|---|---|---|---|
| Raise a requisition for a replacement bearing under $500 | AL-3 | Reversible and impact capped, so it permits AL-3 | AL-3 |
| Schedule the asset into the next planned outage | AL-3 | Disruptive but recoverable, so it permits AL-2 | AL-2 |
| Trip the line and shut down | AL-3 | Personnel safety, so it reserves the decision | AL-4 |
The model is identical in all three rows. So is its maturity score, and so is its evidence. The only thing that changes is what happens when it's wrong, and that's the only variable in the floor.
Notice too what happens when the drift monitor trips. A breach at Data or Information collapses the ceiling to AL-0, and all three rows go with it, including the $500 requisition that the consequence floor was perfectly happy to automate. The floor never rescues a failed gate.
Authority expires
Here's the adaptation that matters most in production, and one most MLOps stacks do not implement as an explicit authority control.
In a generative system the Trust Bridge runs per output. In classical ML, maturity gets established at a point in time and then it decays. The world moves on. The population shifts. The label proxy quietly stops standing for the thing it used to stand for. Nothing in the model changes, no error is thrown, and the scores keep arriving beautifully formed.
The operational consequence is that detecting a meaningful change in the data or operating conditions mustn't terminate in a dashboard. A breach at Data or Information is a gate trip, and a gate trip revokes authority automatically. The assignment drops to AL-0 and the predefined rules or human process takes over, without waiting around for someone to interpret an alert. Restoring authority means re-scoring, not an override.
Three mechanics make that workable.
- The ceiling has an expiration. A grant is valid for a defined window, whether that's a quarter, a retrain cycle or a volume of scored records, and it lapses unless somebody re-establishes it. Attested evidence expires faster than the model does.
- Retraining resets the clock. A retrained model is a new release rather than a maintenance update. It inherits none of its predecessor's authority. It inherits its predecessor's test suite. And this isn't administrative caution. Because training includes randomness, the new model is genuinely a different model rather than a refreshed one.
- Every automated decision gets scored against outcome. Actions taken at AL-1 and above need their real world results captured and reconciled, otherwise the Experience layer stops accumulating evidence at precisely the moment the system is generating the most of it.
AL-3 carries one further condition that's easy to overlook. It's conditional not only on evidence but on demonstrated overseer engagement, because a model good enough that you stop watching it closely is a model whose supervision has quietly hollowed out. That's Bainbridge's Ironies of Automation, forty-three years old and still the most under-priced result in this field. It isn't a theoretical worry here either. An alert firing on 18% of hospital admissions doesn't produce vigilance, it produces a click, and WF-053 catalogs the same thing in transportation, where a system requires human vigilance while actively eroding it. The sampling review that justifies AL-3 has to be evidenced like everything else, or the authority level is fiction.
What to do on Monday
The following seven actions provide a practical, cost-effective path from model-centric oversight to decision-based governance. They are ordered by the efficiency with which each step can strengthen control, expose hidden risk and establish clearer accountability.
- Inventory by decision, not by model. Most organizations have a model register. Almost none of them have a decision register. Ask what automated actions your models currently trigger and you'll find several the model was never validated for. On its own this is usually the largest finding of the whole exercise.
- Separate the evidence from the builder. Any performance number produced by the team that built the model is declared evidence, and it caps at AL-0. Independent validation isn't bureaucracy, it's the difference between 0.83 and 0.63.
- Score the label, not just the model. Write down the real outcome the organization wants to predict, the measurable substitute used to train the model, and the conditions under which that substitute stops holding. If nobody can write that paragraph, the Information layer has failed and everything above it is capped.
- Govern the threshold. Find every cut-off that turns a score into an action, then write down who chose it, when, and on what view of the relative cost of the two errors. A threshold isn't a configuration value, it's the precise point where an estimate becomes a decision, and it's the least documented artifact in most ML estates.
- Make drift an authority control. When the data or operating conditions change materially, don't stop at a dashboard alert. Revoke delegation automatically and hand the decision to predefined rules or a human process, with restoration by re-scoring only.
- Give the ceiling an expiration date. Every authority grant carries a review date and lapses on it. A retrain starts a new grant from zero.
- Publish the assignment. Record the ceiling, the floor, the resolved level and the named human, and put it somewhere an auditor can find it. When something goes wrong, the only question anybody actually asks is who held the authority, and the record should already answer it.
The close
Most of the technical building blocks already exist and are mature. Modern data platforms can preserve what information was actually available when a decision was made. Monitoring can detect when data or operating conditions change. We know how to test whether predicted probabilities match real outcomes. Independent validation has been a regulatory requirement in banking since 2011, and running a model on live activity without letting it act is a standard practice. None of it is waiting on research.
What's missing is the layer above it. The judgment about what all that evidence entitles the model to do, made explicitly, recorded, bounded by consequence rather than by confidence, and revisited when it expires. At the moment that judgment is being made by a threshold in a configuration file, written once by somebody who has since changed teams.
Machine learning isn't a lesser case for epistemic governance just because it predates the current wave. It's the case with the longest record, the largest deployed base, and the most consequential decisions already wired to automatic execution. The generative discussion is newer. This one is older, quieter, and still running in production.
The model is not the decision. It never was, and the discipline of governing it comes down to keeping evidence and authority separate enough that accountability never disappears between them.
The framework is formally specified in the WEKID™ Open Standard, which defines the Authority Levels, the Trust Bridge and the two-determinant resolution of ceiling and floor. The WEKID Foundation Whitepaper v1.3 and WEKID Foundational Companion Paper v1.3 provide the intellectual foundation behind the standard, including the role of Experience as the pivot between capability and the right to act. WEKID Governed Delivery walks the sequence as a working tool: define the artifact, declare the build and its safeguards, instrument the evidence, score the maturity, assign the authority.
Sources
Framework documents
- Judge, J. M., WEKID™ Open Standard. The Epistemic Maturity Model, the AI Decision Authority Model (AL-0 to AL-4), the Trust Bridge, the maturity ceiling and stakes floor, hard gating rules and sector calibration profiles. WEKID LLC, 2026.
- Judge, J. M., WEKID Foundation Whitepaper v1.3. The intellectual foundation for the WEKID framework and its two-model approach to epistemic maturity and decision authority. WEKID LLC, August 2026.
- Judge, J. M., WEKID Foundational Companion Paper v1.3. Companion analysis extending the framework’s treatment of human oversight, Experience and the conditions required for delegated authority. WEKID LLC, August 2026.
- WEKID™ Failure Library. 45 documented cases across 24 sectors, including recurring Wisdom-layer patterns of delegating authority beyond competence and treating probabilities as judgments.
Failure Library cases
All cases cited in this article are drawn from the WEKID™ Failure Library, which maps publicly documented incidents to the Epistemic Maturity Model and the AI Decision Authority Model. Organization names, individuals, sources and timelines are masked in the public catalog and released in the WEKID AI Failure Patterns Executive Brief.
- WF-003 Automated Hiring and Screening Bias, Employment / HR, 2014 to 2023, Constrained / Remediation.
- WF-004 Autonomous Trading and Market Disruption, Financial markets, 2010 to 2020, Constrained.
- WF-005 Government Benefits Eligibility Errors, Public sector, 2013 to 2024, Constrained.
- WF-006 Predictive Policing and Risk Scoring, Criminal justice, 2011 to 2021, Constrained / Rejected.
- WF-015 Correct Predictions Applied Beyond Their Authority, Real estate, 2018 to 2021, Constrained.
- WF-038 Overreliance on a Flawed Prediction Model, Healthcare, 2017 to 2021, Remediation Required.
- WF-046 Probabilities Replacing Clinical Judgment in Coverage, Insurance and healthcare, 2022 to present, Constrained.
- WF-047 False Positives in Security Screening, Homeland security, 2007 to present, Remediation Required.
- WF-050 Algorithmic Denial of Post-Acute Care, Insurance and healthcare, 2019 to present, Constrained.
- WF-053 Overstated Autonomy and Degraded Human Vigilance, Transportation, 2016 to present, Constrained.
Supporting literature
- D'Amour, A. et al., "Underspecification Presents Challenges for Credibility in Modern Machine Learning", JMLR 23, 2022.
- Geirhos, R. et al., "Shortcut Learning in Deep Neural Networks", Nature Machine Intelligence 2, 2020.
- Kapoor, S. & Narayanan, A., "Leakage and the Reproducibility Crisis in Machine-Learning-Based Science", Patterns 4(9), 2023.
- Sculley, D. et al., "Hidden Technical Debt in Machine Learning Systems", NeurIPS 2015.
- Sambasivan, N. et al., "'Everyone wants to do the model work, not the data work': Data Cascades in High-Stakes AI", CHI 2021.
- Bainbridge, L., "Ironies of Automation", Automatica 19(6), 1983.
Standards and regulation
- Board of Governors of the Federal Reserve System SR 11-7 and OCC Bulletin 2011-12, Supervisory Guidance on Model Risk Management.
- NIST AI Risk Management Framework 1.0, January 2023.
- ISO/IEC 42001:2023, AI management systems.
- Regulation (EU) 2024/1689 (EU AI Act), Article 14 and Annex III, as amended for application dates by the Digital Omnibus on AI.
- Commission Delegated Regulation (EU) 2024/1774, Article 16.
- Mitchell, M. et al., "Model Cards for Model Reporting", FAT* 2019.
- Gebru, T. et al., "Datasheets for Datasets", CACM 64(12), 2021.