Every governed object in Juno carries an append-only version history: connections, registered tables, mappings, vocabulary, policies, rules, agents, level settings and model links.
Five steps; simulation sits in the middle, and a named owner takes the last one.
A version starts with a change to something a run reads: a condition in a policy, a mapping between a column and an ontology attribute, a term in your vocabulary, a limit, or the level an agent runs at. Juno treats all of them the same way.
The change is made where the object lives: the plain-language sentence and its planning table for a policy, the review screen for a mapping, the level register for an agent. Juno holds it as a draft, so the version in force keeps deciding while your team works.
Simulation sits between the change and the release. Juno replays a past period through the draft and through the version in force, and puts the two results beside each other, with the reason for each difference.
Release belongs to a named owner. The approval records the person, the minute and the change set, and the new version takes effect on the next run. Every decision made afterwards points at that version number.
The same nine objects cover the data, the meaning, the rules and the level an agent runs at.
| Governed object | What a version holds | Who releases it | In the running example |
|---|---|---|---|
| Connection | The source, the credentials reference and the tables in scope. | IT architect | S. Iyer · SAP link, v2 |
| Registered table | The columns, types and keys as they stood. | Data lead | A. Novak · 23 tables, v1 |
| Mapping | Each column-to-attribute decision, with its reviewer and reason. | Data lead | A. Novak · mapping v7 |
| Vocabulary | Terms, acronyms, abbreviations, synonyms and aliases. | Domain owner | P. Sharma · vocabulary v3 |
| Policy | The sentence in plain language and the planning table under it. | Policy owner | j.park · PO cancellation v4 |
| Rule | The conditions the engine evaluates, exactly as published. | Policy owner | j.park · four conditions in v4 |
| Agent | Objective, scope of data, trigger, actions and limits. | Agent owner | D. Okafor · agent v2 |
| Level setting | The level an agent runs at, and the value band it applies to. | Manager | J. Ridley · A3 under $25,000 |
| Model link | Provider, model, key reference and the boundary rule. | IT architect | S. Iyer · design-time link v1 |
Showcase estate. Each row is append-only: a released version stays where it was written.
Gartner, 11 March 2026, predicts that by 2030 half of agent deployment failures will come from weak enforcement of governance at run time. A version history makes that enforcement checkable: the run points at a version, and the version points at the person who released it.
The same past period, run twice, shows exactly what a change would have done.
A simulation reads a past period from your own systems and runs both versions over it. Juno reports the decisions they share and the decisions that differ, and every difference carries the condition that caused it.
The reader checks those differences against what people did at the time. That is the strongest evidence a change is right: the lines version 4 holds back are the lines buyers were already keeping by hand.
Length is your choice. A narrow change is read on a week; a condition that touches supplier classes is read on a quarter, because the pattern needs the volume. Juno states how many decisions the simulation covered.
A simulation reads through the same connections as a live run and writes its findings inside Juno, so the same period is replayed as often as your team wishes.
One change set, four objects, one approval, one entry in the audit trail.
| Object | What it holds | Version 3 | Version 4 |
|---|---|---|---|
| PO cancellation policy | Supplier condition | supplier class is standard | supplier class is standard and the supplier sits outside allocation |
| PO cancellation policy | Confidence floor | 0.80 | 0.85 |
| Supplier vocabulary | Terms for one class | allocation-bound | allocation-bound · allocation supplier · AG supplier |
| PO cancellation agent | Level under $25,000 | A2 supervised | A3 delegated |
| Change set CS-0041 | four objects, released together | simulated Wed 28 Oct | j.park · Fri 30 Oct 16:20 |
A change rarely stands alone. The condition that keeps allocation-bound lines needs the vocabulary that names that class, and the level change that follows from the better drafts. Juno collects them in a change set, simulates the set as one and releases it as one, under one owner.
Undoing works the same way. Your team selects the change set and asks Juno to reverse it. Each object returns to the content of its earlier version, and each return is written as a new version, so a replay of an old decision still finds the text that produced it.
Work crosses from one environment to the other as an approved change set.
The build environment holds a copy of the versions in force and the past periods your team replays. Drafts, simulations and the tests a level change has to pass all run there, so live agents keep working while a change is prepared. Production holds the version in force, the limits the rules engine checks and the audit trail.
A change set is how work crosses, and the release log records the person, the minute and the objects that moved. A level change follows the same route with one addition: raising a level takes a passing test on recorded cases, a named owner’s approval and a live escalation route.
Showcase estate.
A. Novak opened the proposal Juno had raised from the five edits on lines for one allocation-bound supplier and drafted it as a condition on the PO cancellation policy. On the Wednesday the simulation ran over last quarter: 1,806 purchase order lines, 214 cancellations under version 3 and 197 under the draft. The 17 lines the draft held back all matched lines buyers had kept by hand at the time.
On Friday 30 October, after J. Ridley’s level review at 16:10, j.park opened change set CS-0041, read the four objects in it, and released them at 16:20. From the Monday run the agent applied version 4, lines under $25,000 ran at A3, and D. Okafor’s queue held only the lines that needed a decision. Versions 1 to 3 stayed readable, and the audit trail for September still points at version 3.
How every model call is budgeted, metered and routed, and why run time in your estate carries zero token cost.
The difference is whether the state of a rule on a given day can still be read.
In most estates a planning rule lives in a spreadsheet, a scheduled job or a line of code. A change is made, and the next report comes out different. Reading back why a decision was made in March means finding the person who edited the file and asking what it said then.
Juno keeps the answer in the system. The rule text, the conditions, the approver and the minute are held as a version, and the decision record points at the version number.
As far back as the retention period your policy sets. Records and versions share that period, so a decision from any date inside it reads with the text that produced it.
They keep pointing at that version. A release changes what the next run reads; recorded decisions keep the facts, the rule text and the approver they were made with.
It reads a past period through the same connections and writes its findings inside Juno. A source system receives a write when an approved action goes through the write-back route.
The owner of the object. Juno shows the simulation and the cases behind each difference, and records the owner’s name and the minute on the release.
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.
