Enterprise Decision Automation

Executive summary

Most organisations make the same decisions thousands of times a year against a written policy: approve or refer an application, price an offer, route a claim, clear a condition before funding. The policy is usually clear. Applying it is not. Different people read it differently, the cases wait in a queue for someone to pick them up, a threshold change needs an engineering release, and when someone asks months later why a case was decided the way it was, nobody can say which version of the policy applied.

Enterprise decision automation is the discipline of running those decisions as governed software: the policy held as versioned rules and tables that the business can read, calculations done exactly, AI used where judgment helps and nowhere it would decide the policy, people brought in where the policy says one is needed, and a record of every decision that can be shown to an auditor.

This paper explains what that takes. It defines the category, breaks a governed decision into its parts, sets out where AI belongs, describes how to change a policy without guessing at the consequences, lists what a record must contain to answer an examiner, and ends with a practical 90-day path and a readiness checklist. It is written to be useful whatever tool you choose. The last chapter says how Miji does it.

1. Why policy-driven decisions break

A policy-driven decision is one where a written rule says what should happen and a person or a system applies it to the facts of a case. Credit eligibility, pricing, prior authorisation, claims triage, onboarding checks and invoice exceptions all have this shape. They fail in the same five ways.

• Inconsistent outcomes. Two identical cases get different answers because two people interpret the policy differently, or because one of them is working from last quarter's version. Inconsistency is a fairness problem before it is an efficiency one.
• Slow answers. Every case waits for a person, including the ones the policy already decides. The applicant with a clear yes waits as long as the one who needs a careful look.
• Policy changes that need a release. When a threshold lives in application code, changing a credit-score minimum is an engineering ticket, a test cycle and a deployment. The business stops changing the policy because changing it is expensive.
• No answer to “why was this decided?”. The decision was made, but the inputs, the version of the policy and the branch that fired were never recorded together. Reconstructing them later is guesswork.
• People reviewing everything. Without clear routing, every case gets a manual pass as a precaution. Review capacity is spent on cases that did not need it and is short for the ones that did.

None of these is solved by working harder or by adding a model. They are solved by making the policy itself the thing that runs, and by recording what it did.

2. What enterprise decision automation is

Decision automation is software that applies a defined policy to the facts of a case and returns an outcome — approve, decline, refer, a price, a route, a limit — together with the work around that decision: gathering the data, doing the calculations, sending exceptions to people, acting on the result, and recording why.

The word enterprise adds three demands: the decision must be governed (who may change the policy, and who must approve what), testable (a change can be tried on real history before it decides anything), and explainable after the fact (the record says what was decided, by which version, on which inputs).

It is often confused with three neighbouring kinds of tool. Each does part of the job.

3. The seven parts of a governed decision

Every automated decision worth defending has the same seven parts. A gap in any of them is where inconsistency, delay or an unanswerable audit question comes from.

Two design choices matter more than any other. First, keep limits and thresholds in tables rather than in logic, so a rate change is a data change rather than a rule rewrite. Second, do the arithmetic exactly: a payment or a ratio computed with floating-point numbers, or by a language model, will eventually be wrong by a cent in a way that matters.

4. Where AI belongs in a governed decision

AI is very good at the parts of a decision that rules are bad at: reading a document, classifying free text, summarising a file for the person who checks it, drafting a letter. It is a poor place to put the policy itself. A model asked whether an applicant meets a credit-score minimum may answer correctly every time in testing and still be impossible to explain to an examiner, and a model's answer can change when the model is updated.

The workable pattern is to keep the decision deterministic and put AI inside it, at bounded steps whose output is checked:

• Extraction. AI reads a value from an unstructured document; a rule checks it against the figure the applicant stated, and a mismatch goes to a person.
• Classification. AI sorts an incoming request into a category; the category picks the workflow, and the workflow applies the policy.
• Summarisation. AI writes a summary for the person reviewing a referred case; the person decides.
• Authoring. AI drafts a workflow or a rule from a plain-language description; a person reviews and publishes it, and it then runs without AI.

Govern AI steps the way you govern people: record the model, the input and the output with the decision; choose the model and own the key; and decide in advance which outputs a person must confirm. A model that only ever advises is much easier to defend than one that decides.

5. Changing a policy safely

The most dangerous moment in the life of an automated decision is not the first deployment. It is the fifth policy change, made under time pressure, with no clear view of which past cases it would have decided differently. Mature teams test a policy change the way they test code, against real history, before it decides anything.

Replay only means something if it answers every external call — a credit bureau, a pricing service, an AI model — from what the original run actually received. Otherwise a replay compares the draft policy with today's data, not with the facts the original decision saw.

Pair every technique with an approval rule: who may publish a policy change, and whether a second person must agree. A change that cannot be traced to the person who approved it is the first thing an auditor will ask about.

6. Governance and the decision record

Examiners, auditors and regulators ask the same questions of an automated decision, and the questions are easy to predict. Build the record to answer them before anyone asks.

Governance is also about who can do what before a decision runs: role-based access to policies, single sign-on so access follows the organisation's directory, separate test and production environments, and deployments pinned to a known version so production cannot drift.

7. A 90-day path to the first automated decision

The fastest route to value is one decision, end to end, rather than a platform programme. Pick a decision that is frequent, policy-driven and expensive when inconsistent, and take it through these steps.

1. 1

   Weeks 1–2: choose and write down the decision

   Pick one decision. Collect the policy as it is actually applied, including the exceptions people know by heart. Agree what a correct outcome is for twenty real cases.

2. 2

   Weeks 3–5: model the policy

   Turn the policy into rules and decision tables, put limits and rates into reference tables, and make every calculation exact. Keep it readable by the people who own the policy.

3. 3

   Weeks 5–7: connect the data and the people

   Connect the data sources the policy needs. Decide which cases go to a person, who that person is, and what they see when the case arrives.

4. 4

   Weeks 7–9: test against history

   Replay a batch of past cases. Explain every disagreement with the historic outcome: either the policy model is wrong, or the historic decision was.

5. 5

   Weeks 9–11: run in shadow

   Let the automated decision run beside the current process on live cases without acting. Compare daily until the differences are understood.

6. 6

   Weeks 11–13: go live with review

   Let it decide, with a person reviewing referrals and a sample of automated outcomes. Widen automation as confidence grows.

8. Readiness checklist

A decision is ready to automate when you can answer yes to most of these.

• The policy is written down, or can be, by the people who own it.
• The decision is made often enough that consistency and speed matter: hundreds of times a month or more.
• The data the policy needs can be reached by a system, not only by a person reading a screen.
• You can say which cases a person must decide, and who that person is.
• You have past cases with known outcomes to test against.
• Someone is accountable for the policy, and for approving changes to it.
• You know what an auditor or examiner would ask for, and who would answer.

If several answers are no, start with the policy rather than the software: a decision that cannot be written down cannot be automated, only moved.

9. How Miji implements this

Miji is an enterprise decision automation platform. It runs a decision as a governed workflow built from the parts in this paper, and it is live today in lending, sold first to manufactured-home lenders. The same engine fits any operation where work arrives, is checked against a policy, is decided, is sometimes reviewed, and is acted on.