Build an air-gapped FAT evidence package that can be checked offline

A FAT evidence package is not ready just because its files are in a ZIP. The recipient needs to identify what each artifact is, see which revision it represents and check that the package has not changed in transit. That matters most on an air-gapped plant network, where a cloud account is not an option.

Build the release around three things: a clear inventory, readable evidence paired with source files, and an offline integrity check. The same discipline makes industrial automation closeout less dependent on whoever happens to remember the project folder.

1. Define the release before collecting files

Start by recording the machine or system covered by the handover and the release point you are documenting: for example, the FAT closeout or a later handover revision. Set a cut-off for what belongs in this release. If a file changes after that point, treat it as a revision to assess, not an invisible replacement.

Use a consistent naming pattern that identifies the system, artifact and revision. Keep the naming practical: a customer should be able to distinguish a PLC backup from a drawing without opening every file. Avoid filenames that rely on “final” or “final-new” to explain what changed.

Make an inventory as you assemble the evidence. A master document register gives the reviewer a single place to see what is included. It should correspond to the actual files in the package, not to a wish list of documents that were never supplied.

2. Pair native files with readable evidence

Preserve the native PLC backup as the source artifact. Pair it with a readable PDF of the relevant logic or supporting evidence where one is available. The native file is what a controls engineer may need to work with; the PDF gives a reviewer a way to inspect the evidence without relying on the original engineering environment.

Apply the same principle to other handover material. Include the drawings, HMI backups and signoffs required for the release, and make each item traceable in the inventory. Keep related files together logically, but do not let folder structure stand in for a register. A directory tree cannot tell a customer whether a required artifact is missing or whether a backup is the expected revision.

For a broader comparison of nested folders and local release records, see the trade-offs between FAT package ZIPs and local release ledgers.

3. Record revisions, including mismatches

For each controlled artifact, compare the revision expected for the release with the revision actually present. Record the result before export. If they do not match, resolve the discrepancy or make it explicit; silently substituting a newer file weakens the handover record.

Keep a revision log that identifies what changed between releases. A new release should supersede the earlier one rather than obscure it. This gives the receiving team a way to understand whether a drawing or PLC backup belongs to the package they are checking.

Membran Digital describes Viggen as a local-first tool for industrial automation handover and FAT/SAT evidence packaging. Its listed capabilities include revision guarding, a SHA-256 integrity ledger, native-to-readable-PDF pairing and exports that can be verified without installing Viggen. The company lists the Windows 10/11 product as coming soon; this workflow does not depend on that tool being available.

4. Export, then verify on the plant laptop

Before transfer, check that the package contains the files named in the register, the readable evidence paired with its native source, and the revision information needed to interpret them. Generate or use the SHA-256 checksum manifest for the release. A checksum is useful only when the recipient can compare it with the files they actually received.

On the plant laptop, use an approved SHA-256 utility to calculate the checksums of the received files and compare the results with the manifest. Where available, a command-line tool such as shasum can perform this check. A mismatch means the file and manifest do not agree; stop and investigate before treating the package as verified. Opening a PDF successfully is not an integrity check.

Keep the manifest with the exported package and make the verification method clear to the recipient. Viggen’s described export includes a PDF dossier and ZIP, along with checksums and a manifest; its stated design is local-first, with air-gapped plant network support. Its SHA-256 ledger is intended to support verification offline.

5. Make readiness visible

Before signing off, check the package against the release scope: required artifacts present, source and readable evidence paired, revisions accounted for, and checksums verifiable on the receiving machine. List unresolved items rather than burying them in comments or assuming the next team will find them.

A good FAT evidence package lets another engineer answer three questions without a call: what is included, which revision is authoritative, and whether the files match the release record. That is the standard for an air-gapped PLC handover—not a particular folder layout, and not a cloud link that the plant cannot open.