The Lima Rules Engine executes the plans your team publishes. It reads the plan from the rule store, gathers the facts it needs from your systems, evaluates the conditions in the order the plan sets, and carries out the actions the plan allows.
Six steps, the same for every agent, so one run reads the same way as the next.
A run starts when its trigger fires. The engine reads the plan for that agent from the rule store: the published version, the rows of conditions, the actions each row allows, the limits that apply and the level the agent runs at.
It then builds the fact base for that run. Each row names the data it fetches, and the engine reads those mapped tables through the federated query engine, in the systems that hold them, under the access the agent carries.
Evaluation follows the published order. Row by row, the engine tests the conditions against the facts and keeps the lines that match. Where a row calls for a calculation, the calculation block runs it and hands the number back to the rule.
Matching lines become findings, and the level decides what follows: the agent informs a person, drafts for a named approver, or executes inside your limits. The engine then checks the outcome against the objective and writes the run to the audit trail.
Nine parts behind every agent, and one clear division of labour between the engine and the model.
The authoring layer holds what people write. The rule repository keeps every version of every plan with its owner and its approver. The Advanced Rule Builder is where a row is edited by hand, and validation runs while the author types.
The evaluation layer holds what the engine reads and works out: the fact base over your federated sources, the evaluation of the conditions, and a calculation block for rules that need statistics or a solver.
The action layer holds what the engine does with a result. Arbitration ranks competing recommendations, action flows carry the action to the system that will perform it, and the closed-loop operator holds the write-back setting for that one agent.
The PO cancellation agent runs on these nine parts today, and every role built from the blueprint would share them. That is why oversight is learned once: one repository, one fact base, one record.
| The rules engine | The language model |
|---|---|
| Evaluates the published conditions and returns the result | Puts that result into a sentence a planner reads |
| Applies your limits before an action is carried out | Drafts the plan at design time from the stated intent |
| Ranks competing recommendations inside the band you set | Proposes candidate rules found in past planner behaviour |
| Carries out the action and stores the acknowledgement | Reports where live data has moved away from what a rule assumed |
| Gives the same result on the same facts and version | Serves run time from inside your estate, at zero token cost |
The engine decides; the model explains, discovers and reports drift. Product.
The rule names business objects; the engine resolves them to your columns through the published mapping.
| Fact the plan reads | Ontology object it belongs to | Where it was read in the showcase estate |
|---|---|---|
| Open lines and their quantities | Purchase order line | SAP S/4HANA · Oracle Fusion |
| Requested and confirmed dates | Schedule line · supplier confirmation | SAP S/4HANA · supplier portal |
| Stock on hand and stock on order | Stock · material at plant | SAP S/4HANA · warehouse system |
| Forward demand | Forecast · sales order | Planning suite · SAP S/4HANA |
| Cancellation window in days | Purchase order line | SAP S/4HANA, a custom field mapped by your team |
The fact base is the set of rows one run reads. It is assembled from the mapped ontology, so a rule names “projected excess” and the engine works out which columns in which systems carry it. The rows stay in the systems that own them.
Each agent carries its own least-privilege access, and the fact base applies it. The facts are stored as they were read, with the system and the moment, so the reason for a decision stays readable years afterwards.
A condition can be a row, a comparison, a query or a script, and each one is checked as it is written.
| How a condition is written | What it looks like | Who usually writes it this way |
|---|---|---|
| A row in the planning table | Projected excess · above · 8 weeks of demand | Planners and buyers, in the words the policy uses |
| A comparison on an ontology attribute | Supplier class equals standard | Domain owners, in the Advanced Rule Builder |
| A query condition | A SQL statement over the mapped tables that returns the lines to act on | Data leads, for tests a single row leaves out |
| A short script | A few lines that work out a value in several steps and return it | Data leads and IT, reviewed before release |
Most conditions stay as rows, because a row is what a planner reads and an auditor checks. The two open forms are there for the tests a row leaves out, such as a comparison across several periods.
Validation runs while the author works. It confirms the attribute exists in the published mapping, that the value fits the data, that the agent’s access reaches every table, and it reports overlaps between rows before the plan is simulated.
Validation while authoring · showcase estate.
The trigger is a setting on the agent, and every run records the one that started it.
| Trigger | What starts the run | Example from the showcase estate |
|---|---|---|
| A schedule | A time you set, on the days you choose | The cancellation agent runs at 06:00 each weekday, before the planners arrive |
| An interval | A gap you set between runs, such as every 15 minutes | A shortage triage role would refresh its ranked list through the working day |
| An event in a source | A row that changes in a system Juno reads | A customer push-out lands in the planning suite and an excess stock role would run |
| A person | A run started by hand from the agent screen | The Friday test write: one line changed in the test system of each ERP, started from the agent screen at 12:30 |
Each agent carries its own trigger, and a run records which trigger started it. Showcase estate; the shortage triage and excess stock roles are designed in the agent blueprint, yet to be built. blueprint
A schedule suits a decision the team works through at a set hour. An interval suits a queue that people watch during the day. An event suits a change that matters within minutes. A run started by hand suits a test, a question from a manager, or a rule that has just been published.
Showcase estate.
The PO cancellation agent ran at 06:00 on Monday 21 September, as scheduled, after the planning run. The engine read version 3 of the policy, gathered 1.2 million open lines from SAP S/4HANA and Oracle Fusion, and evaluated the five rows in 41 seconds. When L. Tan opened her 1,240 exception messages at 07:40, the lines were already found.
Thirty-eight lines matched, worth $412,000. Twenty-nine of them sat under the $25,000 threshold and reached D. Okafor’s approval queue as drafts worth $187,300; nine ran above the threshold and reached D. Okafor as buyer, for his judgement, with the reason for each.
The policy ran at A2, so a named person approved every one of the 38. The threshold decides who sees a line first, and the approval stays with a person on both sides of it. Each line carried its rule version, the facts as read and the limits checked, so the queue showed the reason beside every draft.
How a rule you state in plain language becomes something Juno watches, and how the alert reaches the right person.
The published conditions decide. The model writes the explanation, proposes candidate rules from past behaviour and reports drift. At run time it runs inside your estate, so a call carries zero token cost.
The run records the facts it could read and reports the gap beside the affected lines. Those lines wait; the rest of the plan carries on. The next run picks them up again.
Yes. Facts are read per run under that agent’s access, so two agents reading the same tables see the rows each of them is cleared for.
It depends on the sources and the size of the plan. In the showcase estate the cancellation policy read 1.2 million open lines and evaluated five rows in 41 seconds.
Each one builds on the one before it.
Reads your rows in place.
Connect and move ↗One record per real thing.
Master and govern ↗Apps for every decision.
Operate and decide ↗Asks and acts, at your level.
Ask and act ↗Bring two systems and one decision your planners make every week. In the first week we register the data, confirm the mapping with your team, answer your questions in ChatLima and run the first agent at the level you choose.
