Juno proposes a mapping for every registered column and hands the result to your people.
Five steps; your team spends its time on the columns that carry judgement.
The queue holds one row for each registered column. Each row carries the proposed ontology attribute, the confidence, the reason in plain words and a sample of values. Filters narrow the queue to one system, one business object or one status, so the work splits between people.
Proposals above your confidence line arrive as one block. A reviewer scans the block, unticks anything that looks wrong and confirms the rest in one action. In the showcase estate 338 of 412 columns went through that way, which left 74 for judgement.
The marked proposals take the most time, and they deserve it. A reviewer agrees, picks another attribute from the object it belongs to, or hands the row to the person who owns that data. Every choice records who made it, when, and why.
Columns Juno left open are listed as gaps. The reviewer searches the ontology by business term, picks the attribute and saves it. Where the right attribute is missing, the reviewer adds one on the ontology model page and maps to it.
The reason, the confidence and a sample of values sit on the same row as the decision.
| Registered column | Ontology attribute | Confidence | Status | Why Juno proposed it | |
|---|---|---|---|---|---|
| EKPO.MENGESAP · 12,000.000 | → | Ordered quantityPurchase order line | 98% | confirmed | standard SAP field · numeric with a unit of measure |
| EKET.EINDTSAP · 2026-10-02 | → | Requested delivery dateSchedule line | 96% | confirmed | standard SAP field · dates ahead of today |
| EKKO.LIFNRSAP · 0000104471 | → | Supplier numberSupplier | 99% | confirmed | joins to LFA1 · matches 9,340 suppliers |
| PO_LINES_ALL.QUANTITYOracle · 500 | → | Ordered quantityPurchase order line | 95% | confirmed | standard Oracle field · same value shape as the SAP column |
| EKPO.ZZ_CXL_WDWSAP · 21 | → | Cancellation window (days)Purchase order line | 62% | adjusted by D. Okafor | custom field · name suggests “cancel window” · whole numbers 0 to 90 |
| PLAF.PLNUMSAP · 0000241187 | → | Planned order numberPlanned order | 71% | needs review | key of PLAF · sent to the planning owner |
| CONFIRMED_SHIP_DTPortal · 2026-09-30 | → | Supplier confirmed dateSupplier confirmation | · | added by A. Novak | mapped by hand on Tuesday 09:42 |
| ZSD_ALLOC_GRPSAP · AG-07 | → | Allocation groupMaterial at plant | · | open | custom field · short codes · waiting for the planning owner |
The four statuses: confirmed, adjusted, added by a person, open. The last column is the reason Juno gave. Showcase estate.
The queue splits by business object, so each person sees the rows they are able to decide.
A mapping review works best with two people at one screen: one who knows the tables and one who knows the business. The data lead brings the first, the domain owner brings the second.
A larger estate splits the queue by business object: purchasing to the buyer team, planning to the planners, stock to the warehouse team. The data lead keeps the whole queue and the count still open.
Six steps; the reason a reviewer gives stays with the mapping.
A correction is a piece of company knowledge, so Juno keeps it whole: the column, the attribute chosen, the attribute proposed, the reason, the reviewer and the time. An auditor reads that record months later and sees why the estate means what it means.
The same record feeds the next proposal. Juno treats confirmed and corrected mappings as the strongest evidence it holds, above names and value patterns, because they come from the people who own the data.
The published version is what questions and agents read; a review in progress leaves them steady.
A column stays open until someone maps it or marks it out of scope. The queue shows the open count at the top of the screen. When a question needs an open column, Juno names the attribute it waits for.
Publishing turns the current state of the queue into a version. Questions, policies and agents read the published version, so a review in progress leaves live answers steady. Restoring an older version writes a new one.
Showcase estate.
A. Novak opened the queue at 08:30 with 371 proposals waiting. The block above 90% held 338 columns. A. Novak read the reasons, unticked two that looked wrong and confirmed the rest at 08:52. That left 74 columns and one colleague to call.
D. Okafor joined at 09:15. Together they adjusted 33 proposals, among them ZZ_CXL_WDW, the cancellation window that the whole purchase order case turns on. They mapped 41 columns by hand, including the supplier portal’s confirmed ship date. Version 1 was published at 10:40, and L. Tan’s question read it on Wednesday.
The objects, attributes, relationships and measures behind each target column, and how you add your own.
The judgement stays with your people; the clerical work around it goes.
The common practice is a mapping spreadsheet. A data engineer fills a sheet of source columns and target fields, sends it to the business by e-mail, receives comments in three colours and merges them by hand. The knowledge of why a field was chosen stays in the e-mail thread.
The review screen keeps the same conversation in one place. The proposal, the evidence, the decision, the reason and the author sit on one row, and the result is a version an auditor reads directly. Your data owners still supply the judgement; the clerical work around it goes.
It depends on how many columns carry judgement. In the showcase estate 412 columns from five systems took 2 h 10 min, with two people at one screen.
Yes. The queue splits by system, business object or status, and each reviewer works their own filter. The data lead sees the whole queue and the count still open.
Questions and agents read the last published version. A review in progress stays private to the reviewers until someone publishes it as the next version.
Yes. A reviewer opens the row, picks another attribute and gives a reason. That writes a new version, and the earlier version stays readable for a replay.
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.
