Governed Record Editing in SyteLine: Preview, Confirm, Audit, Undo
There is a bright line in every conversation about AI and ERP systems. On one side, reading: answering questions, building dashboards, generating reports. Mistakes there are visible and cheap. On the other side, writing: changing a due date, updating a price, correcting a customer record. Mistakes there ship wrong orders and misstate financials. Most AI tools handle this line by pretending it is not there, either refusing all writes or, worse, performing them casually. SyteRay's position is that writes are legitimate and necessary, and therefore deserve real governance. The editing flow is built on four guarantees: you see exactly what will change before it changes, nothing happens without explicit confirmation, everything that happens is recorded in a full audit trail, and changes can be undone. This post walks through why each guarantee exists and how they compose.
Preview: The Change as a Diff, Not a Promise
When you ask SyteRay to change something, the first thing it produces is not a change but a preview: the specific records that will be affected, each field's current value, and the value it will become. The preview is computed against the live database, so it reflects reality at the moment of decision, not an assumption from earlier in the conversation.
The preview step is where AI assistance and governance meet. The language model's job is to translate intent into a precise, scoped change set; the preview is where that translation is exposed for human judgment. If the request was ambiguous, the ambiguity is visible as a wrong or overbroad preview, caught before it costs anything.
Confirm: Writes Are Explicit Acts
Nothing in the preview executes on its own. The user must explicitly confirm the change, and confirmation is scoped to exactly the previewed change set, not to a category of future changes. There is no mode where SyteRay writes to the ERP as a side effect of conversation.
This same gate extends to stored procedures. Because SyteRay classifies every procedure's side effects, including transitive ones, a request to run a procedure that writes data, even indirectly through nested calls, is routed through the same preview-and-confirm flow. The system's knowledge of effects is what makes the gate airtight rather than advisory.
Audit: Every Change Has a Story
Each confirmed change is recorded with what changed, the before and after values, who confirmed it, and when. The audit trail is what turns AI-assisted editing from an act of faith into an ordinary controlled process, the same standard you would demand of any integration touching your ERP.
In practice the audit trail earns its keep in review conversations. When a value looks wrong a week later, the question of what happened has a factual answer in seconds: here is the change, here is who approved it, here is what the value was before. That legibility is precisely what makes controllers and IT managers comfortable expanding what the system is allowed to touch.
- Before and after values are captured for every field of every affected record.
- Every change is attributed to the user who confirmed it, with a timestamp.
- The trail is queryable, so review is a lookup rather than an investigation.
- Reversibility is built on the trail: the recorded before-state is what undo restores.
Undo: Reversibility as a Design Requirement
Because the audit trail captures the before-state of every change, undo is a first-class operation rather than a manual repair. Reverting restores the recorded prior values through the same governed flow, previewed, confirmed, and itself audited, so the correction is as legible as the original change.
Reversibility changes the risk calculus of adoption. Teams can start using governed editing for real work knowing that the worst case of a mistaken change is a recorded, reversible event rather than a data-repair project. Confidence built this way compounds: the audit history of correct, boring changes is the evidence that earns the system more scope.
Why Conservative Is the Right Speed
It would be easy to market a more autonomous system, one that just does what you ask. We think that is the wrong product for a production ERP. The value of AI at the edit path is not saving the three seconds a confirmation click costs; it is eliminating the twenty minutes of form navigation before it, while keeping human judgment exactly where it belongs, at the moment of commitment.
Governance is also what makes the capability durable. A single ungoverned mistake can end an AI program's credibility at a site. A governed flow with previews, audit, and undo survives its mistakes, learns from them, and keeps its mandate. Slow is smooth, and smooth is what production systems require.
Key Takeaways
- 1SyteRay treats ERP writes as legitimate but governed: previewed, explicitly confirmed, audited, and reversible.
- 2Previews show the exact records and before/after values computed against the live database.
- 3Stored procedures with write effects, even transitive ones, route through the same confirmation gate.
- 4The audit trail powers undo: the recorded before-state makes every change reversible through the same governed flow.
Want AI that can safely touch your ERP, not just talk about it? See SyteRay's governed editing live. Contact ajay@netray.co.
More Insights
From Question to Governed SQL: How SyteRay's Evidence-First Answers Work
Generic AI chatbots fail on ERP data because they guess at schemas and invent numbers. SyteRay takes a different contract: every answer over your SyteLine database ships with the SQL that produced it and the tables it read. Here is the pipeline that makes that possible.
SyteRayHow SyteRay Classifies Every SyteLine Stored Procedure's Side Effects
A mature SyteLine site runs on thousands of stored procedures that nobody fully remembers. SyteRay crawls the whole catalog, 8,636 procedures on the reference deployment, and classifies what each one reads, writes, and calls, including transitive effects. Here is how and why.
SyteRayWhy We Built Semantic Views for SyteLine: One Source of Truth for Open Orders
When two SyteLine reports disagree about how many orders are open, the root cause is almost never a bug. It is two different definitions. SyteRay's semantic layer encodes each business definition exactly once, as reviewable SQL views, and everything reads from them.