Visual policy rules for AI governance: no hidden scripts behind the diagram

The rule was visible. The exception lived in a hidden script.

A distributor runs an AI-assisted supplier refund process. The approved policy sits in a visual builder, clear enough for anyone to read: refunds above $25,000 need a second finance approver; so does any change to the beneficiary bank account; and both approvals must stay bound to the exact refund proposal.

On screen it reads: IF amount > 25,000 OR beneficiaryChanged THEN require second finance approval.

beneficiaryChanged is calculated by a custom expression behind a property panel. It was written when the refund record had a field called beneficiaryAccountId. A later schema version moved it to beneficiary.account.id. The diagram didn't change. The script still read the old field, found nothing, and returned false instead of an error.

An $18,000 refund to a newly supplied account skipped the second approval. The first approver checked the amount, the policy service returned a valid decision, and the payment API confirmed the transfer.

Nothing threw an error. The rule still showed the control, the script ran, the approver was eligible, the payload matched its schema. The failure wasn't using expressions; policy always needs them. It was letting one expression become a hidden, weakly typed, separately changing source of authority.

What makes a visual policy rule trustworthy?

A visual rule is trustworthy when the diagram is the policy rather than a picture of it: typed facts, defined handling of missing data, explicit outcomes and conditions, visible precedence, tests and versions, all in one definition that the runtime executes.

A readable canvas is useful, but readability isn't governance. Besides "does this evaluate to true?", a governed rule must answer:

• What exactly is being evaluated, and for whom?
• Which facts are authoritative, current and allowed for this decision?
• What happens when a fact is missing, stale or conflicting?
• Which outcome results, and which conditions come with it?
• Which step enforces it, and what invalidates it later?
• What evidence proves it constrained the real outcome?

Rules, validations, decisions and policies aren't the same thing

"Rule" gets used for at least six jobs, and they don't carry the same authority:

Keep these visibly distinct. Otherwise a schema check gets mistaken for authorization, a routing rule for an approval, or a prompt for a control.

Facts need a source, a type and a meaning

A policy evaluates a whole proposition, not a user or a record in isolation: who started it, who's acting now, which software is running, the tenant and legal entity, the record and its revision, the action and purpose, the exact proposal, the current state, and the time and risk conditions. A role like "Finance Manager" is one input, not the decision.

Every fact in that proposition needs a contract. amount = 18000 means little until you know whether it's the proposed, approved, gross, net or estimated amount. beneficiaryChanged = false isn't defensible unless you can say which two records were compared, with which IDs and schema version, and whether either value was missing.

A visual builder should show where each fact comes from rather than presenting anonymous variables. Facts drawn from history (counts, totals, status over time) need the same contract, including how fresh they must be.

How should a policy rule handle missing data?

Missing, stale, conflicting or unauthorized facts are policy outcomes, not programming inconveniences. Each needs a declared response, because silently converting them to false, zero or a default is how controls disappear.

Scripts typically coerce a missing value into false, zero, an empty string, a default option or a swallowed exception. Any of those can quietly widen authority, exactly as beneficiaryChanged did. A governed rule names the states:

• available, missing, stale, not authorized, conflicting, invalid, source unavailable;

and declares what each leads to: deny, refresh the data, request more evidence, send to a person, mark the decision indeterminate, or stop before any change. Nobody should discover months later that null == false is why a financial control vanished.

Image · visual-policy-hidden-scriptTop: a clean visual rule card with two conditions joined by OR and an outcome Require second approver. Below it, peeled back like a layer, a code panel reading beneficiaryAccountId with a red note Field renamed in schema v2, returns false. To the right, an 18,000 refund to a new account passing straight through to Paid. Second panel to the side: the fixed version, with a typed fact Beneficiary changed: Missing leads to Send to review.

Outcomes beyond allow and deny

Authorization standards already distinguish Permit, Deny, Not Applicable and Indeterminate. Business policy often needs more: review required, step-up sign-in required, reapproval required, wait for fresh data, permit with conditions, block.

Each of these is a state change with consequences, not a hint to the caller. "Review required" moves the case to a person. "Permit with conditions" isn't Permit plus optional notes; the conditions are part of what was permitted.

Conditions become runtime work

A rule may permit an action only if the runtime also redacts fields before the model sees them, uses an approved region, caps an amount, requires a second approver, asks for step-up sign-in, keeps a receipt, re-checks before the write, or retains evidence. Each of those must be tied to the specific step that performs it and produces proof that it did.

That's the point where many visual builders stop: they show the decision but not where it's enforced. A valid decision is not proof the policy was enforced. For how enforcement points work across an agent workflow, see runtime policy enforcement.

When several rules apply, the combination is policy too

Real decisions combine rules from enterprise governance, tenant settings, legal entity, product line, jurisdiction, data class, process and exceptions. How they combine has to be explicit: deny overrides, permit overrides, first applicable, explicit priority, merged conditions, or a person decides on conflict.

None is always right. Deny-overrides suits sensitive disclosure. Permit-overrides is only safe when the permitting rule is an authorized exception. First-applicable is dangerous if someone can reorder rows by dragging them. A visual builder should show not just the rules, but how several applicable rules become one decision.

Scope needs the same visibility. Reviewers should be able to see which workflows use a rule, which tenants or business branches inherit it (see taxonomy-scoped authorization), which exceptions narrow or widen it, and which paused cases are still bound to an older version.

Does every path actually cross the rule?

Only a coverage check answers that. A rule can be well written and well tested while one fallback branch, retry path or sub-workflow reaches the action without it.

Reviewing rules in isolation misses the path problem. The stronger question is structural: does every route to this consequential action pass the required check and produce the required evidence? A coverage view can expose one branch that reaches payment without a second approval, one fallback model route that skips the residency rule, one sub-workflow that drops the tenant, one retry that reuses an expired decision, or one output channel with no disclosure rule.

Test semantics, not just examples

Testing belongs in the policy definition, not in a separate spreadsheet.

Then simulate. Run the proposed version against synthetic and recorded cases, with changed facts, scopes and precedence, and compare outcomes, with no live side effects. A simulated result never authorizes a real action.

Image · visual-policy-change-lifecycleLeft-to-right lifecycle: Edit rule, Dependency view (list of workflows using it), Compare versions (side-by-side diff), Simulate on recorded cases (bar showing outcomes changed versus unchanged), Approve, Publish. A curved arrow from Publish back to the previous version labeled Rollback. Note under Simulate: no live side effects.

Version everything the decision depends on

A policy version number is incomplete if the decision can change because something else changed underneath it. A rule depends on fact schemas, sources, taxonomy versions, mappings, shared functions, combination rules, enforcement bindings and tests. The schema rename in the opening story was exactly this kind of unversioned dependency.

Paused work shouldn't automatically adopt the newest rule either. Each workflow should declare whether a waiting case stays on the version it started under, rechecks current authority and record state, needs reapproval, migrates, or stops. Decide that up front rather than letting it happen by accident.

Common anti-patterns

Ten design rules for visual policy

1. Evaluate a complete proposition, not anonymous variables.
2. Give every fact a type, source, scope, freshness and missing-data meaning.
3. Keep validation, decision logic, authorization, human judgment and prompts distinct.
4. Make outcomes and conditions explicit; never collapse them into a boolean.
5. Tie every mandatory condition to the step that enforces it.
6. Show how multiple rules combine and which one wins.
7. Test boundaries, missing facts, conflicts, coverage and version changes.
8. Bring custom code in as typed, versioned, tested functions.
9. Version facts, mappings, taxonomies and enforcement together with the rule.
10. Keep the decision, its enforcement and the confirmed outcome linked.

The result: rules people can read and trust

Visual policy isn't a replacement for precise policy semantics. It's how you make those semantics inspectable by the people accountable for them. Business owners see the intended control, security sees actor, record, action, purpose and scope, engineers see typed facts and enforcement steps, auditors trace decisions to outcomes, and the runtime executes the same published meaning.

The goal isn't to hide complexity behind friendly shapes. It's to make the complexity that matters visible, so nobody has to read a general-purpose script to find out whether a control is really on.