Process history
The substantively readable history of the operation.
LEDGER ARCHITECTURE
Ledger Architecture: History Emerges Within the Process.
The ledger architecture describes how execution and its history remain connected. Recorded actions, state changes, reviews, and corrections form a shared history. Its substantive sequence and technical verification serve different purposes.
Evidence emerges within the process.
Event model
Every relevant step extends the process record.
When a person performs a work step, confirms a review, or corrects a value, the affected operation changes. 420+ records this change as an event with its time, object, state, and responsibility.
Data provenance connects data to their origin, the operations involved, and responsible actors, making it possible to trace how a record was created.
01
Execution
A person or a defined system process initiates the step.
02
Event
What happened, when, and by whom is recorded.
03
State
The affected operation and its objects are updated.
04
Evidence
Measurements, images, and documents remain assigned to the event.
05
Review or approval
The decision draws on the history so far and itself becomes part of it.
Human and system-generated events remain distinguishable.
Evidence is created during execution.
Traceability
One history. Three layers.
The same history serves three different purposes: it makes the operation understandable in substance, provides its review-relevant history, and preserves the technical connection between events.
What happened in substantive terms?
The process history connects action, responsibility, previous state, new state, and result into an understandable operation.
For a specific batch, this process history can also provide the technical foundation for an Electronic Batch Record: the EBR consolidates the executed batch as the domain record, while the ledger architecture protects its history and integrity.
Audit Trail
The review-relevant history of actions, decisions, and evidence.
Integrity chain
The technically verifiable connection between stored events.
The process history explains the operation. The audit trail organizes the review-relevant history. The integrity chain makes its connection technically verifiable.
Controlled change
A process record must not change unnoticed.
Corrections and reviews extend the process record without invisibly replacing earlier entries. Under the architectural principle of event sourcing, the current system state is built from an ordered sequence of events.
01What happens when a correction is made?
Block 01
Measurement recorded
- Measured value
- 18.2 °C
- Person
- Person A
- Time
- 10:42
Block 02
Correction added
- Reference
- Block 01
- Original value
- 18.2 °C
- Corrected value
- 19.2 °C
- Reason
- Transcription error
- Person
- Person A
- Time
- 10:57
Block 03
Correction reviewed
- Reference
- Block 02
- Decision
- Approved
- Review
- Person B
The original entry remains in place. The correction is appended as a new block and linked to the original entry.
Corrections do not change the past. They extend the history.
02What happens when a review is required?
Execution completedThe specified step has been carried out.
Review requiredThe configured process requires a documented decision.
Approval or returnThe decision becomes part of the process record as a new block.
If separation of duty is specified, the review must account for the people actually involved. An exception is possible only through an expressly defined procedure that permits it; justification alone does not override a binding separation requirement.
The review is not separate from the process record. It extends it.
Verifiable integrity
Integrity can be verified.
Permissions control who may act. An integrity chain can reveal deviations from a protected reference state. For this to work, the relevant verification values must be secured so that they cannot be replaced unnoticed together with the event data.
Simplified illustration for explanatory purposes.
Block 01Measurement recorded
prev0000…hasha3f9…Block 02Correction added
preva3f9…hash7c2e…Block 03Correction reviewed
prev7c2e…hashb1d8…
Ready to verify.
Check the connection between the three blocks.
The demonstration shows a mismatch between fixed example values. It does not calculate cryptographic hashes. If the data and all verification values are regenerated together, an internally consistent chain can result; only the protected earlier reference state enables comparison. The substantive correctness of a measurement remains a separate question.
External verification is possible.
Cryptographic verification data can additionally be retained by an independent party. This requires a defined recipient and a specified verification procedure.
420+Verification dataVerification
Verification can be designed without a public blockchain or tokens. Which verification data are transmitted to whom must be determined in advance; protected operational content must not unintentionally become inferable from the verification data.
The check verifies the consistency of the integrity chain—not the substantive correctness of the process.
Technical integrity replaces neither substantive review nor the operator's responsibility.
EXPLORE THE KNOWLEDGE BASE
Provenance, integrity, and change.
Further articles explain the central models behind a traceable process history.
Next step
A reliable history makes the actual workflow analyzable.
Process Mining uses the same event foundation to reveal how processes actually unfold, where variants arise, and which relationships should be investigated.