The private, hash-chained ledger architecture

Every relevant event is recorded in 420+ as a standalone entry – for instance a completed task, a measurement, a release, a block, a batch movement, a correction or a follow-up decision.

Each new entry contains a cryptographic fingerprint of its predecessor. This creates a continuous, cryptographically linked chain of events in which the individual records are technically connected to one another.

Existing entries are not overwritten. If a value needs to be corrected, supplemented or reassessed, a new event is created. It remains linked to its origin and documents what was changed, who made the change and when it occurred.

This keeps the following traceable:

• what was originally recorded,
• which correction or follow-up decision was added,
• who was responsible for the respective step,
• and how the state of a process developed.

If an earlier entry is changed after the fact, its cryptographic fingerprint changes as well. The chain then no longer matches the previously formed chain of events. Such a discrepancy can be detected during verification.

The architecture is therefore tamper-evident: later changes cannot go unnoticed, provided that check values, reference points, keys and verification mechanisms are properly protected.

It is not the mere existence of an audit trail that makes the difference, but the ability to verify the integrity of its chain of events technically.

The value does not lie in a blanket promise of immutability, but in the traceable, cryptographically verifiable connection of all relevant events.

Recognised data integrity guidance places a requirement on audit trail functionality that goes beyond its mere existence: the functionality must be enabled and locked at all times. It must not be possible to deactivate, delete or modify it. Where administrative users are nevertheless able to do so, that circumstance must itself create an entry in the audit trail.

Most systems meet this requirement through permission settings. Immutability then becomes an assurance: it has to be configured, maintained and evidenced as a setting during an inspection – and it can be withdrawn by the same means that established it.

In an append-only, cryptographically chained architecture the same property follows from the construction. The evidence is not the description of a setting, but the chain itself.

There is no switch that suspends logging, and no way to alter an existing entry without breaking the verification chain.

This statement concerns the requirements for audit trails. It does not mean that the remaining requirements for computerised systems – such as backup, archiving, access management or validation – are met in a specific deployment. Their assessment remains the responsibility of the operator.

Data integrity guidance requires that critical audit trail entries be reviewed before a process is completed – for instance before a release – and that this review be documented. In practice it usually sits in a written procedure and is not enforced from there.

The batch record shows the state that was reached. Only the chain of events shows what was changed, corrected or added along the way. Irregularities of that kind become visible only if someone looks before release.

The workflow engine in 420+ supports mandatory steps that block completion until they are documented. The audit trail review can be set up as such a step ahead of releases.

Whether it is depends on the operator and the process – wherever the risk justifies it. The review is then recorded like any other step, with reviewer, time and outcome. Where a second person is required, the same four-eyes principle applies as at other critical points.

The hash-chained architecture supports in particular:

• the attribution of events to people, roles and points in time,
• an enduring and consistent history,
• the connection of origin, correction and follow-up decision,
• the detectability and technical verification of later changes.

A measurement therefore does not remain isolated. It becomes part of a traceable context of creation, responsible person, point in time, further processing and possible corrections.

A release, too, does not stand apart at the end of a process. It remains connected to the tasks, evidence, states and decisions from which it emerged.

The cryptographic chaining is an additional integrity layer within the platform. It makes the audit trail of 420+ technically verifiable and does not replace validation, permission concepts or organisational controls – it complements them.

It does not guarantee that an originally entered value is factually correct. If, for example, an incorrect measurement is recorded, the chaining cannot assess its factual accuracy. It can, however, document in a traceable way when and by whom the value was recorded, how it was further processed and whether a change, correction or follow-up decision occurred later.

The architecture thus protects the integrity of the history – not automatically the factual quality of each initial value.

A cryptographically chained sequence of events also remains part of an overall system. Its effectiveness requires that check values, keys, reference points and verification mechanisms are adequately protected.

Access control, separation of roles, four-eyes principles, time synchronisation, backup, monitoring, audit trail reviews, training, SOPs and validation remain an indispensable part of the operating system. Assessment and validation in the specific deployment remain the responsibility of the operator.

Where the architecture directly addresses a regulatory requirement, we name it. This concerns the requirements for the immutability of audit trails. Other requirements for computerised systems are not thereby fulfilled.

420+ supports the requirements for data integrity. The architecture does not, however, establish automatic GxP, Annex 11 or Part 11 conformity.

The 420+ ledger architecture requires no public blockchain, no token and no freely accessible network.

Your operational data remains within the intended infrastructure and under your control. The cryptographic chaining does not serve the public distribution of information, but the traceable safeguarding of operational events.

Tasks, measurements, batch movements, releases, blocks and evidence are not merged only at the end of a process or sealed after the fact. They become part of the same chain of events as they are created.

Precisely because these events arise within the same platform, the cryptographic chaining can capture them continuously and without media breaks. A ledger placed on top of external systems afterwards cannot establish this process proximity and completeness in hindsight.

The chain of events can be carried along synchronously as a second, independent proof strand – for instance at an authority or an independent third party. This strand is created in real time at the moment of capture, not as a subsequent copy. It requires an independent body that receives the strand.

No operational data needs to be disclosed for this. The cryptographic proof is sufficient to check whether the chain of events has been altered since a defined point in time.

Whatever has once arrived in the independent strand can no longer be changed after the fact – not even by the operator. Whether and in what form such a strand is maintained in a specific deployment depends on the risk profile, the validation concept and the receiving body.

A history that is merely documented becomes a chain of events whose integrity can be verified technically.