How the drafting works

How the drafting works, and where accountability sits

A competent person should know how a draft was produced before putting their name to it. This page explains what the drafting layer is, the rules it runs under, what is recorded, and where accountability sits.

ProtechOS supports the drafting of documents from structured facts about the job — the activities, the site, the plant, the materials, the personnel and the programme. It is a drafting and cross-checking layer inside a wider system that governs finalised drafting, review, approval, issue and revision.

It is not a template filler, and it is not a black box that returns a finished document. The output is a draft with its gaps marked and its citations checked, which a competent person then reviews, edits where necessary, and approves.

The drafting layer is a large language model — currently Google's Gemini — used within the product under defined rules, with full logging of each drafting call. It works only from the facts, libraries and registers made available to it by the system for that job.

ProtechOS does not act as the authoring contractor, competent person, reviewer, approver, permit issuer, principal contractor or designer. Responsibility for checking, approving and issuing documents remains with the user's appointed personnel and duty holders.

The flow

From the pack to the log, and who decides at each gate

01

Pre-construction pack

System step: Author uploads
02

Fact check

Gate: Author confirms the site facts
03

Drafting

System step: System, from your facts and libraries
04

Citation check

System step: System, against the register
05

Markers

System step: System lists every [TO CONFIRM]
06

Review

Gate: Reviewer comments and sends back
07

Approval

Gate: Competent person, separate from authorship
08

Log

System step: Append-only, every step

Gate: a named person decides and is accountable System step: recorded in the drafting log

Guardrails

The rules the drafting runs under

Built into the product, not written in a manual. Each one is the reason a reviewer can trust the page in front of them.

Drafting constraints

It cannot invent a site fact: Where the system has not been given a fact, the document reads [TO CONFIRM by author]. It does not produce a plausible sentence to fill the space. Every marker is collected and listed for the author to resolve before approval.; Enforced in: DRAFTING
It asks before it drafts: Each document type declares the site facts it needs. Those are requested up front, so the gaps are closed before drafting rather than printed into a finished PDF.; Enforced in: DRAFTING
Citations are checked, not asserted: Every legislation reference is validated against a curated register of UK health and safety legislation. Findings are recorded on the document and visible before approval. Unresolved references are flagged, not buried.; Enforced in: REVIEW
Your wording, not a paraphrase: Your hazard bank, hold-point wording and PPE vocabulary are supplied to the drafting step, so the output uses wording your clients have already accepted.; Enforced in: DRAFTING
Environmental conditions come from data: Seasonal hazards are derived from thirty-year climate normals for your actual programme window, with the source named. Without programme dates it declines to assess rather than guessing.; Enforced in: DRAFTING
Model changes are disclosed: If the drafting step falls back to a different model, that is recorded on the document and shown to the reviewer. Silent degradation is not acceptable in a document someone signs.; Enforced in: REVIEW
Everything is logged and reproducible: Each call is recorded in full — instruction, model, response, tokens, latency — and can be replayed months later to explain why the document says what it says.; Enforced in: LOG
Approval is separate from authorship: The author cannot approve their own document. The two exceptions — an administrator override that needs a written reason, and a waiver for one-person organisations — are recorded as exactly that, never as independent approval.; Enforced in: DATABASE
The trail cannot be edited: The audit trail is append-only: a database trigger blocks update and delete, for your administrator and for us.; Enforced in: DATABASE

Accountability

Who is responsible for the document

The duty to assess risk and plan the work sits with the duty-holder under the Management of Health and Safety at Work Regulations 1999 and CDM 2015. Nothing about that changes because the first draft came from software rather than the last job's file.

What changes is the evidence around the decision. The author cannot approve their own document. The two exceptions — an administrator override that needs a written reason, and a waiver for one-person organisations — are recorded as exactly that, never as independent approval. The approval is recorded against a named individual at a specific revision. The trail of who changed what, and when, is append-only and cannot be rewritten afterwards.

That is the difference between a record you hand to an inspector wincing, and one you are glad to hand over.

Questions

What people ask

Does AI write our RAMS?

It supports the development of a draft. A competent person reviews, edits and approves it. The author cannot approve their own document. The two exceptions — an administrator override that needs a written reason, and a waiver for one-person organisations — are recorded as exactly that, never as independent approval. The document that leaves ProtechOS is one your competent person has signed off, and legal accountability for it sits with them exactly as it does today.

What stops it making things up?

Two things. It is not permitted to invent site facts — where it has not been told something it writes a [TO CONFIRM by author] marker instead of a guess. And every legislation citation it produces is checked against a register of real UK health and safety legislation before the document can be approved, so an invented regulation is flagged rather than published.

Why does the document have gaps in it?

Because we would rather show you a gap than hide it. A marked gap is a correct output when the system has not been given the fact; a confident guess is not. Every marker is listed on the document page so you can resolve them in one pass.

Who is liable if a document is wrong?

The competent people who draft and approve it, which is why segregation of duties, the confirmation step at approval, and the audit trail exist. ProtechOS does not provide health and safety advice and does not certify compliance. Any vendor offering you a compliance guarantee on a generated document is selling you something they cannot deliver.

Can we see what the system did?

Yes. Every drafting call is recorded in full and is reproducible later, and every change to a document is captured in an append-only audit trail that cannot be edited or deleted afterwards.

Private beta

Request beta access

Leave a work email. We will reply to arrange a call and run one of your own packs through it with you.