A quality rule in Lima is a sentence that says what to check, where and when. Saved, it becomes a rule agent: it runs on its schedule over its scope, produces findings with evidence, and may propose or apply a fix according to the level of autonomy it has earned.
The sentence form is deliberate. The people who know what a correct record looks like are stewards, planners and controllers, and a sentence is the form they already use. The platform's job is to turn the sentence into a testable thread and to show its reading back, so a misunderstanding is caught before the rule runs.
The dry run is the second safeguard. Every rule is executed against live rows with writing disabled before it is saved, so the steward sees the rows it would flag. A threshold that is too tight or a scope that is too wide shows up as a number that looks wrong, and the sentence is adjusted on the spot.
Rules written this way are the same rules the rules page describes at three levels: column rules on one field, row rules across a record, business rules over totals and across tables. What this page adds is how each of them lives as an agent.
This is what makes the fleet manageable: one register, one detail page, one set of registers behind them.
| Block | What it holds | For the lead-time rule |
|---|---|---|
| Mission | What the agent is for, in a sentence | Keep lead times of active plant materials inside 1 to 180 days |
| Scope | The tables, rows and fields it may look at | Plant materials, status active, 14 plants, 42,318 rows |
| Directives | The testable rules it applies | Lead time between 1 and 180; a value of 0 is a finding, a blank is a completeness finding |
| Tools | What it may call, each with a mode: read, propose, write | Read the table; propose a value from the supplier's quoted lead time; write through the released material interface |
| Trigger | When it runs: interval, calendar, event or on request | Nightly 02:00 and on change of the field |
| Guards | Hard checks on every proposed action | Confidence at least 0.9; 500 writes a day; four eyes on writes |
| Escalation | The screen and the people a finding goes to for a decision | The planning centre of excellence review screen, hop SLA 24 hours |
| Eval | Golden test cases replayed against the agent, with the pass rate | 38 cases; 97% pass; last run this morning |
A domain with forty fields and ten plants has hundreds of rule instances. They stay manageable because they share the eight blocks and are minted from packs.
A rule pack is a bundle of rule templates that is stamped across a scope: three templates across fourteen plants mint forty-two rule instances in one action, each with its own findings and its own acceptance rate. A local edit to one instance is tracked as drift and shown at the next publish of the pack, so a plant's exception is visible to the pack owner. The configuration page covers packs in full.
The register shows the fleet by domain, by level, by acceptance rate and by last run. A rule whose findings are always rejected is a candidate for rewriting; a rule whose proposals are always accepted is a candidate for promotion. Both are visible from the register itself.
| rule | level | scope | findings (7d) | accepted | last run |
|---|---|---|---|---|---|
| lead-time-range | L2 | 42,318 | 1,204 | 97% | 02:00 |
| moq-positive | L3 | 42,318 | 88 | 99% | 02:00 |
| planner-assigned | L1 | 42,318 | 2,910 | 71% | 02:00 |
| uom-valid | L3 | 61,004 | 12 | 100% | on change |
| gross-weight-present | L1 | 38,110 | 5,402 | 58% | 02:00 |
Through a tool grant: verification services, registries and the platform's own match engine are tools with a mode (read, propose, write) granted per agent. The verification page lists the services.
A finding carries the rule that raised it, so two findings on one field are shown together on the ticket. Where two agents propose different values, the case goes to a person, or to a weighted arbitration inside a spread the owner has set.
Anyone with the steward role on the domain writes and dry-runs; saving a rule that writes to a source needs the domain owner's stamp, because the write-back is a change to a system of record.
The reading is shown back as the three parts of the thread before anything is saved, and the dry run shows the rows it selects. Where the sentence is ambiguous the platform asks one question, in the same screen.
Bring one domain and two systems. In a week the sources are profiled, the ten costliest fields are under rules, the first corrections are written back with their acknowledgements and the publish gate is on.
