IMDA released MGF v1.5 at ATxSummit 2026. One case study shows what enforcement-layer governance actually requires. Read the analysis →
agentic AIAI governancemodel risk managementMAS AIRGdecision lineageenforcement layer

Who approved 0.85? Governing the judgment layer in agentic AI

Arjen Hendrikse · · 10 min read

The one condition no rule can express

A claims agent at an insurer is preparing to send a customer’s medical report to an external loss adjuster. Before the transfer goes out, it passes a series of checks. The agent holds the claims role. The adjuster is on the approved recipient list. The claim is open. The report’s data classification permits sharing with approved third parties.

Every check passes, and one question is still unanswered: does the adjuster need this report to assess this claim?

Under Singapore’s PDPA, the purpose limitation obligation asks whether a disclosure serves a purpose that a reasonable person would consider appropriate in the circumstances and, where applicable, that the individual was informed of. A claimant’s full medical history sent to assess a windscreen claim clearly raises a purpose limitation problem. Relevant medical information sent to assess a disability claim may well serve the stated purpose. The hard part is locating the boundary between those two cases, and no attribute on the request marks it. Finding it requires reading the claim, reading the report, and forming a judgment.

For most of the short history of AI agents, that judgment has been left to the agent itself, or to a second language model asked to review the first. A new class of component now offers a third option, and it raises a governance question most architecture reviews have not yet asked.

A new kind of component

Bounded decision models take unstructured context and a set of typed questions, and return typed answers: a yes or no, a choice from a fixed list, or a level on a rubric. A yes or no comes back as a single probability that the claim is true. A choice or a score comes back with a probability for each option and a separate confidence value. They do not generate prose.

The engineering proposition is attractive. Vendors in this category, Jev from TypeSafe AI among them, position these models as returning decisions at much lower latency and cost than calling a frontier conversational model for every check. Because the output is restricted to a schema, the model cannot return malformed text or invent an option it was never offered. A guardrail built on a conversational model, by contrast, generates its verdict token by token and can be talked into writing the answer an attacker wants.

Teams are placing these models in front of reasoning models for injection detection, PII screening and intent routing, and increasingly as a gate before an agent calls a tool. That last use is the one that matters for governance. Moving a check from generated text to a typed, inline decision point is a real improvement to the execution path, because it places a control where it can stop an action before it happens. What it leaves open is who decides what the model’s answer is allowed to cause.

The pattern that fails in regulated settings

A post on X on 23 September 2026, by a practitioner who has built agents in healthcare, insurance and fintech, set out a triage pattern for Jev-based systems. Above a confidence of 0.85, the action executes automatically. Between 0.50 and 0.85, it escalates to a frontier model or a second check. Below 0.50, it halts and goes to a human operator.

The specific numbers will vary between implementations, and early developer guides for Jev describe similar routing, with automatic handling above a cut-off and human review below it. The pattern is beginning to appear in agent architectures, and in a regulated institution it has five problems.

  1. A confidence score does not make an action safe

    The confidence value reflects the model's assessment of its answer. It says nothing direct about whether the resulting action is permitted or safe, and even a well-calibrated model will sometimes be wrong at high confidence.

  2. Calibration must be proven locally

    Calibration is a property measured against a dataset. TypeSafe trains Jev specifically for calibration, which is a meaningful design choice. Even so, a probability calibrated on a vendor's benchmark tells you little about how the model behaves on your claims files, your supplier invoices or your customers' phrasing. Until it has been validated on your own data, 0.85 is a number without a meaning.

  3. A schema-valid response can still be wrong

    Constraining the output leaves the input exposed. A bounded model cannot be tricked into writing an arbitrary reply, which removes one class of attack. A crafted input can still move the answer from "unsafe" to "safe". Narrowing what the model is able to say does nothing to establish whether what it says is true, and a schema-valid wrong answer is harder to spot than a malformed one.

  4. A second model is not automatically independent oversight

    A second model provides weaker oversight than it appears to. If the agent and the judgment model share base models, training data or the same framing of the context, their errors can be correlated. A judge agreeing with the agent counts as evidence only to the extent that the judge's failure modes are understood and differ from the agent's.

  5. The cut-off itself is policy

    The number 0.85 now decides which customer data leaves the institution without human review. In a typical implementation it lives in a configuration file, was chosen by an engineer during testing, and has no owner, no approval record and no validation evidence. If a supervisor asked who approved it, few institutions could answer.

MAS’s proposed Guidelines on AI Risk Management address this directly. They make reliance one of three dimensions that determine how material an AI use case is, covering the level of autonomy granted to the system and the degree of human involvement in the process it supports. A confidence tier that executes automatically above an unowned cut-off materially increases reliance while leaving no one accountable for the setting that governs it.

Five functions, often collapsed into one

The remedy is to change where the model’s answer sits, so that it informs the execution decision without holding the authority to make it. That means separating five functions that most agent designs merge into one or two components:

  • Reason: the agent proposes an action.
  • Judge: bounded models assess semantic conditions that rules cannot express.
  • Decide: policy combines those judgments with deterministic controls and determines whether the action is admissible.
  • Enforce: a control point in the execution path makes that decision binding before the action runs.
  • Evidence: the system records enough lineage to reconstruct why the action occurred.

The Decide function combines three distinct inputs:

  1. Deterministic controls: identity, delegated authority, hard limits, and required approvals. These are rules, so a policy engine or entitlement system should evaluate them deterministically.
  2. Semantic judgments: questions rules cannot answer on their own, such as whether a disclosure is necessary for a claim or a payment fits the approved task.
  3. Contextual evidence: the assigned task, its history, the provenance of inputs, and the current state of the tools involved.

The judgment provides evidence. Policy determines whether that evidence is sufficient for the action to proceed.

Two design rules make the arrangement work.

The first is order. Deterministic controls run first. If the agent lacks the authority to execute payments, or the amount breaches a hard limit, the request is denied without consulting any model. This is cheaper, and it prevents a subtler failure: a request that policy would have refused reaching a human reviewer because a model was unsure about it. Every unnecessary escalation spends reviewer attention, and reviewers who see too many low-value escalations start approving them by reflex. MAS’s proposed guidelines make the same point, asking institutions to account for automation bias and decision fatigue when deciding how much human oversight a use of AI requires.

The second is a separation of roles. The judgment answers the semantic question. The probability, measured against an owned cut-off, determines whether that answer is reliable enough to use automatically. Policy determines what follows from it.

Reason and judgment Deterministic control Allow Deny Escalate
Reason Proposed action Agent requests an action
Deterministic controls Authority, limits and approvals Evaluate rules before consulting a model
FailDeny
PassContinue
Judge Semantic judgment Assess conditions rules cannot express
Usability check Probability at or above the owned cut-off?
NoEscalate
YesUse in policy
Decide Policy combines all inputs Authority, constraints, context and usable judgment
Allow Deny Escalate
Enforce Control point binds the decision The action cannot proceed without this decision
Evidence Decision record Retain lineage for review and audit
The model supplies a bounded judgment. Policy, not the model, determines whether the action is admissible.

A high-probability judgment that a disclosure is necessary does not release the report on its own. It satisfies one condition in a policy that also requires the recipient, role and claim status checks to hold. A judgment below the cut-off means the condition cannot be evaluated automatically, so a person evaluates it.

What the decision record must contain

Consider an agent in a procurement workflow proposing an SGD 85,000 payment to a supplier. A typical log line records something like this:

2026-09-25T10:42:17Z payments.execute ALLOW safe=0.982

An auditor can do nothing with that line. It does not say what question the model answered, which model answered it, what cut-off applied, who set it, or what else was checked.

A decision record with usable lineage looks more like this:

Decision lineage

Payment decision record

Allow

Action

Capability
payments.execute
Amount
SGD 85,000
Payee
supplier-827

Identity

Principal
procurement-agent-17
Delegated by
finance-workflow-3

Authority

Capability
payments.execute
Status
Valid

Constraints

Transaction limit
Pass
Approved payee
Pass
CFO approval
Pass A-2231

Judgment

Question
Is this payment consistent with invoice INV-4471 and the approved purchase order?
Probability claim is true
0.982
Model
judgment-model v2.3

Usability

Automatic-use minimum
0.95
Owner
Head of Payments Risk
Approved
14 July 2026
Calibration set
PAY-VAL-2026-03
Validation report
VR-019

Policy

Reference
FIN-PAY-4.2
Rule
Allow if authority is valid, all constraints pass, and judgment probability is at or above the minimum.

Decision

Outcome
Allow
Enforced at
payments-control-point-2
Execution
txn: 88419273 Success

Three things separate this record from the log line. The judgment is tied to a defined question and a specific model version. The cut-off that made the judgment usable has a named owner, an approval date and calibration evidence drawn from the institution’s own data. The policy that turned all of this into ALLOW is versioned and states its conditions.

The record never claims the payment was 98.2% safe, because no model produced that fact. The model estimated that the payment matched an invoice and a purchase order. The institution decided that estimate was sufficient, under conditions it can show and defend.

Decision lineage

The record above is what Aivance means by decision lineage, which has three parts. Authorization asks whether this actor was permitted to attempt this action. Execution records what actually happened, and through which control point. Constraint records which limits applied and whether they were satisfied.

Semantic judgment can supply evidence for two of these. For authorization, it can assess whether the proposed action appears consistent with the delegated task. For constraint, it can assess contextual conditions such as necessity, sensitivity or anomaly. It grants authority in neither case. Authority comes from identity, delegation and policy, which are set by accountable people and changed through controlled processes.

The record also shows where the enforcement threshold sits: the point in the execution path at which the combined decision becomes binding, here payments-control-point-2. The enforcement threshold is a location in the architecture, and the score cut-offs are inputs that feed it. Before the enforcement threshold, everything is assessment. At it, the institution commits to allowing or refusing the action, and it must be able to show afterwards that the decision was admissible: taken by an actor with authority, within its constraints, on evidence that can be reconstructed.

Governing the judgment layer itself

Once a bounded model sits in the execution path, it is a model acting as a control. Institutions already know how to govern models, and they already know how to govern controls. The judgment layer needs both disciplines at once:

  • Cut-off ownership: every cut-off is owned by a named role in the business or risk function, with the rationale recorded.
  • Change control: a cut-off moves only through approval, and each change is versioned and linked to the decisions made under it.
  • Validation: the gate is calibrated and tested on the institution’s own data before it goes live, and retested at a defined interval.
  • Independence: the judgment model’s failure modes are assessed against the agent’s, so correlated errors are known before the judge is relied on.
  • Monitoring: probability distributions and escalation rates are tracked for drift, with triggers for review.
  • Revalidation on change: calibration evidence belongs to a specific model, so a new version or a new vendor resets it.

These map onto supervisory expectations already in view. MAS’s proposed guidelines ask financial institutions to maintain an inventory of AI use, assess risk materiality by impact, complexity and reliance, and apply lifecycle controls covering areas that include human oversight, evaluation and testing, monitoring and change management, and management of third-party AI risks. A semantic gate on payments or customer data rates high on all three materiality dimensions. It belongs in the inventory, with the controls that implies.

Five questions for your next architecture review

  1. Which of your agents’ execution decisions currently rest on a model probability?
  2. Who set each cut-off, and where is that decision recorded?
  3. Was each cut-off calibrated on your data or on the vendor’s?
  4. Are deterministic denials evaluated before any model is consulted?
  5. If you replaced the judgment model tomorrow, which evidence would you have to regenerate?

If the honest answer to the second question is “an engineer, in a config file”, the institution has a policy decision operating outside its governance framework.

Back to the claims agent

The judgment model in the opening example can answer its narrow question well: given this claim and this report, is the disclosure necessary? It may answer faster and more consistently than a human reviewer working through a queue, which makes it useful. Whether its answer is enough to release a customer’s medical records is a separate decision, and that decision belongs to someone who can be asked to account for it.

Whether 0.85 is high enough is a question a data science team can test. Who decided it was enough, on what evidence and for which actions, is a question for the institution’s governance, and few institutions can answer it today.


Sources

AH
Arjen Hendrikse
Founder of Aivance Consulting. ISO/IEC 42001:2023 Lead Auditor. Thirty years working at the edge of what technology can do. More about Arjen
This article was drafted with AI assistance and reviewed for accuracy by Arjen Hendrikse before publication. AI Use Policy

Put what you just read to work

If this article raised questions about your own governance posture, the 30-Minute Enforcement Gap Review is the right next step. 30 minutes, complimentary, with a one-page diagnosis on Aivance letterhead within 48 hours.

Book Your Enforcement Gap Review