Technical publications
Maintenance, operation, installation and commissioning manuals, troubleshooting guides, illustrated parts and spares, and an HMI and interface reference.
Documentation Blueprint
What could your existing engineering knowledge become?
Tick what you already hold. The map shows the documentation it could support — and names what still needs a person.
Nothing is uploaded, scanned or connected. This is not an audit of your documentation — we have not seen it.
Steps 1 and 2
What do you have, and what could it become?
Select what exists anywhere in your organization — even if it is out of date or living in someone's head. Open any node for detail.
Select a source to light up what it could support.
Step 3
Reveal the full blueprint
The complete structure, every gap, and the first workflow we would recommend. It appears here immediately, and we email a copy.
We use your email to send the blueprint and follow up. See our legal information.
What the Blueprint contains
A structure you could hand to a technical author tomorrow
The reference library behind this page covers eleven deliverables across four families. Each one carries the sections a manufacturer is expected to produce, and each section declares the kind of source that could support it.
Interactive instructions
Digital work instruction packs and quality inspection packs — the steps, visuals, acceptance criteria and evidence to capture.
Training and assistance
Training packages built from procedures you have already approved, published in the interface languages your teams need.
Connected content and evidence
Where-used and review maps built from explicit source-to-content relationships, and a plan for the evidence execution should return.
Software and HMI
Your control software already wrote half a manual
The screens, parameters, alarms and error codes in your control software define most of what an operator will ever meet — and they are usually the least documented part of the product. Selecting software as an input unlocks an HMI and interface reference, the controls sections of the operation manual, and the error-code index behind troubleshooting.
How that content is produced
TwinWorks does not parse source code, PLC projects or HMI project files. Screen references, parameter tables and error-code indexes are authored as structured, reviewable content and kept linked to the software revision they describe. HMI screens appear in the documentation as labelled visuals with callouts.
- Screen inventory and navigation: what exists, how an operator reaches it, and which procedures depend on it.
- Parameters and setpoints: ranges, defaults, permitted limits, and who is allowed to change what.
- Alarm and error index: code, displayed text, severity, probable cause, operator action, reset condition.
- Diagnostics: service screens, test points and expected values, signal and I/O names.
- Version applicability: which firmware a screen belongs to, and what a revision changed.
Honest boundaries
What this page is, and what it is not
The Blueprint is a reference structure filtered by your answers. It is a useful starting point precisely because it does not pretend to know anything it has not been told.
Not an audit
This is not an audit of your documentation. We have not seen it. Nothing here scores, rates or diagnoses your current process.
Not a scan
Nothing is uploaded, crawled or connected. The page reads your selections and nothing else.
Not a delivery estimate
A structure is not a schedule. Effort depends on the state of your sources, the experts available, and the approval path you need.
What is credible: the section structures are the ones we use, the source mapping reflects verified TwinWorks import paths, and the gaps are named rather than smoothed over. Where a source informs content but is not machine-read, the Blueprint says so.
Related workflows
Go deeper on the deliverable you recognise
Documentation Blueprint FAQ
Is the Documentation Blueprint an assessment of our documentation?
No. We have not seen your documentation and the Blueprint makes no claim about it. It is the reference structure TwinWorks proposes for each deliverable, filtered to the sources you say you hold. Every number it shows counts our templates, not your maturity.
Do we have to upload anything?
No. Nothing is uploaded, scanned or connected. You tick the kinds of source your organization already holds and the page filters the reference structure accordingly.
Does TwinWorks read our source code or HMI project files?
No. TwinWorks does not parse source code, PLC projects or HMI project files. Screen references, parameter tables and error-code indexes are authored as structured content and kept linked to the software revision they describe.
What is the difference between the Blueprint and the Documentation Drift Scan?
The Blueprint answers what could be created from the sources you hold. The Documentation Drift Scan is a separate practitioner-led assessment that examines how exposed your current documentation process is. The Blueprint describes our structure; the Drift Scan examines your operation.
Which formats can TwinWorks actually import?
GLB, GLTF, FBX and OBJ import directly, and STEP/STP import is in beta. Engineering structures parse from 3DXML, and electrical schematics from QElectroTech and KiCad. PDF is the verified reference-document upload path. Every input on this page is labelled with how it reaches a document.
Build the blueprint, then review it with us
Select your sources, reveal the structure, and bring it to a working session. The meeting starts from work you have already done.