Industrial handover digest: offline evidence is moving into the brief

In industrial commissioning, the handover brief is getting stricter about where evidence lives and how a customer can verify it. For contractors, that changes the closeout task: a package is not finished just because files have been collected. It also needs to remain usable when the plant network is isolated, a cloud portal is unavailable or a customer wants to inspect the record independently.

That is the practical shift worth watching this month. Air-gap compliance, avoiding cloud vendor portals and repeatable FAT sign-off evidence are showing up as connected requirements. They are not interchangeable. An air gap is a network constraint; a portal-free handoff is a delivery choice; a manifest is a way to make the delivered evidence legible and checkable.

Offline is a handover constraint, not a storage preference

When a site requires an air-gapped process, the handover package has to cross the boundary in a form that works on the receiving side. That means the release needs to carry its own evidence and verification information rather than depend on a hosted workspace, account or live connection. Contractors should confirm that expectation early, before they settle on a workflow that assumes cloud access.

A useful baseline is a disciplined file structure, a revision record and checksums that can be verified offline. The point is not to add ceremony. It is to make it possible for the receiving team to establish what was delivered and whether the files have changed. Our earlier guide to building an air-gapped FAT evidence package covers that basic pattern.

Cloud portals can be convenient during collaboration, but they can also become a dependency at the point of transfer. If a client does not want a contractor’s portal in the handover path, the package must be portable and understandable without the contractor’s service. That is a useful procurement question: can the customer verify the release with ordinary offline tools, or does verification require a login or a particular application?

Standardize the evidence, not just the folder names

FAT sign-off evidence often spans different kinds of records: PLC and HMI backups, drawings, test results and approvals. A folder full of files does not, on its own, explain which revision is authoritative or whether all expected items are present. A manifest can provide that map. Pairing native files with readable versions where appropriate can help reviewers inspect the record without changing the source artifacts.

Teams should agree on the manifest’s contents before testing starts. Define what must be included, how revisions are identified, who signs off, and what happens when an expected file is missing or conflicts with the recorded revision. A consistent list is more useful than a late-stage attempt to reconstruct the evidence from individual engineers’ working directories. It also gives the receiving team a repeatable checklist across machines and projects.

There is no single universal manifest implied by these requirements. The contract and the site’s procedures still govern what counts as complete. The operational goal is narrower: make the package’s contents, revision state and integrity inspectable without relying on the person who assembled it.

Where local release tools fit

Membran Digital’s Viggen is positioned for local-first industrial automation handover and FAT/SAT evidence packaging. Its listed capabilities include SHA-256 integrity ledgers, revision guarding and support for air-gapped plant networks. It runs on Windows 10/11; macOS is on its roadmap. Those details line up with the offline and revision-control concerns, but a tool does not replace agreement on the client’s evidence requirements.

Viggen’s listed pricing is Free for five projects and Pro at $149 one-time for unlimited projects plus branding. That is a pricing structure, not evidence of a recent price move. The practical comparison for a commissioning team is whether a local release workflow saves enough closeout effort and reduces enough verification ambiguity to justify adopting it. For smaller jobs, a well-maintained folder structure and checksums may be sufficient. For repeated releases with stricter revision controls, a purpose-built ledger may be worth evaluating. A previous comparison of ZIP packages and local release ledgers sets out that distinction.

Questions to settle before the next FAT

• Network boundary: Must the package be assembled, transferred and verified without internet or cloud access?
• Portal policy: Does the customer permit a contractor-hosted portal, or must the deliverable stand alone?
• Evidence manifest: Which artifacts, revisions, approvals and readable copies are mandatory?
• Verification: What check can the recipient run offline to confirm file integrity?

Those decisions are easier to make before commissioning closes than after a machine is ready to ship. The direction for builders is straightforward: design the evidence handoff as part of the release, not as an administrative step that happens once the work is done.