SolutionsServicesLive DemosMCPEngineeringAboutProcessContactGet Started
All articles
Targets: “governed AI write path ERP

How a governed AI write-path actually works

Most "AI for ERP" pitches stop at read-only. Here's the seven-stage pattern — read, decide, approve, execute, audit, reject, rollback — implemented as actual running code, not a slide.

Evidence: real policy code and a real bug caught during testing, both from our live Governed AP Exception Workflow demo.

The pattern, concretely

Our live demo (linked below) proposes a fix to an invoice that failed three-way match, then runs it through a policy engine that's under 60 lines of code, on purpose — an internal-audit reviewer should be able to read it without an engineer in the room.

The routing is a spend-tiered ladder: actions under $5,000 execute autonomously, up to $25,000 route to a named human approver, and anything above that is blocked outright with no override path at that layer. That's not a UI restriction — it's enforced in the same code path every request goes through, whether it came from an agent or a human clicking a button.

Two independent layers of defense

The policy engine is one layer. The ERP's own application logic is a second, independent one — our mock validates vendor status and PO ceiling on every write, the same way real Oracle EBS Forms/PL-SQL logic does. In our demo, a scenario can pass every policy check the gateway runs and still get blocked because the vendor is on credit hold — the governance layer isn't pretending to replace the system's own business rules, it sits alongside them.

The part most reference implementations skip: rollback

Approval and rejection are the two outcomes everyone builds. Reversing an action that already executed is the one that gets skipped — and it's where we found a real bug while building this demo: the first version let you roll back the same executed action twice, silently double-reversing the underlying PO amount.

The fix wasn't a UI tweak — it's a governance invariant: once a rollback ledger entry exists referencing an action, that action's reversal path disappears permanently, enforced in the state logic itself, not just hidden in the UI. A compliance ledger that lets you reverse a reversal isn't a compliance ledger.

Why this maps to NIST AI RMF, not just "best practice"

Each policy check in the demo carries an explicit control tag — scope enforcement maps to GOVERN-1.5, spend-tier escalation to MANAGE-1.3, ERP validation to MEASURE-2.7, and the audit ledger itself to MANAGE-4.1. That's not decoration: it's what turns a ledger row into evidence a control owner can actually cite, not just a log line an engineer can point to.

See it built, not just described

Agent-Ready ERP Diagnostic & Governed Write-Path is the engagement this pattern comes from.

Agent-Ready ERP Diagnostic & Governed Write-Path