Robotics documentation describes machines that can injure people, and it is read by engineers, integrators, safety assessors and eventually by operators on a factory floor who were trained once. That combination puts an unusual burden on the writing: it must be technically exact enough for a system integrator designing a cell, and unambiguous enough that an operator following a recovery procedure at the end of a shift does not put a hand somewhere it should not be. Documents in this field are also evidence — of the risk assessment you performed and the residual risks you communicated.

We edit what robotics companies and integrators produce — installation and integration manuals, safety requirement specifications and risk assessments, functional safety documentation and validation reports, operator and maintenance manuals, lockout and energy isolation procedures, teach pendant and programming guides, SDK and API documentation for robot control, simulation and digital twin documentation, cell design and layout documentation, commissioning and acceptance test procedures, CE and conformity documentation, training material for operators and technicians, and proposals and specifications for automation projects. Our editors check that safety-related instructions are written as unconditional actions, that terminology is consistent with the standards you are declaring conformity to, and that residual risks are communicated where the operator will meet them.

Recovery and fault-clearance procedures deserve the most editorial attention, because that is when people enter the working envelope of a machine that is powered, stopped, and about to be restarted. Normal operation is documented carefully everywhere; recovery is where manuals turn vague. We rewrite these so the isolation and verification steps come first and are stated as absolutes rather than recommendations, so the procedure names who is permitted to perform it and what training that requires, so the restart sequence explicitly re-establishes a known safe state rather than assuming one, and so each step says what to expect — the motion the arm will make on re-enable is exactly the thing an operator needs warned about in advance. We also separate what the operator may do from what requires a technician, since blurring that boundary is how well-meaning people end up inside a cell.

Everything you send is treated confidentially, including client cell designs, unreleased product documentation and safety files. We are editors rather than safety engineers and cannot assess conformity or approve a risk assessment, but we can make your documents unambiguous, consistent and appropriate to each reader — including for teams writing in English as an additional language.