Safety & Responsible Use Guide

1. Who PLCflow is for

PLCflow is built for qualified controls engineers, automation specialists, and PLC programmers working on industrial control systems. We assume the user has the training and judgement to evaluate generated logic, recognise functional gaps, and determine whether output is safe to deploy.

For the purposes of this guide, a qualified controls engineer is a person who (a) has formal training and demonstrable experience in industrial control system design and commissioning, (b) is trained and authorised by their employer (or client) to commission industrial control logic on the target equipment, and (c) has competency consistent with the requirements of IEC 61511-1 clause 5.2.2 or an equivalent regional standard. Relevant credentials include ISA Certified Automation Professional (CAP), ISA Certified Control Systems Technician (CCST), TÜV Functional Safety Engineer, or equivalent.

If you are not a qualified controls engineer, do not deploy PLCflow output to live equipment.

2. The review obligation

Every output from PLCflow must be reviewed and validated by a qualified controls engineer before it is deployed. This is non-negotiable. The platform produces draft logic at speed; the human engineer is the safety boundary.

At a minimum, your review must cover:

• Tag references and addresses match the actual hardware
• Permissive and interlock logic behaves as intended in every operating state
• Failure modes are handled — sensor faults, comms loss, power-up, e-stop reset
• Timing, sequencing, and edge-triggered logic produce the right behaviour under load
• Alarms, faults, and operator messages are wired to the correct destinations
• The code compiles cleanly on the target controller and matches your project's coding standard

3. Not acceptable uses

PLCflow output must not be used as the implementation of any safety function without independent safety-rated hardware and a formal safety lifecycle process. Specifically, do not use PLCflow output as the sole implementation for:

• Emergency stop circuits or any SIL-rated / PL-rated function
• Burner management systems (BMS) or fired-equipment safety interlocks
• Light curtains, safety mats, two-hand controls, guard locking, or any other machine guarding interlock
• Fire detection, fire suppression, or gas release systems
• Pressure relief, over-temperature, or runaway protection
• Aviation, medical device, nuclear, or any other regulated safety domain
• Any function subject to a safety requirement specification developed under a formal HAZOP, LOPA, or equivalent hazard analysis
• Any function whose failure could cause injury, environmental damage, or significant property loss

Safety functions belong on safety-rated PLCs and safety relays, with logic developed under a formal safety lifecycle (V-model, hazard analysis, validation testing) by an engineer competent in functional safety. PLCflow does not produce that kind of artefact and must not be substituted for one.

4. Standards we reference

If your application is in scope of any of the following standards, your safety functions must be implemented and verified under that standard's process. PLCflow output is not a substitute for that work.

• IEC 61508 — Functional safety of electrical / electronic / programmable electronic safety-related systems
• IEC 61511 — Functional safety: safety instrumented systems for the process industry
• IEC 62061 — Safety of machinery: functional safety of safety-related electrical, electronic and programmable electronic control systems
• ISO 13849 — Safety of machinery: safety-related parts of control systems
• ANSI/ISA-84 — Functional safety: safety instrumented systems for the process industry sector
• NFPA 79 — Electrical standard for industrial machinery
• IEC 62443 — Security for industrial automation and control systems (cybersecurity of OT environments and supply chain)

5. Commissioning checklist

Before deploying PLCflow output to production, work through the following at a minimum:

• Static review — read every routine, every rung, every line
• Compile and download to a test controller, not to the live one
• Simulate the logic against expected I/O states using your platform's emulator
• Bench test against actual or simulated hardware where possible
• Loop check every input and output on the real machine before energising
• Dry run the sequence with motors / valves / actuators isolated
• Wet commission only after the dry run has confirmed expected behaviour
• Document the changes, the test results, and who signed them off

6. AI features specifically

Some PLCflow features (Code Analyzer, Comment Helper, Command Center) use a large language model under the hood. LLMs can produce confident-sounding output that is partly or wholly wrong. They have no understanding of your physical process, your hardware, or your safety case. Treat their output as a starting point for review — never as a finished answer.

If a prompt mentions safety-critical equipment or terminology (E-stop, light curtain, safety PLC, SIL, PL-d, burner management, etc.), the AI features are designed to refuse to respond. This safeguard is intended to prevent casual misuse in safety contexts, but it is a best-effort mechanism rather than a guarantee — you must not rely on it, and you must continue to apply the review obligation in Section 2 to every output regardless of whether a refusal was triggered. If you encounter a refusal on a legitimate non-safety request, rephrase the prompt to remove the trigger terminology.

7. Confidentiality of submitted logic

Logic, tags, and project context that you submit to PLCflow are handled in accordance with our Privacy Policy. Customer logic is not used to train third-party foundation models, and access is limited to the minimum personnel and systems required to operate the service. If your project is subject to export controls, classified information rules, or customer confidentiality agreements, confirm that PLCflow's data handling is compatible with those obligations before submitting logic.

8. Reporting a safety concern

If you believe PLCflow output is dangerously wrong, or you have observed an incident in which PLCflow output was a contributing factor, contact us immediately at [email protected]. This inbox is monitored for safety-related reports and we aim to acknowledge receipt within one business day. For non-safety issues, general support remains available at [email protected].

When reporting, please include: the affected feature, a description of the output and the expected behaviour, the target controller and firmware version, and — if safe to share — a redacted copy of the prompt or input that produced the output.

9. Acknowledgement

By creating an account and by each use of PLCflow, you confirm that you have read the current version of this guide, that you are a qualified controls engineer (or working under the direct supervision of one) as defined in Section 1, and that you accept full responsibility for reviewing, testing, and commissioning every output before it runs on real equipment. Continued use of the service after a material update to this guide constitutes acceptance of the updated guide.

For the related legal terms — including warranty disclaimers, limitation of liability, and indemnification — see our Terms of Service and Privacy Policy.