A management operating system for a UAE distribution group: deterministic rule engines read a 229-table SAP lake and turn every posting into per-vertical P&Ls, so a margin move becomes a diagnosis, an owned action, and a journaled consequence — not a mystery.
This is not a reporting platform. It is the operating system a distribution business is run through — the product's own manifesto opens with that refusal, and every screen is audited against it.
The client is a UAE distribution group: one business unit, roughly ten verticals, buying from global principals and selling to contractors, developers and government. SAP is the system of record and management cannot read it. So the machine reads it for them — and refuses to summarize. Every number a manager sees is the output of a named, deterministic query against one semantic layer; the language model is allowed to write sentences, never numbers.
What your vertical heads get is not a dashboard. It is their own P&L, down to net profit, with an accountability line drawn at exactly the costs they control — and behind every line, the machine's four standing questions: what is this, what caused it, what should I do, did it work.
Somewhere this month a finance analyst is hand-cutting a SAP dump into Excel, again, so that a room of executives can look at one number and fail to explain it.
The organization stores every cost at business-unit level. Ten verticals — HVAC, pumps, elevators, the rest — share one pooled P&L, so no vertical head has ever seen their own bottom line, and no one can say which of the ten actually makes money. SAP knows, in its way: cryptic profit centers, material groups, document types. Nobody in the meeting speaks that language.
So the monthly ritual runs on a deck of disconnected spreadsheets. Contribution margin is down; the room asks why — price, volume, mix? The honest answer is that finding out means another week of Excel, and the meeting is now. FIG. 1 shows the loop as observed. The question survives it; the answer never arrives.
Thirty-six SAP extracts land in an Iceberg lake — 229 of the 239 catalogued tables scoped in, table by table, with a written verdict on each. A data-residency rule holds everywhere: no SAP copy ever leaves the lake. Engines query it in place; the app database holds reference and audit schemas only, never a fact.
A 32-rule priority ladder classifies every sales line into one of ten vertical buckets — time-aware, because profit centers were born on different dates and history misroutes without it. Same row, same rules, same period: same output, always. The bucket totals are frozen as a regression baseline; any refactor that moves a number by one dirham fails the gate.
When CM2a misses target, the machine decomposes the gap — price, volume, mix, new and lost business — at SKU-customer grain, rolled up only for display. The bridge must sum exactly: no “other” bar, no residual line. If the math doesn't sum, the rule is to fix the math, not the chart.
Diagnosis ends in a drafted action from a playbook catalog — each playbook carrying its own track record — with an owner and a deadline attached. Not a dashboard to browse: the three things that need attention, pushed to the channels people already live in. A human approves anything that moves money. Always.
Every decision is journaled with an expected outcome and a frozen snapshot of the numbers as they stood — immutable, so hindsight can't rewrite it. When the outcome arrives, the arc lands back on the same ledger line the decision tried to move. This loop is the whole thesis — the same dashed arc you saw closing on the tile.
The tempting design: hold each vertical head to full CM2. But that line carries salaries HR sets and warehouse shares Finance allocates — judging people on levers they don't hold guarantees a legitimate argument with the platform.
The tempting design: see a misattributed dirham, add a rule. Aggregate statistics lie about sub-populations — a reference field that is “a customer PO on average” carries the seller's own invoice number on most retentions.
A ledger that claims to be trustworthy owes you its corrections. Every row below traces to a numbered design doc, a commit, or a re-frozen baseline.
The pattern across them: when a number came out wrong, the fix was never a patch on the symptom — it was a probed row, a corrected rule, and a baseline re-frozen so the mistake can never return silently.
valid_from/valid_to, and a cost-center filter at the lake layer means the engine never even sees a foreign division's rows. Caught in review, before a single sheet shipped.And the skeptic's question, answered before the interview: this page claims correctness, not speed. No before/after month-end cycle-time was measured — the toil it replaces was never instrumented — so the strongest verifiable outcome here is reconciliation: real SAP totals reproduced to the dirham and frozen as gates. The five-minute figure on sheet 1 is the design target the product is built and accepted against, and it is labeled as exactly that.
What the numbers mean for an operator: your ten vertical heads stop being managers of a blind spot and start being owners of a P&L; your finance team stops hand-cutting SAP dumps and starts adjudicating a reconciliation report; and “why did margin move?” stops being a week of Excel and becomes a question the meeting can answer while it is still the meeting.
Discuss a system like this →A dossier this tidy hides the true shape of a live system, so here is the untidy part, plainly.
This machine is in production cutover right now — role-based access, row-level security and SSO are being hardened for a real go-live, with a threat model and a runbook, not a demo switch. The engines and the reconciliation discipline are the proven part. The upper layers are the bet: the diagnosis narratives and drafted actions ship at the lowest autonomy tier and must earn promotion, and the decision journal — the consequence loop this whole page is drawn around — is deliberately ramped over months, because forcing a forecast commitment on someone who has never read a P&L kills the habit in week two.
The hardest engineering wasn't the SQL. It was refusing shortcuts that would have demoed well: refusing to let an LLM near a number, refusing a rule that wasn't motivated by a probed row, refusing to measure a vertical head on costs they don't control. What this build proves is the part I sell — that a raw ERP can be made to confess, deterministically, and that people accept accountability when the line is drawn honestly.
Bring the number nobody in your business can explain — the margin that moved, the vertical that might be losing money, the report everyone distrusts. The first conversation is a probe, not a pitch: one failed row, examined properly.