Registration is how a table in SAP, Oracle, a planning suite, a warehouse system or a lake becomes something Juno can query.
Two decisions belong to your team: which system to connect and which tables to take. Juno carries the rest.
Registration starts in the connector list. You choose the kind of source: SAP S/4HANA or ECC, Oracle Fusion or E-Business Suite, a planning suite, a warehouse system, a cloud data warehouse, a database, a file share or a REST service. Each connector already knows how that kind of system describes itself.
The connection comes next: the address of the system, the client or the schema, and a service account whose credentials the platform holds as a stored secret. The read rights of that account are the outer limit of everything Juno can see in that system.
Juno then asks the source what it holds and shows the list. You browse it or search by name. In the showcase estate the client brought two ERPs on the Monday, and the estate reached five systems in all. The team picked 23 tables from about 1,400 that those systems offered.
Selected tables are grouped into a project: the piece of work at hand, such as the purchase order cancellation case. Projects sit inside the catalogue, the estate-wide list of every registered data set.
For each selected table Juno records the description: the table and column names, the data types, the keys, the row count and a sample of values. The mapping stage reads that description, and a sync scan compares against it later.
From then on the data set is live. A question in ChatLima or a rule in an agent reaches the rows through the federated query engine, in the system that holds them, under the rights of the connection and of the person asking.
One list per project, with the source, the size and the state of every registered table.
| Table | Source | Rows | Columns | Registered | State |
|---|---|---|---|---|---|
| EKKO · purchase order header | SAP S/4HANA | 1.24 M | 54 | Mon 08:12 | Ready |
| EKPO · purchase order item | SAP S/4HANA | 8.61 M | 61 | Mon 08:12 | Ready |
| EKET · schedule line | SAP S/4HANA | 9.04 M | 18 | Mon 08:14 | Ready |
| LFA1 · supplier | SAP S/4HANA | 9,340 | 27 | Mon 08:20 | Ready |
| MARC · material at plant | SAP S/4HANA | 412,880 | 44 | Mon 08:22 | Ready |
| PO_LINES_ALL · order line | Oracle Fusion | 1.87 M | 39 | Mon 09:05 | Ready |
| Planned orders · weekly plan | Planning suite | 240,110 | 22 | Mon 09:41 | Sample read |
| CONFIRMED_SHIPMENTS.csv | Supplier portal | 18,204 | 9 | Mon 10:07 | File · daily 06:00 |
Eight of the 23 tables. Together they carry 412 columns, and the mapping stage started at 11:20 the same morning. Showcase estate.
The state column says what Juno can do with a table today. Ready: the description is complete and queries run. Sample read: the source answered with a limited extract, which is how several planning suites expose their data. File: the data set arrives as a drop on a schedule, here at 06:00 each morning.
Six things per table: enough for mapping, for query planning and for an audit of where an answer came from.
| What Juno records | Example from the showcase estate | What it is used for |
|---|---|---|
| Table and column names | EKPO · MENGE, NETPR, MATNR | Expanded into business words and compared with the supply chain ontology |
| Data types and lengths | MENGE: decimal 13.3 · EINDT: date | Checking that a proposed meaning fits the values in the column |
| Keys and links between tables | EKPO.EBELN joins EKKO.EBELN | Joining tables in one query, and evidence behind a mapping proposal |
| A sample of values | “0000104471” · “2026-10-02” · “12,000.000” | Recognising patterns: supplier numbers, dates, quantities with a unit |
| Row count and last read | EKPO: 8.61 M rows · read Mon 08:12 | Planning the query, and telling a reader how current an answer is |
| Owner, project and access rule | A. Novak · project “PO cancellation” | Who may query this data set, and who is asked when the source changes |
The description lives in Lima’s catalogue. The rows stay in the source system. Showcase estate.
The project is where the work happens; the catalogue is where an auditor and a data lead look.
A project is the working unit: the tables one case needs, the people who own them and the mapping that goes with them. The cancellation case in the showcase estate holds 23 tables from five systems.
The catalogue is the estate-wide view. It answers what a data lead is asked every month: which systems are connected, which tables are registered, who owns each one, and which agents and questions depend on them.
The connection sets the outer limit; the asking person sets what comes back.
Showcase estate.
On Monday 07:40 L. Tan opened 1,240 exception messages: a customer push-out had left 38 open purchase order lines worth $412,000 above the need. A. Novak, the data lead, needed the purchasing, stock and plan data in one place by the afternoon.
The SAP connection already existed for Quanta, so the first six tables were registered by 08:20. Oracle Fusion took longer: S. Iyer granted the service account read rights on the purchasing resources at 08:55. By 10:07 all 23 tables sat in the project “PO cancellation”, 412 columns described. Mapping started at 11:20.
The catalogue of sources: what each connector reads, how SAP and Oracle are reached, and the three ways data is read.
The effort moves from building pipelines to choosing tables and confirming meaning.
The common route to the same starting point is a copy. Each source gets a pipeline, the tables land in a warehouse, a modelling layer gives them meaning, and reports follow. Teams describe that first stretch in weeks per source, and the copy is then kept current and governed on its own.
Registration takes the other route: Juno records the description and reads the rows where they live, so the first question can be asked in the same week. Where history at scale or a slow source calls for a copy, the Lima Quanta lands a governed one in your lake and Juno reads it there, under the same access rules.
Registration records the description of each table: names, types, keys, counts and a sample of values. The rows stay in the source system, and Juno queries them there when a question or a rule needs them.
A connection takes minutes once the service account exists. In the showcase estate five systems and 23 tables were registered in one morning; most of that time went into choosing tables and agreeing the access rule.
A named data lead, usually with IT for the connection itself. Both names are recorded on the data set, and the catalogue shows who registered what and when.
A sync scan compares the live source with the recorded description and lists what is new, changed or gone. Your team chooses what to adopt, and the mappings that depend on it follow.
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.
