LinkedIn newsletter
Write it Safe. Prove it Safe.
Turning complex safety into usable information
My newsletter on LinkedIn about turning machine safety, evidence and compliance into usable information: emergency stops, interlocks, risk assessment, safety and security, lifecycle documentation and AI in the safety evidence chain.
The issues are written in English. At the start, two issues appeared per week, then one per week. New issues now appear once a month, on Fridays at 9 pm Central European Time.
Archive
All issues
Each card shows the original title, a short summary written for this page and the focus areas the issue relates to. The links lead to the issues on LinkedIn. The follow-up to issue 1 is marked as such and does not count as an issue of its own.
Filter by focus area
No issues match this focus area.
-
Tracing AI decisions and actions in R&D and V&V
An authorised AI workflow can produce a result without leaving enough evidence of how that result became a development decision or a verification outcome. Building on the AI TechDoc Knowledge blueprint ‘AI systems and the machine: levels and boundaries’, the issue asks for R&D and V&V whether the record can show who or what made a decision and triggered the next step.
-
Why Safety and Security must iterate — but never share a single process
Safety and security work on the same technical system but defend against hazards that move in opposite directions, with different standards, methods and evidence. The issue argues that the two domains must exchange feedback but never merge into one process; the revised edition of 1 October 2026 adds a correction notice and an extended appendix.
-
From structure to meaning to evidence to using the EvoOntology AI-Model
When a guard-door switch changes, the update has to reach the machine configuration, the affected safety function, the inspection instruction and the released evidence. Using the MX-Y7B400 example, the issue shows how canonical models, ontologies and an AI-supported EvoOntology layer lead from structure to meaning to evidence, with every proposed model change going through technical review.
-
AI in machinery — why 2027 is currently more important than 2028
Discussions about AI in machinery often focus on 2 August 2028, but for machinery with AI functions the relevant shift comes earlier, on 20 January 2027, when the Machinery Regulation (EU) 2023/1230 starts to apply. With reference to the Digital Omnibus Regulation, the issue explains why AI functions in machinery follow a sector-specific conformity route and which functions require assessment from 2027.
-
Lifecycle documentation: The new backbone of technical communication
Lifecycle documentation replaces the idea of a finished manual with a continuous, safety-relevant information flow from development through operation and maintenance to modernisation and digital updates. The issue describes how the Machinery Regulation (EU) 2023/1230 formalises this shift and what it means for maintenance documentation and the digital elements of machines.
-
Safety Information Readability and Usability
Risk management often fails where nobody transfers the safety logic into information that people can actually work with. The issue describes what makes safety information in internal technical documentation readable and usable for R&D, Safety, Regulatory and Quality, without inventing a second risk-assessment language.
-
Material handling machines: systemic risks and recurring failure patterns
The hazards of material handling machines arise from continuous interactions: constant motion, limited visibility, narrow spaces, unclear responsibilities and routine behaviour. The issue describes evidence-based methods, such as incident and near-miss data, fault logs and observation at transfer points, that reveal recurring failure patterns traditional assessments often miss.
-
When safety evidence becomes a system in Machine Safety and MedTech
Safety-critical products in machine safety and MedTech rarely lack documents; the problem starts when risk assessments, V&V results, manuals and post-market information must jointly prove that a product is still safe after a change. Drawing on research on model-based assurance evidence management and safety cases, the issue describes safety documentation as part of a managed evidence system across the lifecycle and across expectations in the EU, the United States, Canada and China.
-
When AI enters the Safety Evidence Chain
AI does not have to control a machine to become safety-relevant; it only has to change the information people use to operate, maintain or approve it. The issue looks at AI-supported technical documentation as part of the evidence chain, at the governance mindset of the EU AI Act and at what documentation teams need to control, from classifying AI use to tracing sources.
-
From Semantic Drift to AI Drift: when signals change meaning
Semantic drift is the moment when a signal, state or command still looks valid but no longer carries the meaning the system or the documentation assumes; AI drift extends the problem to interpretation itself. Using a robotic cell whose ‘ready’ status changes meaning between versions, the issue applies the discipline of calibration to meaning: reference, tolerance and acceptance criteria.
-
Implementing control: when motion becomes a safety function
Identifying a hazard point is only the beginning: the safety concept then has to define how control reduces the risk. Following on from issue 15, the issue traces cause and effect from hazardous movement and access situation through detection, control response and safe state to response time and the verification of the safety-related control function.
-
Hazard points and machine motion
Safeguarding does not start with the choice of a guard but with what moves, how it moves, where people can reach it and which energy is present. The issue explains how injury mechanisms such as entanglement, crushing, shearing or drawing-in define a hazard point and why the name of a machine says little about its risk.
-
API Safety and MBSE: why interfaces must become system elements
An unsafe API rarely fails as isolated software; it fails where system context, architecture, security constraints and verification evidence no longer fit together. The issue explains how Model-Based Systems Engineering places API documentation in a wider engineering context and treats interfaces as system elements with consequences for risk, verification and lifecycle.
-
Where APIs hide inside modern interlinked machinery lines
A modern food processing and packaging line is a cyber-physical system in which PLC safety logic, authenticated data flows, cloud services and external APIs interact. Using a representative line from intake to palletising, the issue shows where APIs hide and why their documentation becomes part of the safety, security and compliance evidence.
-
Evidential systems focus of interlocks
From the system side, an interlock provides evidence but does not by itself establish system truth. The issue follows the chain from safety inputs through diagnostic processing, safety functions, state and mode logic and safe states to validation and PL/SIL evidence under ISO 13849.
-
Operational user focus of interlocks
Operators do not experience an interlock as PLC logic but as a condition such as ‘Guard closed’ or ‘Safe to start’. The issue shows how a user manual translates the safety intent of an interlock into operational meaning: what the visible condition allows or prohibits at the machine.
-
Why security fails: the blind spot between safety and security thinking
Safety and security share the same formal structure but look in opposite directions, and most organisations design, audit, train and document them separately. The issue traces the resulting blind spot across ships, ports and industrial production lines and outlines how combined safety and security thinking can close it.
-
ISPS and industrial security: one prevention logic for ships, ports, rail, machinery, and OT
ISPS and industrial security follow the same prevention logic: identify intentional threats, assess vulnerabilities and consequences, define proportionate controls and verify them in a PDCA cycle. Using passenger ships, container ships, ship machinery, train manufacturers and train operators, the issue distinguishes security, which asks what people can do to a system, from safety, which asks what a system can do to people.
-
Latency chains in IT/OT Security: why technical speed is a governance issue
Every technical system is a chain of stages, and the slowest stage determines the behaviour of the whole. The issue uses latency chains to make dependencies, control points and evidence chains in IT/OT visible and shows how ISO 27001 controls support governance under the Cyber Resilience Act.
-
The Documentation Latency Chain: the hidden gap between machine reality and documented reality
Machines often change faster than the documentation around them: a component is replaced, firmware changes, a vulnerability is published. The issue introduces the term documentation latency chain for the time lag between machine reality and documented reality and shows how PLM and ILM together can close it across risk assessment, PL evidence, CRA evidence and manuals.
-
Manuals, SOPs, and SIMOPS: why document type is a safety boundary
Procedures often fail because the wrong kind of document was published, such as a generic guide where a behavioural standard was needed. The issue sets out what manuals, SOPs and SIMOPS rules are each responsible for and treats documentation as a management instrument for parallel work, shift handovers and contractor interventions.
-
Lubrication data is a safety control
Lubrication and media documentation defines operating limits, compatibility and the isolation steps that prevent hazardous releases, and is therefore part of the safety architecture. The issue looks at it from the safety, compliance and documentation side, separates manufacturer and operator duties using a linked paper-industry line and an offshore plant, and shows how media belong in the risk assessment.
-
Industry rules change — Information discipline doesn’t
Automotive, food processing, pharmaceuticals, chemicals and marine each have their own rules, but they share one failure mode: information drift on the way from regulators through manufacturers and integrators to operators. The issue borrows Information Lifecycle Management from IT so that safety information stays available, trusted and owned throughout its lifecycle.
-
ISO 12100 is everyone’s business
ISO 12100 is the shared risk language that connects design, purchasing, operation and documentation, not a topic for the CE team alone. The issue describes how to keep working with it while it is not yet harmonised under the Machinery Regulation (EU) 2023/1230 and why the system definition belongs in chapter 1 of the operating instructions.
-
CE-focused view: E‑Stop versus Power‑Off as a conformity and evidence question
This follow-up to issue 1 is written for CE teams: the engineering is often correct, but the evidence chain from protective measures to information for safe use is not expressed clearly enough. It treats conformity evidence as one coherent safety argument across integrated lines, multiple suppliers and lifecycle changes and points to established machine safety experts in the DACH region for further orientation.
-
Documentation and HMI: the place where concepts either stay sharp — or get blurred
Operating instructions often leave out safety functions such as presence-sensing devices, on the assumption that operators do not interact with them. The issue explains why the purpose, coverage and limits of these devices, the difference between stop and power isolation, and the conditions for reset and restart belong in the manual and the HMI, also with a view to the Machinery Regulation (EU) 2023/1230.
-
Writing emergency stops right: why documentation shapes E‑Stop versus Power‑Off understanding
Emergency stop concepts in interconnected lines are often engineered with care, yet manuals, HMI texts and LOTO instructions blur Emergency Stop and Emergency Power-Off. Using hotforming lines as an example, the issue shows how stop functions, zones, energy domains and reset discipline have to be described so that people expect what the machine actually does.
LinkedIn shows its own recommendations on article pages, including articles by other authors. They are not part of this newsletter.
My other newsletter on LinkedIn: Cut Complexity — Create Clarity