How much can we trust a system’s record of change?
In development · Running system using sample data
Pranee Audit explores a simple but difficult question. When a system says something changed, who changed it, or what state it used to be in, how much can we trust that evidence?
It is an audit trail engine for recording and checking events. The images in this account come from version 0.9.0 running with sample data. The product and this account are both still in development.
A record leaves another question
An event record helps show who did what and when, including values before and after a change. But reading the list alone is not enough if the stored information can be edited afterwards.
I am interested in another layer of the question: can we check that what we are reading still matches what was recorded? Looking up events and checking the continuity of evidence are related, but answer different parts of the problem.
A result that needs its context
In the simulated test, an event was edited after storage. The verification result identifies a problem at sequence 84 because its hash no longer matches the stored record.
Detecting a change does not mean preventing every change
This evidence shows a mismatch detected in one simulated test. It does not establish prevention of every form of editing or deletion, commercial readiness, compliance with a standard, or detection of every kind of threat.
A verification result and a chain state are different parts of the account
The simulated test includes a separate broken-chain state, distinct from the selected-range verification result. These two parts should not be read as a continuous change of status.
This section explains the distinction in text, without showing the broken-chain image. The verification image above is therefore not visual evidence of that state.
Checking for change leaves the question of what to record
Checking that information still matches what was recorded is a different question from choosing what to record in the first place. For me, trustworthy evidence therefore involves more than detecting change. It also means considering which information needs to be kept.
In an event-detail screen using sample data, email addresses appear as transformed values and phone numbers are partly masked. Names and other context remain visible. This example shows why masking some fields does not answer whether all the information that remains is appropriate to keep.
The principle I want to preserve is to consider personal information before it becomes evidence that needs to be retained. Checking a hash does not decide for us whether that information is necessary, or resolve the choice to collect more than is needed.
This is design reasoning, not confirmation that the system handles personal information across every path. A screenshot cannot establish whether information was handled before storage or only when displayed, or how it is handled elsewhere in the system. Those questions still need examination of actual behavior.
What still needs examination
This test does not cover every condition involved in preserving and verifying evidence. Questions remain about how access boundaries and separate verification affect the conclusions.
Returning to what was checked
I want to return to a result together with its conditions: which range was checked, what it found, and which status it did not update, rather than keeping only “a problem was found”.