Audit and assurance
The system that does the work is not the only system watching it.
A bot that reports on its own behaviour is a bot marking its own homework. So ours do not. One automation runs the process; a separate one observes it independently. The reading engine keeps its own record of what the automation engine then did with what it read. The two have to agree.
Four layers
Every action is recorded four separate ways
Not four views of one log. Four independent records, produced by different parts of the system, that can be compared against each other.
Layer one
One automation audits another
An independent observation layer watches what the working bot actually did — separate from the bot’s own account of itself. If the two disagree, that disagreement is the alert. A single bot reporting its own success can only ever tell you it succeeded.
Layer two
The reading engine audits the automation
When a document is read and the result is then acted on, the reading side keeps its own record of what it handed over. That record is checked against what the automation side says it received and did. Data cannot quietly change shape between the two.
Layer three
A machine-readable trace per action
A complete structured record of every operation — queryable per patient, per document, per transaction. When an information governance question arrives about one record, the answer is a query, not an investigation.
Layer four
A reviewable recording of the task
Every task produces video as a by-product of being done, not as an extra step somebody has to remember. If a question surfaces months later, there is something to watch rather than something to reconstruct.
Why four
Because the dangerous failure is the quiet one
A bot that crashes is not a problem. Somebody notices within the hour and it gets fixed.
The failure that costs you is the one that keeps reporting success. The interface that returns a confirmation for messages nobody is reading. The scheduled job that stopped running three weeks ago. The reconciliation that has been comparing an empty set against an empty set and finding no discrepancies.
All of those look identical to working correctly, if the only thing you check is whether the system says it is fine.
So we treat silence as a fault. The platform knows what should have run and when. Work that does not happen raises an alert in the same way work that fails does.
A success message is a user interface event, not proof that anything was saved.Which is why every write is read back and confirmed before it counts as done
The trap this avoids. If a monitoring layer is quietly catching failures that a fix was supposed to prevent, the numbers look healthy — because the net is working. That reads identically to the problem being solved. We report the two separately and treat a busy safety net as evidence that something upstream is still broken.
Integrity
The record cannot be quietly edited — including by us
Tamper-evident chain
Audit entries are cryptographically chained. Altering one after the fact breaks the chain visibly. There is no version of this where a record is changed and nobody can tell.
Written once, mirrored immediately
Every entry is copied to an append-only store within a minute of the action, encrypted, and kept for seven years in line with NHS records management.
Our own access is logged too
When our staff look at your data it is recorded and visible to you. Access is scoped per client at the platform level, and crossing that boundary is an event, not a permission.
What this is worth to you
Three questions this makes cheap to answer
| The question | Without this | With it |
|---|---|---|
| “What happened to this patient’s record?” | Someone reconstructs it from several systems over days | A query against the trace store |
| “Prove the remediation is actually running.” | An evidence pack assembled in the weeks before the deadline | A report, because the evidence is a by-product of the work |
| “Show me every action taken on this document.” | Partial logs, if the logging was configured that way | A full trace, and a recording of the task |
The audit format meets the clinical risk-management standard as a native output rather than as a report generated afterwards. Your clinical safety officer signs the hazard log before anything goes live, every time.
And the other half
Auditing what happened matters less than refusing to let it happen
All of the above is retrospective. The more important protection is that the bot architecturally cannot take an action it was not configured to take — it either runs correctly with a clean audit trail, or it stops and tells someone. There is no third state where it improvises.
Send us your due diligence questionnaire
We would rather answer it now than halfway through a procurement. If there is something here we cannot evidence, we will tell you which.