The Machinery Regulation's logging rules for self-learning systems

When the old rules stop and the new ones start

The EU Machinery Regulation (EU) 2023/1230 comes into force on 20 January 2027, replacing the Machinery Directive that has been in place since 1989 ^[1]. If you put a machine on the market from that date onwards, the regulation applies. If you placed it before, the directive still governs it.

The shift matters because the regulation treats software as part of the machinery, with explicit rules about logging, traceability and protection against tampering. These aren't afterthoughts. They're written into the conformity requirements.

What counts as a safety-relevant software change

Think of it like the logbook in a lift. Every time someone adjusts the braking system or changes the speed settings, there's a record. The regulation asks for something similar: a log of changes that affect how safely the machinery works ^[1].

That log must be traceable for five years. The word 'traceable' means you can show what changed, when it changed and, where it matters, who changed it. If a machine injures someone three years after a software update, the log is what tells you whether that update played a part.

The regulation also says machinery must be protected against corruption. That includes deliberate interference and accidental damage to the software that keeps it safe ^[1].

Machines that learn as they run

Some machinery now changes its behaviour based on what it experiences. A robot arm in a factory might adjust its grip strength after repeated use, or a sorting machine might refine its decisions about which item goes where. The regulation calls this 'self-learning behaviour' ^[1].

For these systems, the manufacturer has to make sure there's a way to monitor what the machine is learning and to intervene if it starts doing something unsafe. It's the difference between a machine that follows fixed instructions and one that rewrites its own.

That monitoring isn't optional. If the machine can change how it works without anyone telling it to, someone has to be able to see what it's doing and stop it if needed.

The five-year question

Five years is a long time in software. The person who wrote the update might have left. The version control system might have been replaced. The company might have been bought.

The regulation doesn't care. If the machinery is still in use and something goes wrong, you need to show what the software was doing at the time ^[1]. That means keeping records in a way that survives staff changes, system migrations and everything else that happens in five years.

It's worth asking now: if someone questions a machine's behaviour in 2032, could you show which software version it was running in early 2028, and what that version contained?

What protection against corruption actually means

A machine protected against corruption is one where unauthorised changes to its safety functions don't go unnoticed ^[1]. That might mean access controls, monitoring, checksums or all three.

The point isn't to make the software impossible to change—sometimes you need to change it—but to make sure nobody can change it quietly. If an update gets installed, someone should know. If a configuration file gets edited, there should be a record. If something breaks, you should be able to see that it broke.

This overlaps with the logging requirement. A log of software changes is only useful if the log itself can't be quietly rewritten.

Sealing the record as it's made

Here, the thing to seal is each software release and each deployment event: the build fingerprint, the release notes, the test results and the record of when it was installed on which machinery. Sealing takes a fingerprint of the record, not the record itself, so the details never leave your systems.

The fingerprint goes to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back. To check later, anyone you share the record with calculates the fingerprint again and compares it. If it matches, the record is unchanged. Change a single character and it won't match.

That gives you a way to show, five years on, that the deployment record you're presenting is the one you made on the day. It doesn't show that the software was free of defects or that the machine was properly maintained, but it does show that nobody has rewritten the version history since.

How it would work

1. At each software release, seal the build fingerprint, release notes and test results.
2. At each deployment, seal the deployment event with the machine identifier and timestamp.
3. When questioned, present the record and let anyone check the fingerprint.

Your system sends the fingerprint to WitniumChain through the REST API, the SDK or the MCP server, and gets a witness ID back. To check, anyone you share the record with calculates the fingerprint again and compares it with the sealed one. The content stays with you. Read the docs for integration details. The first 2,000 witnesses a month are free.

What this means for you

If you manufacture machinery that will be placed on the EU market from 20 January 2027:

• Check whether your machinery includes safety-relevant software, and if so, whether changes to that software are logged and traceable for five years.
• If the machinery adjusts its behaviour based on experience, decide how you will monitor what it learns and how you will intervene if needed.
• Think about how you will show, years from now, which software version was running on a given machine at a given time.
• Consider how you protect the logs and records against corruption, including changes made by people with legitimate access.

What to watch

20 January 2027 is the date the regulation applies ^[1]. Notified bodies and market surveillance authorities will interpret the new rules as cases come up, so early guidance from trade bodies and standardisation committees is worth following.