Hooks, category-based logging and governed recursion — designed for audit-heavy contexts from the start, not added later when the trail is needed and isn't there.
An audit trail added afterwards is always incomplete.
If logging isn't part of the engine from the start, every new code path risks falling outside the trail. Pwas registers hooks around every read, write, authentication and execution operation, with logging configurable by category — so the audit doesn't depend on the discipline of whoever writes the next endpoint.
the difference that matters
The auditor's question, and the two possible answers.
The difference between those two answers doesn't come down to software quality or people's diligence. It comes down to an architectural choice made years earlier, often without realising it.
When traceability is an addition — a logging module, a history table, a service that records events — it depends on every code path remembering to call it. In practice, the more the system grows, the more paths don't call it: a bulk import written in a hurry, a correction made directly in production, a service endpoint created for internal support. None of these is trying to evade the audit: nobody remembered.
The result is a trail that covers the main paths and has gaps exactly where they'd matter: in the exceptions, which are what auditors ask about.
When the trail is a consequence
In the declarative model, every operation touching data passes through one engine, and around that engine are hooks firing before and after every operation, for every category: read, write, authentication, pipeline execution. There's no alternative path allowing data to be written without going through it, because that engine is how data gets written.
The practical consequence is that the question "is this path traced?" stops making sense: every path is, including the bulk import written in a hurry and including an action proposed by an AI agent.
What gets recorded, beyond the fact
An audit trail saying only "record X was modified on day Y by user Z" answers half the question. The part that matters in a regulated context is why.
So alongside the operations trail, the decision layer is recorded: when an action originates from automation, the system records which intent generated it, which plan was compiled, which tools were invoked, which decision was taken and with what rationale. And it's a register independent of the technical request log, because it answers a different question and must be readable by people who aren't engineers.
Add the fact that applied rules are declared and versioned with their own effective dates, and reconstruction becomes complete: you know what happened, who did it, why, and under which rules in force at the time.
the comparison
Added traceability versus structural traceability.
Audit trail as a module
Covers the paths someone remembered to cover
Every new code path must remember to record the event.
Bulk imports and exceptional corrections slip through most often.
The trail records the fact, rarely the rationale.
Reconstructing a decision means interpreting technical logs.
Rules applied at the time are no longer readable if they've since changed.
An AI agent acting on data opens an uncovered surface.
Traceability in the engine
Covers every path, because there are no others
Hooks fire around every operation: there's no route that bypasses them.
Imports, corrections and service operations pass through the same engine.
Alongside the fact, intent, plan and rationale stay recorded.
Reconstruction is a readable lookup, also for non-technical people.
Rules are declared and versioned: you read the one in force at the time.
An agent's actions pass through the same verification and the same trail.
governing automation
Sensitive actions stop, they don't proceed.
Every write proposed by an agent waits for human confirmation, with the exact content already visible before approval.
01
Classifying actions
Together we decide which operations are read-only, which are low-impact writes and which are sensitive. It's a business decision and belongs to whoever answers for the process, not to the supplier.
02
Pre-execution plan verification
Before any execution, the proposed plan is checked against the real permissions of the user who requested it. A plan that fails verification isn't even partially executed.
03
Human confirmation with visible payload
For sensitive actions, whoever confirms sees the exact content that will be written and the record that will be touched. Not a generic warning: the specific data, before it becomes final.
04
Explicit execution limits
Every compiled plan runs under limits on step count, nesting depth, iterations and query size. Recursion is denied by default and must be enabled explicitly, with end-to-end tracking.
05
Independent recording
Intent, plan, tool invoked, decision and rationale stay in a register separate from the technical one, consultable by whoever answers for the process without reading application logs.
traceability
The trace comes from the mechanism, not afterwards.
Every rule carries an effective date, every operation is checked against the version in force and leaves exportable evidence.
the guarantees
What's structural and what isn't.
Engine properties, verifiable in a demo.
100%
of operations with attachable hooks
Read, write, authentication and execution: hooks precede and follow every operation, by construction and not by convention.
per category
configurable logging
You choose what to record and at what level of detail for each category, without intervening path by path.
denied
recursion, by default
A pipeline can re-enter itself only if it declares so, with complete tracking: no silent loops.
separate
the decision audit
The register of intent, plan and rationale is independent of the technical request log, because it answers a different question.
These are platform properties. They do not constitute a compliance certification: verifying adherence to the regulatory requirements applicable to your business rests with you and your advisers. What the platform offers are the structural tools that verification requires.
in depth
The questions control functions ask.
"Do you guarantee our compliance?"
No, and anyone promising that is telling you something they can't deliver. Compliance isn't a property of software: it's a property of how an organisation uses that software inside its own processes, assessed against rules that concern you and not us.
What a system can do is provide the structural elements verifiable compliance requires, which without software are extremely expensive to obtain: explicit versioned rules, controls enforced by the engine rather than by people, complete reconstructable traceability, declared and measurable waiver authorities.
The difference this makes in practice is to the cost of demonstrating compliance more than to compliance itself. An organisation preparing for a review moves from reconstructing behaviour to consulting descriptions. That's a change in the nature of the work, and anyone who has lived through an inspection understands immediately what it's worth.
"Our control function must be able to verify the rules without going through IT. Is that possible?"
This is where the approach differs most, and it's worth explaining precisely because it's counterintuitive.
In a traditional system, processing rules are code. To know what the system really does you have to ask whoever wrote it, and the answer is necessarily a second-hand description. The control function can verify outcomes — by sampling cases — but not the mechanism. That's why controls end up statistical rather than structural.
In the declarative model the rules are a readable structured document: which controls exist, with which thresholds, with which effective dates, who can waive and under what conditions. And that document isn't the system's documentation: it is the system. There can be no divergence between what is written and what is applied, because they're the same thing.
A control function can therefore read it, compare it with internal policy and spot differences without depending on anyone. Work on individual cases remains, but changes nature: from reconstruction to reconciliation.
"How do you handle retention and immutability of the trail?"
Three distinct aspects worth keeping separate, because they have different solutions.
Trail integrity. Audit events are append-only: the system's normal flow provides no path to modify or delete them. This doesn't equal cryptographic immutability guaranteed against a system administrator with direct database access — no application system can promise that on its own. Where the requirement demands it, the trail can be replicated to an external append-only store or a dedicated retention system.
Retention over time. Retention periods are declared per category and consistent with your obligations: you establish which trails are kept for how long, and the rule is explicit instead of being a consequence of a database configuration.
Minimisation. A complete audit trail is also an archive of personal data. So you declare explicitly which content goes into the trail and which doesn't: recording that a field was modified doesn't necessarily require keeping its previous value for years, and that's a choice to make deliberately with whoever handles data protection.
"We want to use AI but our risk committee has blocked everything. What can we bring them?"
A risk committee's concern about AI almost always reduces to three precise questions. It's worth addressing them one at a time, because put that way they have verifiable answers.
"Can it do something it shouldn't?" No, and not because of a policy but by construction: an action not declared as possible for that user at that moment has no execution path. The plan doesn't compile. This is demonstrable in a demo, by trying to make an agent perform an operation outside the requester's permissions.
"Can we stop it before it happens?" Yes: actions classified as sensitive require explicit human confirmation with the exact content visible. Which actions are sensitive is your decision, and the classification is itself a readable document the committee can approve.
"Can we reconstruct what happened?" Yes: intent, compiled plan, tools invoked, decisions and rationale stay recorded in an independent audit. Reconstruction doesn't require interpreting technical logs.
What can't be promised, and should be said to the committee, is that the model won't misread a request. It can. The guarantee is that a misinterpretation cannot become an action that isn't permitted, and that it becomes visible at the confirmation moment. That's a different and weaker guarantee than some would like to hear, and it's the only honest one.
quick check
Is this your case?
Probably yes
You must be able to reconstruct who did what, when and why, years later.
Your processing rules change and you must be able to read those in force at the time.
An internal control function must be able to verify the rules unaided.
You want to introduce automation or AI into processes subject to review.
Waiver authorities exist but today are neither declared nor measured.
You've been through, or fear, a review where reconstruction would take days.
Probably not
You need a compliant archiving system or a digital signature platform.
You're looking for a certification: that concerns your organisation, not the software.
Your processes aren't subject to review and you don't need traceability.
The requirement is purely perimeter security, not application traceability.
frequently asked
Regulated systems: the specific questions.
Can the audit trail be modified by an administrator?
Events are written append-only and the system's normal operation provides no path to modify them. It must be said precisely, though, that this doesn't equal immutability guaranteed against someone with direct database access and administrative privileges: no application system can guarantee that alone. Where the requirement is strict, the trail is replicated to an external append-only store or a dedicated retention system, and that replica becomes the reference.
How are rules that change over time handled?
Rules carry a declared effective date and a case's processing stays associated with the criteria in force when it happened. Changing a threshold today doesn't alter the readability of past decisions: a review reopening a two-year-old case sees the values of the time. How to treat cases in progress at the moment of a change is a choice to make explicitly at the start, because it has operational consequences.
Can we export trails to our log collection system?
Yes. Events can be forwarded to external collection and correlation systems in the formats those systems accept. It's a frequent configuration in organisations that already have a central capability and want line-of-business applications to feed it, instead of keeping separate log islands.
How does this relate to data protection obligations?
The declarative configuration assists in preparing the record of processing activities and any impact assessment, because which data exists, who sees it and how long it's kept is written explicitly instead of being an implicit consequence of code. The obligations remain yours as controller, however; we act as processor under the appropriate agreements.
Do sensitive actions always require human confirmation?
Which actions require confirmation is your decision, and the classification is a readable document your control functions can approve. The typical configuration is reads without confirmation, low-impact writes with notification and sensitive writes with explicit confirmation and visible content. Removing confirmation where it isn't needed is legitimate, provided it's a deliberate and documented decision.
Where do the data and the trails reside?
Where you decide: in your own infrastructure, on European cloud or in a mixed setup. In regulated contexts, installation within your own perimeter is the most frequent choice and is a full deployment mode, not a reduced version of the product. The choice is documented in the project and stays reversible.
We use technical cookies and, with your consent, analytics cookies (Google Analytics) to understand how the site is used. Read our Privacy & Cookie Policy.