Suppose someone looks at your log a year from now and asks one question: how do you know nothing has disappeared from it?
Not: has anything been changed. Not: is it in the documentation. But: how do you know nothing was cut off at the end.
Most tools have no answer to that question. We do, since this past summer — but part of that answer is “in four situations we do not see it”. Those four are below.
Why we are writing this down
An audit trail is our central promise. A promise you cannot verify yourself is a slogan.
So instead of writing down what it stops — everyone else does that already — we are writing down what it does not stop. Everything below is also in the security document that ships with our source code. It is here because a security document nobody reads is not openness.
What the chain does see
Every line in the log carries a computation over the previous line plus what happened on this line. The check starts at line zero and recomputes everything.
That makes three things visible.
Content altered. The recomputation no longer matches.
Lines swapped. The order must strictly increase, and breaks.
A line added or taken out in the middle. The link to the previous line falls away.
On top of that, the software itself may only append to and read from the log table. Updating and deleting are not allowed.
That is what a good log is supposed to do. Now the rest.
Gap 1: cutting off the end
The check anchors only the first line to a fixed starting point and then walks forward. It does not check that the chain begins at line one, and not whether the end matches an expected number of lines.
Think of a paper logbook from which someone tears out the last pages. What remains is consecutively numbered, neatly signed and fully consistent. That is exactly what happens here: delete the last lines and the check simply reports that everything is in order.
Add to that: the linking computation uses no secret. Anyone who can write the whole database can recompute the whole chain.
The boundary, precisely: the chain holds against everyone who cannot write to the database, and against altering, swapping and removing something from the middle by someone who can. Not against cutting off the end.
Gap 2: reading the log leaves no trace
Consulting the log does not itself produce a line. Who looked into it, and when, is not recorded.
And there is no playbook for who gets warned when the check fails, or when someone is refused ten times in a row. Detection we have. Alerting we do not.
Today that is bounded by the fact that this part runs in a single process, with no network side and no separation between administrator and user to enforce against. In the desktop version it should be there.
Gap 3: the fields you search on are not recomputed
The check recomputes every line from its sealed part. But the separate fields you search on and get back — time, kind of action, who did it, document name, matter reference — are not compared against their copy inside that sealed part. And when a document name is empty, that copy does not exist at all.
Someone with write access can therefore alter a search field. Your search returns the changed value, while the check still passes.
The rule that follows, and that we apply ourselves: the sealed part is authoritative; the search fields are aids for filtering. Fixing this changes the check itself, and we do not do that in passing.
Gap 4: two fields sit readable on disk, and erasure does not touch them
This is the heaviest one, and it is the direct neighbour of gap 3: the same two fields, the same cause — they sit outside the sealed part.
The document name and the matter reference are written unencrypted on every line. In the sectors this product is meant for, both routinely carry identifying data. A document name is often a person’s name or a case number. A matter reference is, by definition, a client identifier.
The consequence, plainly: an erasure request does not touch these two fields. Who performed the action is shielded through a key per person, but these two are not covered by it. Destroying that key does nothing to readable text. An erased person who appears in a document name remains identifiable.
And there is no after-the-fact repair that keeps the chain intact. Rewriting or blacking out a line that has already been written breaks both the chain and the seal over it. For lines already written, this is permanent. That is a consequence of the design, not a forgotten detail — but it is one you need to know before you begin.
Leaving the fields out is not possible: they are the fields that make the log searchable, they carry the reconstruction of what happened, and the matter reference is the basis for the per-matter export.
What you do about it as an administrator: treat both fields as personal data sitting on disk, and encrypt the storage. Neither the chain nor the software will shield them for you.
This article is general information, not legal advice. For your own situation, put it to a lawyer or your data protection officer.
What we did about gap 1, and where that ends
Since July 2026, Provenize can periodically place a signed seal over the log. That seal contains a fingerprint over all lines up to that moment, the number of lines, the time, and a signature.
That makes cutting visible: the number of lines no longer matches what was sealed. But only under four conditions, and we never call this tamper-proof without naming all four.
The seal must sit out of reach of whoever can write the database. The seal itself lives in that same database. If you run locally only, someone with write access can throw away the covering seal. The check then falls back to an older seal that is still valid, and reports that everything is in order — for a log whose newer, sealed lines have been destroyed. Publishing the seal elsewhere is the only defence. Working locally only leaves this open by construction.
The signing key must not have been stolen. That key is a file protected only by the operating system. On Windows that rests on the file’s permissions, which are harder to enforce strictly there than on Linux. Encrypting the key file itself is on the roadmap; it is not there yet.
A key must have been configured when the seal was placed. If not, the seal is unsigned and means nothing. The check reports that separately.
The lines in question must sit at or before the last seal. Everything added after it falls outside. If someone cuts back to exactly the last seal, it checks out again. How often you seal is your own risk window. Whoever never seals gains nothing.
The detail I thought about longest
The obvious solution is to write the placing of a seal into the log itself, as a line. Then you can see later that sealing happened.
I deliberately did not do that, because it does not work.
Such a line lands just after the point where the seal ends. That is exactly the area removed by someone who cuts off the tail. The line then sits next to the very lines it is supposed to prove, and disappears along with them. It is the note “the log ends here” on the last page: whoever tears out those pages tears out the note with them.
Linking seals to each other does not solve it, and neither does a counter in the database. Everything sits within the same write reach.
Five answers, not two
The check does not return “good” or “bad”, but five different outcomes: it checks out; it does not; the seal is invalid; the seal is unsigned; or there is no seal at all.
That is not pedantry. A seal that is absent and a seal that exists but is signed by nothing may never share an outcome with “everything was recomputed and it checks out”. A verification tool that folds absence into approval lies to its user.
For the same reason we do not call gap 1 closed. We call it conditionally closed. The mechanism is there; what remains is a duty on your side — seal regularly, and keep the seal out of reach.
Six questions for your vendor
These questions work on us and on everyone. The way they are answered often says more than the answer itself.
- What does your check not see? If the answer is “everything”, you are done with the conversation.
- Does your check notice when the last lines have been cut off, or only when something changed in the middle?
- Does the reference point you check against sit outside the reach of your own administrators?
- Are the fields I search on recomputed as well, or only the sealed content?
- Which fields in that log are personal data, and what happens to them on an erasure request?
- And the most important one: is that answer written down somewhere I can read it myself?
Question six is the reason this piece exists. We wrote the answers down before anyone asked, and you may hold us to them.
Want to see the full boundaries? What we protect (and what not) — in writing, without marketing around it.
Where we stand
A claim about demonstrability from software nobody may inspect is a contradiction. That is why the SDK is open source.
But a claim about demonstrability without a written boundary is just as much a slogan. The number that counts is not how many attacks we stop, but how precisely we can say which ones we do not.
If you find a fifth gap, we would rather hear it from you than from someone else. The disclosure channel is open.
To be honest about it: the SDK is built but still pre-1.0, and Provenize Desktop has not been released — the release is planned for late 2026. Nothing runs in production at a customer yet. The seal in this piece works and is tested; the improvements we describe as “on the roadmap” do not exist yet. The product is designed to support you in meeting your obligations. It is not a stamp of approval, not a certificate and not a guarantee; we deliberately do not use those words.
Want to think along before it is finished? We are looking for a limited number of firms and teams that use and shape the product before release. It costs nothing. What we ask in return is honest feedback: info@provenize.ai.
More for your field: AI on client files (legal & compliance) and searching old pentest reports without the cloud.
v0.1 · September 2026 · Back to the blog overview