WEKID™
AN EXECUTIVE PERSPECTIVE

Governing Machine Learning: The Model Is Not the Decision

Epistemic maturity determining what a model may be trusted to do
SEPTEMBER 2026

The executive issue

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.

Full article: 30-minute readShort on time? Read the 5-minute executive summary →

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.

CaseThe model wasWhat actually failedLayer
WF-003 Automated hiring and screening biasLearning the historical data faithfullyPast selection inferred as merit, then embedded in decision logicKnowledge
WF-038 Overreliance on a flawed prediction modelReported by its vendor at 0.76 to 0.83 AUCIndependently measured at 0.63, with no local validation before deploymentInformation
WF-005 Government benefits eligibility errorsApplying its rules exactly as writtenVerification and appeal arrived after the consequences didExperience
WF-015 Correct predictions applied beyond their authorityAcceptable in the conditions it was built forPrediction confidence mistaken for decision authorityWisdom
WF-006 Predictive policing and risk scoringProducing probabilistic risk scoresThose scores treated as actionable judgments, with no route of appealWisdom
WF-050 Algorithmic denial of post-acute careA population-level predictionUsed to override an individual clinical judgmentWisdom

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.

PropertyDeterministic rule engineMachine learning systemWhat the framework does about it
Origin of the logicWritten by a person who can be asked whyEstimated from data by a process nobody observedData and Information become scored layers rather than assumptions
Repeatability of the buildSame code, same behaviorSame data, no fixed seed, different modelA retrain is a new artifact, and the authority grant restarts at zero
Nature of the outputA determinationA likelihood, plus a threshold somebody choseThe threshold is where evidence becomes authority, so it gets governed as a decision
Behavior when wrongFails visibly, throws, rejects, haltsReturns a well-formed, confident, wrong numberGates get scored in advance, because they can't work as exception handlers
What it can certify about itselfThat the rule was applied as writtenOnly that the computation ranSelf-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 componentGenerative systemClassical ML equivalent
ClaimAn asserted fact in the textThe point prediction or class label
Uncertainty markerHedging, stated confidenceThe probability assigned, the expected range of error, and how much several versions of the model disagree
AssumptionAn unstated premise behind the answerWhether this case resembles the people, events or conditions represented in the training data
Tool outputRetrieval hit, API resultThe input values and a trace back to the source systems from which they came
Reasoning traceThe stated chain of argumentWhich inputs most influenced the prediction, and whether that explanation remains stable after retraining
RecommendationThe proposed course of actionThe 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 strengthWhat it looks like in an ML programCeiling
DeclaredA claim in the model documentation, a performance score produced during development, or "the team validated it"AL-0, informational only
ScannedAutomated checks, independently controlled or verified, for expected data, meaningful change over time and uneven results across groupsAL-1, constrained action
TestedIndependent validation on data the builder didn't choose, testing across a full business cycle, live shadow operation and comparison with an alternative modelAL-2, supervised action
AttestedLive production monitoring, captured outcomes, end-to-end traceability and recorded independent sign-off from an accountable partyAL-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:

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.

DecisionCeiling (evidence)Floor (consequence)Assigned
Raise a requisition for a replacement bearing under $500AL-3Reversible and impact capped, so it permits AL-3AL-3
Schedule the asset into the next planned outageAL-3Disruptive but recoverable, so it permits AL-2AL-2
Trip the line and shut downAL-3Personnel safety, so it reserves the decisionAL-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.

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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

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.

Supporting literature

Standards and regulation