When a data set is registered, Juno compares its tables and columns with the supply chain ontology: Juno’s built-in map of supply chain things and how they relate.
Five steps; the first four take minutes and run as a background task, and the fifth belongs to your team.
Registration gives Juno the description of each table: the table and column names, the data types, the keys and a sample of values. Juno reads the description and the sample; the rows themselves stay in the source system.
Technical names are then expanded into words. Juno carries a dictionary of abbreviations and of the standard fields of common systems, so MENGE becomes “quantity” and LIFNR becomes “supplier number”. Your own abbreviations join that dictionary when you teach them.
Each expanded column is compared with the attributes of the ontology. Juno looks at the name, the meaning, the pattern of the values and the way the column links to other tables. The result is a proposal with a confidence between 0 and 100% and a short reason in plain words.
The proposals go to the mapping review screen. High-confidence proposals can be confirmed together. The others wait for a person, and columns that Juno could place with low confidence are listed as gaps for the team to add.
The review screen shows the reason beside every proposal, so a reviewer can agree or disagree in seconds.
The column and table names after abbreviations are expanded: “EINDT” becomes “item delivery date”.
The pattern of the sample values: ten-digit numbers that match known supplier numbers, dates in the future, amounts with a currency.
How the column links to other tables: a column that joins to the supplier table is very likely a supplier number.
How your existing reports and queries use the column, when the source exposes that information.
What Juno already knows about the standard tables and fields of SAP and Oracle.
Every mapping your team confirmed or changed earlier; the strongest evidence for your custom fields.
| Registered column | Ontology attribute | Confidence | Status | Why Juno proposed it | |
|---|---|---|---|---|---|
| EKPO.MENGESAP · 12,000.000 | → | Ordered quantityPurchase order line | 98% | proposed | standard SAP field · numeric with unit |
| EKKO.LIFNRSAP · 0000104471 | → | Supplier numberSupplier | 99% | proposed | joins to LFA1 · matches 9,340 suppliers |
| EKPO.ZZ_CXL_WDWSAP · 21 | → | Cancellation window (days)Purchase order line | 62% | needs review | custom field · name suggests “cancel window” · small whole numbers |
| CONFIRMED_SHIP_DTPortal · 2026-09-30 | → | Supplier confirmed dateSupplier confirmation | · | added by A. Novak | mapped by hand on Tuesday 09:42 |
The last column is the reason in plain words. Showcase estate.
The confidence tells your team where to spend its review time.
The confidence is a measure of how well the evidence agrees. A standard SAP field whose values and keys both fit the ontology attribute scores close to 100%. A custom field with a short name and plain numbers scores lower, because the name is the main evidence.
Two lines divide the proposals into three groups, and you set both lines. A cautious team starts with a high line and reviews more by hand. After a few tables the corrections teach Juno the company’s naming habits, and more proposals arrive above the line.
The system dictionary covers the standard tables; your custom fields and other systems go through the same five steps.
| Area | SAP tables | Oracle tables | Ontology objects they map to |
|---|---|---|---|
| Purchasing | EKKO · EKPO · EKET · EKES | PO_HEADERS_ALL · PO_LINES_ALL · PO_LINE_LOCATIONS_ALL | Purchase order, line, schedule line, supplier confirmation |
| Materials and stock | MARA · MARC · MARD · MBEW | EGP_SYSTEM_ITEMS · INV_ONHAND_QUANTITIES | Material, material at plant, stock, valuation |
| Sales | VBAK · VBAP · VBEP · LIKP · LIPS | DOO_HEADERS_ALL · DOO_LINES_ALL · WSH_DELIVERY_DETAILS | Sales order, line, schedule line, delivery |
| Planning | PLAF · MDKP · MDTB · RESB | MSC planned orders and exceptions | Planned order, requirement, exception message |
| Partners | LFA1 · KNA1 | POZ_SUPPLIERS · HZ_PARTIES | Supplier, customer |
For these tables the dictionary already holds the meaning of each standard field, so most proposals arrive at high confidence. Custom fields, custom tables, planning systems and files are where the review screen earns its place.
Showcase estate.
A. Novak registered 23 tables on Monday. By Tuesday 08:30 Juno had proposed mappings for 371 of the 412 columns. The field that decides the whole PO cancellation case was a custom one: ZZ_CXL_WDW, the cancellation window in days. Juno proposed the right attribute at 62% and marked it for review.
A. Novak confirmed it with D. Okafor, who owns the purchasing data. The supplier portal’s confirmed ship date had a name Juno could only place at low confidence, so A. Novak mapped it by hand. At 10:40 the mapping was complete and L. Tan’s question on Wednesday could be answered.
The review screen in detail: who reviews what, how a correction is recorded, and how gaps are closed.
The effort moves from defining everything by hand to reviewing proposals.
Most tools that answer questions over data need a semantic model first: someone defines by hand what each table and column means, which metrics exist and how tables join. Practitioners describe that work in quarters for a large estate, and it has to be kept up as sources change.
Juno starts from the other end. The ontology already exists, the mapping is proposed for you, and your team’s time goes into the columns that need judgement. The modelling knowledge of your data owners is still essential; it is spent on 74 columns in place of 412.
It reads the description of each table and a sample of values to recognise patterns. The rows stay in the source system, and the sample follows the access rules of the connection.
They go through the same five steps. The name and the values carry most of the evidence, so more of them arrive for review. Each confirmation teaches Juno your naming habits.
Yes. The ontology can be extended with your objects and attributes, and a client model can be loaded as the target. The ontology model page explains both routes.
The proposals for a few dozen tables are ready in minutes. The review depends on how many columns need judgement; in the showcase estate 412 columns took 2 h 10 min.
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.
