What gets logged, every time the graft acts.
Every read, every write, and every AI-drafted action that passes through a Sysgraft build is recorded — what it looked at, what it changed, and who approved it before anything went back to your systems. This page shows the mechanism, not just the promise.
Three questions worth being able to answer
We're not going to tell you what happens if you can't answer them. We'd just rather you could.
TODAY
Can you show which AI tools are actually touching your systems right now?
WHAT IT TOUCHED
Can you show what customer or business data has passed through them?
IF ASKED
If a customer's supplier questionnaire landed tomorrow, what would you actually send them?
Most businesses can't answer all three yet. That's not a judgement — it's roughly where AI adoption inside most mid-sized businesses currently sits. It's also exactly what a ledger is for.
Show the ledger, not just the promise
This is the same software as the rest of the site's illustrations — a different screen of it. Every row is a single action: something read, something written, something an AI drafted, or someone approving what it drafted.
Illustrative — the shape of a ledger entry, not a real client's data
What gets recorded, in plain terms
What does Sysgraft log when AI acts on my systems?
Five things, for every action the graft's AI takes: what it read, what it wrote, what it drafted, who approved it, and when it happened. Reads and writes are logged the same way whether or not AI was involved — the ledger covers the whole graft, not just the AI parts of it.
Does every AI action need approval before it changes anything?
Reading data doesn't need approval — nothing changes. Writing back to your systems does, by default: an AI-drafted action sits as a draft until a named person approves it, and that approval is itself part of the record. Where a build's specification calls for a different pattern, that's agreed explicitly, not assumed.
Who can see the ledger?
Access follows the same principle as everything else we hold: limited to authorised personnel where required to provide, maintain or support your service, and to the people in your business you've given access to. See AI & data principles for how this sits alongside data handling more broadly.
Is a logged action the same as a certified-secure one?
No, and we're deliberate about not blurring the two. The ledger describes how the graft is designed to work. It isn't a certification, and we don't imply it is one. See Security and data handling for exactly what's in place today and what isn't.
Can I show the ledger to an auditor or in a supplier questionnaire?
It's designed to give you something concrete to point to when you're asked what your AI actually touched — a real record, not a reconstruction from memory. Whether it satisfies a specific auditor's or customer's requirements depends on what they're asking, which is worth checking against your own specification rather than assuming.
Is the ledger an add-on, or part of every build?
Part of how the graft itself works, not a separate tier. Every read, write and AI-drafted action passing through a Sysgraft build is logged the same way, on every build.
Judge the mechanism, not the promise.
The exit terms are published in figures. The AI principles are written to be held to. This is the third piece: what actually gets recorded when the graft acts. The snapshot is a fair place to start testing the rest of it for yourself.