Change history • technical decisions • documentation

Technical decision history
with the full context of changes in the machine project

In machinery safety documentation, the final result alone is never enough. You need decision traceability: who changed a task status, when the risk reduction decision was recorded, why residual risk was accepted, and which declaration version applied at that moment. Safety Software gives you an audit trail tied directly to risk assessment, reduction measures and declarations—instead of leaving critical context buried in spreadsheets, Word files and PDF folders.

See the decision trail in a project What the system records
Audit trail and decision history

For teams that need to show not just the outcome, but the path that led there

An audit trail matters only when it is tied to real engineering work.

Safety Software records history where decisions are actually made: in task statuses, risk reduction, residual risk iterations, declarations, attachments and access decisions.

1 timeline
chronological decision history in the risk assessment documentation report
▲ UP
Change context
who changed what, when and why—linked to technical decisions in the machine project
▲ UP
KMS
encryption for sensitive risk-reduction history fields when KMS is enabled
▲ UP 
status_history:
  area: ISO 12100 task
  before: under review
  after: approved
  person: Anna K.
  time: 2026-05-13 10:42
  note: no additional hazards
Task status history

A task status change should not vanish inside an overwritten cell.

In risk assessment, the team works with tasks, operations, hazard sources and scenarios. When a user changes a status, the system can retain the previous and new state, the person, the timestamp and the technical note.

That means the report shows more than the current project snapshot. It also shows how the decision evolved and whether that part of the assessment was consciously closed, updated or sent back for further risk reduction.

  • task or operation status with change history
  • person, date and description of the change
  • context carried through into the risk assessment documentation
Risk reduction

A protective measure decision needs its own trail.

For risk reduction, it is not enough to know that a guard, interlock, procedure or warning was applied. What matters is who judged the measure effective, whether secondary hazards appeared, and what the result was after reduction.

The risk reduction history module records events against the specific hazard and assessment. That lets you reconstruct the decision path: reduction step, result, input data, user and change time.

  • decisions for each risk-reduction step
  • information on secondary hazards and residual risk
  • event linked to the specific hazard
risk_reduction:
  hazard: infeed zone
  step: technical measure
  event: decision_saved
  result: effective reduction
  context: safety distance measurement
residual_risk:
  iteration: 2
  method: HRN
  result: 12
  category: low
  acceptable: Yes
  note: additional guard + cleaning instruction
Residual risk iterations

Residual risk is a decision, not the last paragraph of the report.

After applying reduction measures, the team can revisit the assessment and record another residual risk iteration: method, result, category, acceptability and note.

This matters in retrofits, design changes and post-audit reviews. If the decision is challenged later, the system helps you show not just the final rating, but the earlier attempts, corrections and rationale as well.

  • successive post-reduction result iterations
  • result, category and acceptability of residual risk
  • technical note recorded with the decision
Declarations and resource access

It is not just risk assessment. Key document events stay in the history too.

In the declarations module, events are recorded for draft creation, updates, declaration issue and replacement of an earlier version. Separately, the system can log resource access decisions and events related to attachments.

This does not replace the manufacturer's organisational procedure, but it gives you a solid foundation: the history is no longer scattered across email, file names and chat comments.

  • history of declaration drafts, issues and replacements
  • events related to attachments and files
  • logging of resource access decisions
declaration:
  event: declaration.issued
  document: EU Declaration of Conformity
  version: 3
  replaces: version 2
  status: issued

What do you need to show when someone asks for decision history?

An audit trail is useful only when it ties the event to technical context. The date alone proves very little.

What you need
What Safety Software records
Person and time
Who made the change, when, and in which project area.
User ID, username and event time recorded against decision events.
Decision subject
Not a vague description, but the exact task, hazard, measure, declaration or resource.
Events linked to the assessment, hazard, reduction step, declaration, attachment or resource.
Technical context
Justification, result, category, acceptability, note or method input data.
Event payload and residual risk iteration data stored with the history entry.
Reporting
Ability to show history in documentation, not only in the admin panel.
The decision-trail section in the risk assessment documentation combines statuses, reduction and iterations into one timeline.
Data security
Access control and protection of sensitive history fields.
Risk-reduction trail data can be stored in encrypted fields when KMS support is enabled.

The difference shows up after a few months—not on the day the document is signed.

A qualitative comparison of what is usually left behind after technical decisions in a spreadsheet, a file folder and a structured decision trail.

The difference shows up after a few months—not on the day the document is signed. — dane tabelaryczne
reconstructability level (0-6) Spreadsheet File folder Safety Software
Ability to reconstruct decisions 1 2 6
Link to technical evidence 1 2 5

Decision history should run in parallel with the process—not be written in at the end.

The most credible audit trail is created during the work itself: when a task status changes, a reduction measure is recorded, residual risk is reassessed, a declaration is issued, or access to a resource is decided.

Decision history should run in parallel with the process—not be written in at the end. Os czasu z 5 wydarzeniami compliance. 1 — task or operation status change 1 task status 2 — risk reduction decision and secondary hazards 2 reduction 3 — residual risk iteration with result and note 3 residual risk 4 — declaration issue or replacement 4 declaration 5 — documentation report with decision timeline 5 report

This is not an event list for admins. It is the technical memory of the project.

A well-run audit trail lets you return to decisions after a retrofit, a complaint, an audit or a change in project ownership.

If, later on, you cannot reconstruct who accepted residual risk and on what basis, the documentation loses a big part of its evidential value.
Safety Software
decision history in risk assessment
An audit trail does not replace the manufacturer's responsibility. It helps show that the decision was not arbitrary, but the outcome of a structured process.
Safety Software
technical documentation and conformity

Common questions about the audit trail

Does an audit trail mean every decision is automatically correct?
No. The system does not independently judge the correctness of a technical decision and it does not replace the manufacturer's responsibility. Its job is to organise the history: who made the decision, when, what it concerned and the context behind it.
Does the change history cover only risk assessment?
It is most visible in risk assessment, risk reduction and residual risk, but the application also records events for declarations, attachments and resource access decisions.
Does the decision trail go into the risk assessment documentation?
Yes. The documentation module can build a decision-trail section from task status history, risk reduction events and residual risk iterations, showing events as a clear timeline with technical context.
Can the history be deleted?
The system shows a structured trail of work in the project and helps reconstruct the context of technical decisions. The visible scope of history, permissions and the way data is presented may depend on system configuration and user role. We are not claiming an immutable register. We are claiming better decision traceability than spreadsheets, PDF files and documents sent by email.

Stop relying on file names and team memory to explain project history.

Run risk assessment, risk reduction, residual risk, declarations and documentation in one process where decisions leave a clear trail.

Start the audit trail in your project

The best test is simple: one machine, one engineering change, and one reconstruction exercise—who changed what, when and why.

Practical articles on risk assessment, machinery directives and compliance — supporting this product page.