A figure is worth as much as the evidence beside it. Every ChatLima answer carries six things on the same screen as the number: the figure, the rows behind it, the business terms it matched, the systems it read, the time and the scope, and the query one click away.
Weighted forecast error was 18.6% for the controller family in August, measured over 214 item and plant pairs.
Five steps; the working is built with the answer, so it arrives on the same screen as the figure.
Most products that answer questions over data now show the statement they ran, and that is worth having. It tells an analyst what was computed. It stays quiet on the step before: which business meaning was chosen, and from which tables.
Juno shows both. The terms row names the ontology terms it matched in the sentence, and each term opens its definition: what “weighted forecast error” sums, what counts as a late line, which date basis a question about delivery uses.
The sources row names each system that took part. A reader who knows the estate learns immediately that the forecast came from the planning suite and the shipped quantities from two other places, joined in place.
The timing and the scope complete the picture. Seconds tell a reader whether a source is slow; the access line tells them how much of the company the figure covers. Both matter before anyone repeats the number in a meeting.
Six links from the figure back to the confirmed mapping underneath it.
A number on a screen is the end of a chain. Juno keeps every link: the definition, the rows, the tables, the mapping version those tables were read under, and the scope of the person who asked.
That chain is what settles a disagreement. When a planning report and ChatLima give two forecast-error figures, the six steps above show where they part: a different definition, a different set of rows, or a different scope.
The mapping version matters most over time. An answer from August was built on the mapping published in July, and a replay names that version. Later corrections give a later answer, and both remain readable.
Where a column changed in the source, the sync scan lists it and Juno names the questions and policies that read it, so a reader learns which figures a change will move.
Business names in the query keep it readable for the people who own the meaning.
SELECT f.material_id, f.plant_id,
SUM(f.forecast_qty) AS forecast_qty,
SUM(a.actual_qty) AS actual_qty,
ROUND(100.0 * SUM(ABS(f.forecast_qty - a.actual_qty))
/ NULLIF(SUM(a.actual_qty), 0), 1) AS weighted_error_pct
FROM ontology.forecast f
JOIN ontology.sales_actual a ON a.material_id = f.material_id
AND a.plant_id = f.plant_id
AND a.period = f.period
JOIN ontology.material m ON m.material_id = f.material_id
WHERE f.period = '2026-08' AND m.material_family = 'CONTROLLERS'
GROUP BY f.material_id, f.plant_id ORDER BY weighted_error_pct DESC| Part of the query | What it settles | Where it came from |
|---|---|---|
ontology.forecast and ontology.sales_actual | Which registered tables carry the forecast and the shipped quantity | The mapping your team confirmed on Tuesday |
| the join on material, plant and period | That a forecast row meets the shipped row it belongs to | The relationships held in the supply chain ontology |
SUM(ABS(…)) / SUM(actual_qty) | The definition of weighted forecast error | The measure held in the ontology |
period = '2026-08' | The month the question named | The sentence A. Novak typed |
| the plant filter added as it runs | Which plants the asking person may read | The roles brought in at sign-in |
The query ChatLima wrote for the answer above, shown the way a reviewer sees it. Table names are ontology names; the engine resolves each one to the registered tables behind it. Showcase estate.
One screen serves the planner, the analyst, the auditor and the briefing room.
Where the registered data reaches part of a question, Juno answers that part, states which part stays open and names the source it would need.
Where one word carries two meanings, Juno asks a single clarifying question and keeps the choice for the rest of the thread.
Where a measure has a company definition, the answer names it, so two people reading the same figure read the same meaning.
The four readers want different depths of the same thing. Putting all six parts on one screen serves all four at once: the planner reads the top line, the analyst opens the query, the auditor opens the record, and the briefing reads the working live.
Showcase estate.
On Thursday A. Novak was asked why the planning report and ChatLima gave different forecast-error figures for the controller family. He asked ChatLima the question and opened the working.
The terms row named weighted forecast error; the definition summed absolute differences over shipped quantity. The planning report divided by the forecast. The sources row named the planning suite, SAP S/4HANA and the sales lake, where the report read one of the three. Both figures were right for their own definition, and the company chose one that afternoon.
Root-cause suggestions with their supporting data, comparisons against two years of history, short forecasts and the weekly digest.
Yes. A person with the right role opens the query, copies it and runs it in their own tool. Corrections to the meaning belong in the vocabulary, so every later question carries them.
It is written against the names your team confirmed, so a reviewer reads it in company language. The federated query engine resolves each name to the registered tables behind it.
The parts are collected while the answer is built, so the seconds on screen cover the whole sequence. The showcase estate averages 4.2 seconds across three systems.
The stored record: the question as typed, the scope, the query, the mapping version, the sources, the row count and the time. Any answer can be replayed against that version.
Juno answers that part, states which part stays open and names what it would need, such as a source carrying supplier confirmations for the acquired division.
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.