Audit evidence you can hand to someone who does not trust you
Updated
In short
How do you prove a record has not been altered after the fact?
Kelvyn stamps audit events with RFC 3161 trusted timestamps obtained from a public timestamping authority, and chains them per tenant so that any later edit breaks chain verification. Board approvals generate sealed archive packages — a ZIP with checksums, itself timestamped, with an endpoint that verifies it. The evidence is checkable by someone outside your organisation, which is the only kind of evidence that settles an argument about whether a record moved.
Timestamps from outside the building
An internal timestamp proves nothing to anyone who suspects the system that wrote it. RFC 3161 timestamps are requested from an external timestamping authority and verified on return, so the assertion that a record existed at a given moment does not rest on our clock or our word.
This is the mechanism behind record-keeping obligations that require demonstrable integrity rather than asserted integrity.
A chain, not a log
Audit events are written into a per-tenant ordered hash chain. Verification recomputes the chain; any post-hoc edit to any earlier entry breaks it. The property is not that records cannot be edited — it is that an edit cannot be hidden.
The security audit trail is additionally immutable at the database level, enforced by a trigger rather than by application code that a future change might forget to call.
Sealed packages, generated at approval
When the board approves, an archive package is generated automatically: the evidence, its checksums, and an RFC 3161 stamp over the result. A verify endpoint re-checks the package, so a recipient can confirm it themselves rather than take delivery of an assurance.
Business-plan versions are retained immutably for ten years, and portfolio versions, curve versions and file versions carry their own lineage.
Scope
What this does not do
Read access is not audited. The trail records writes, approvals and authentication events; there is no general record of who viewed what.
There is no user-facing export of the audit log. It can be listed and filtered in the product, but archive packages export governance evidence rather than the audit trail itself.
Field-level before-and-after values are recorded at the points that record them, not by a database trigger on every table. Coverage is broad but it is not universal by construction, and it is honest to say so.
Questions
- Who issues the timestamps?
- An external RFC 3161 timestamping authority. The response is verified on return, so the guarantee does not depend on Kelvyn's own clock.
- What happens if someone edits a record directly in the database?
- Chain verification fails. The design goal is not to make edits impossible — it is to make an undetected edit impossible.
- Can a third party verify an archive package without access to Kelvyn?
- The package carries its own checksums and timestamp, and there is an endpoint that verifies it. That is what makes it usable as evidence rather than as a report.
Related