The Human Is Still the Rules Engine
We publish rules as documents and leave people to compute their consequences. A reusable, inspectable model can change where that work happens.
Imagine a claims specialist with five tabs open. One contains the insurance law. Another contains the provision it refers to. A third holds the holiday calendar. The remaining two contain the claim and a spreadsheet.
The question is small: was the payment late?
To answer it, the specialist must connect a receipt date to a statutory period, choose the relevant calendar, check whether an exception applies, and compare the resulting deadline with the payment date. If there is a penalty, another chain begins: principal, rate, date, conversion convention, period of delay.
The rule has already been written. The events are recorded. A person still has to assemble the path between them.
In that workflow, the human is the rules engine.
The work between the document and the answer
Calling someone a calculator captures only the last step. Multiplication is usually the easy part. Before it comes the work of deciding which multiplication is warranted.
A rule may depend on a definition elsewhere. An exception may have a narrower scope than its heading suggests. An amendment may apply to a later period. A word such as “received” may require evidence about a particular event. Someone has to turn those relationships into a procedure for this case.
The same design problem can arise in an engineer’s compliance check, an accountant’s treatment of a transaction, or a citizen’s attempt to understand an entitlement. Each needs a path from the governing text to consequences on particular facts.
Software already performs many such calculations. A spreadsheet formula is executable logic. So are the rules inside a payroll or claims system. The question is what happens to the connection with the source: who can inspect it, reuse it, challenge it, and update it when the rule changes?
The OECD identifies this as an institutional problem in its 2026 consultation on the digital provision of law. Legal logic is repeatedly translated into separate systems by authorities, service providers and vendors. Its account links that duplication to inconsistent implementations, limited transparency and dependence on individual systems.
That gives “the human rules engine” a more precise meaning. It is the person who carries the connection between text and implementation when the connection has no shared, inspectable form.
Where the reasoning goes
Suppose the specialist sends a colleague a date and an amount. The colleague can check the arithmetic. But to check the answer, they also need to know which edition supplied the period, why a particular exception was excluded, and how an annual rate became a daily one.
If those decisions live in memory, they must be explained again. If they live in a formula, the formula must be traced back to the text. If they live in a procedure manual, someone must establish whether the manual and the software still agree.
These are several representations of the same reasoning, each needing maintenance.
The opportunity is to preserve more of that reasoning as a reusable object. A rule, its source, its effective dates, its dependencies, the adopted interpretation and the cases used to test it can travel together. The next case can supply new facts to an existing model. A reviewer can examine the model and its application separately.
Publishing a rule makes it available. Making it executable makes its consequences inspectable—provided the model and the path to the answer are available for inspection too.
Give the repeated work a place to live
Consider a workflow with two distinct activities.
First, people formalize and review a bounded set of rules. They identify the sources, encode the conditions, name the assumptions and test examples whose expected answers have been established independently. Interpretive choices become reviewable parts of the model. When the source changes, the model needs a new version and renewed review.
Then, for each case, someone checks the evidence, supplies the relevant facts and runs the chosen version. The result should preserve the applied rules, the inputs and any unresolved conditions. The responsible person reviews that record before acting.
The investment shifts toward maintaining something that can be reused. A difficult interpretation still requires difficult work. Recording it makes that work available to the next reviewer, including a reviewer who disagrees.
This also changes what it means to find an error. If a calendar was wrong, the affected calculations can be identified by the calendar they used. If an exception was modelled incorrectly, it can be corrected and the relevant cases examined again. Keeping versions makes it possible to explain both the earlier answer and the revised one.
These are requirements for a dependable workflow. Executing an inaccurate model more quickly would only distribute its error more efficiently.
One calculation shows the boundary
In the fictional insurance case described in One Accident, Several Laws, One Answer, the insurer receives the required documents on 22 July 2026 and pays 730,000 tenge on 24 August. The recorded model derives a deadline of 12 August and establishes twelve days of delay.
With the recorded annual rate of 16.75% and an explicitly supplied divisor of 365, the penalty calculation yields 4,020 tenge. The payment amount and divisor are inputs; the deadline and penalty are outputs. The saved analysis shows the deadline and lateness in its compact card; the full analysis includes the amount and the obligation to pay the penalty. Its case questions are in Russian, with an English interface.
Remove the divisor in a paired case. The model still establishes lateness, but derives no penalty amount. The rule used for the annual rate does not specify that conversion convention; the model therefore requires it as an explicit input. The paired case is preserved in the analysis of calculation boundaries.
This is a useful division of work. The engine applies the formalized relationships. A person must supply and justify the assumption on which the remaining arithmetic depends. The absence of an amount remains visible instead of becoming an unexplained zero.
Arxo executes the canon. Models formalize; Arxo executes and proves. Here, the chain from events to consequences is available for review, along with the inputs on which it depends.
Human responsibility becomes more specific
A person reviewing such a result has several distinct jobs.
They must establish the facts. A date in a form does not prove when documents were received. A calculation cannot establish the authenticity of the evidence supporting its inputs.
They must examine the interpretation. Encoding a provision requires choices about its meaning and scope. Naming those choices makes them easier to review; it does not confer legal authority on their author.
They must exercise judgment where the rule requires it. Whether conduct was reasonable, evidence sufficient or a remedy proportionate can require a decision from an authorized person. A useful model should identify that dependency and show which conclusions rely on it.
And they must take responsibility for the action. Computing an amount, approving a payment and deciding a dispute are different acts. A workflow should identify who is entitled to perform each one.
This makes “human oversight” more concrete. The reviewer needs access to facts, sources, assumptions and unresolved questions. A final approval button cannot supply those things by itself.
Access to consequences
The implications extend to the person on the other side of the desk.
An accessible text lets a claimant read the rule. An inspectable model could also let them examine which conditions were used, whether the facts were entered correctly, and what would change if a disputed fact were resolved differently.
That is a design objective, and it has institutional conditions. The model needs an identifiable author and version. Its interpretations must be open to challenge. Its results must be distinguishable from decisions made by an authority. A way to correct the model and review affected decisions matters as much as a way to run it.
Without those conditions, the claimant may simply exchange dependence on an expert for dependence on a service whose reasoning they cannot inspect.
The five-tab specialist shows where to begin. Choose one recurring question. Make its rules explicit. Preserve the evidence for the inputs. Test the boundaries. Give the next reviewer enough information to reproduce the answer and locate a disagreement.
A rule should come with a way to inspect what follows from it. Human attention should go where the answer still requires judgment.