Every run of an agent writes a record while it happens. The record holds the signal, the rule version that evaluated it, the facts as they were read, the recommendation, each limit that was checked, the approval, the action, the acknowledgement from the source system and the outcome.
Eight parts, each written at the moment it happens, under one decision reference.
An audit record is assembled during the run, part by part. The signal arrives, and the exception message and the facts behind it are stored. The rules engine evaluates the version in force, and the version number joins the record with the conditions that matched.
Facts are kept as they were read. A later change in the source system leaves the record as it was, so the reason for the recommendation stays readable years afterwards. Each fact carries the system it came from and the moment it was read.
Approval adds the person. The record holds the name, the time, the queue the action waited in and whether the action was approved as drafted, edited or rejected. Where two-person approval applies, both names are stored.
The write-back adds the answer from your own system: the document number, the message and the status the source returned. The outcome check closes the record at its window with a verdict. Storage is append-only, so every entry stays where it was written.
The same nine entries exist for every action, whichever agent produced it and at whichever level.
| Time | Part of the record | What is stored |
|---|---|---|
| Mon 06:00 | Signal | Exception message 0034921 for material 7741-X at plant 1210; the open lines read from SAP S/4HANA and Oracle Fusion, of which 38 match |
| Mon 06:00 | Rule version | PO cancellation policy, version 3, released 18 September 2026 by J. Ridley |
| Mon 06:01 | Facts as read | Projected excess 11.4 weeks · line value $8,420 · window closes Thu 24 Sep · supplier class standard |
| Mon 06:06 | Recommendation | Cancel line 00020 of order 4500067123; three conditions matched; confidence 0.91 |
| Mon 06:06 | Limits checked | Value under $25,000 passed · daily action budget 29 of 60 · confidence floor 0.80 passed |
| Mon 09:12 | Approval | D. Okafor opened the queue at 08:50 and approved as drafted after 3 h 06 min in the queue; session and role recorded |
| Mon 09:14 | Action | Purchase order change posted to SAP S/4HANA through the released interface for the agent |
| Mon 09:14 | Acknowledgement | Order 4500067123 item 00020 carries the deletion indicator; message 20260921-114 stored as returned |
| Mon 5 Oct | Outcome | Projected cover 6.2 weeks at day 14; verdict met; guard measure clear at day 28 |
Showcase estate. One decision reference, DEC-2026-09-21-0417, holds all nine entries.
The rules engine gives the same result on the same facts, so a decision can be reproduced.
Replay answers the question an auditor asks first: why was this done. Because every governed object carries an append-only version history, the rule, the mapping, the vocabulary and the level setting can all be rebuilt as they stood on the day.
The comparison step answers the second question: what would happen today. Running the current version on the same facts shows how the policy has moved, which is also how a team reviews a change before releasing it.
An auditor reads the same record your planners and managers read, from a role of their own.
The frameworks buyers bring to this conversation ask for the same things. EU AI Act Article 12 asks for automatic logging over the lifetime of a system; Article 26 asks deployers to assign oversight to trained people and keep those logs. ISO/IEC 42001:2023 asks for a management system around the whole of it, and the NIST AI Risk Management Framework asks the four questions of govern, map, measure and manage.
IDC, 23 October 2025, predicts that by 2030 up to 20% of the largest 1,000 organisations will face lawsuits, fines or leadership changes because of poorly governed agents. The record on this page is what a governed agent leaves behind on every action it takes.
Showcase estate.
J. Harrison, the finance lead, asked why one line on order 4500067123 had been cancelled. The audit trail returned the record in full: the Monday signal at 06:00, version 3 of the policy, the three conditions that matched, the limits checked, D. Okafor’s approval at 09:12 after 3 h 06 min in the queue and the acknowledgement SAP returned at 09:14.
S. Iyer then replayed the decision against version 4, released later with the condition that keeps lines for allocation-bound suppliers. On the same facts, version 4 gives the same result, because the supplier class on this line is standard, and the replay says so. Both results sit side by side in the export that went to the audit file, each with its version number.
How a change becomes a version, how it is simulated on past data, and how change sets move between your two environments.
The difference is whether the evidence is collected afterwards or written at the time.
The usual pattern is a search through e-mail threads, screenshots and a spreadsheet of approvals, put together in the week before an audit. The evidence describes what people remember, and the gaps are the parts a system performed quietly.
Juno writes the evidence as the work happens, from the same run that produced the action. That is what the live PO cancellation deployment means by 100% of actions traced to a rule: the trace exists because the action created it.
Inside your estate, in the Juno platform database, under your backup and retention policy. Exports go where your audit process asks: a file, an object store or a case system.
The store is append-only, so entries stay as written. A correction is a new entry that names the person who made it and points at the entry it corrects.
Yes. Questions and answers are logged with the person who asked, the ontology terms used, the systems read, the access applied and the query, and the show-the-working page explains what a reader sees.
The same eight parts, with the approval entry holding the limit that allowed the action to proceed. Audit after the fact is the oversight at that level, so the record carries the whole chain.
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.
