Skip to content
HoldField

DeployWorks

Installable on-prem — signed, preflighted, rollback-ready

Deploy HoldField on-prem, offline, plant-LAN, or hybrid read-only with signed manifests, preflight checks, backup and rollback proof, and a redacted customer install packet — and no remote-control authority.

Step 01

Deployment mode

Choose the deployment pattern — single-station, multi-station, air-gapped, plant-LAN, customer DMZ read-only, hybrid read-only fleet, service laptop, or enterprise site — without changing station authority.

Inputs

  • Site profile
  • Station scope
  • Network policy
  • Support model
  • Offline policy
  • Backup policy
  • Customer IT/OT constraints

Proof generated

  • Deployment plan receipt
  • Selected mode
  • Station scope
  • Policy references
  • Blocker list

Where it appears in the app

  • DeployWorks
  • EnterpriseGuard
  • Stations
  • Capabilities

AI Sense support

  • Checks the mode against network, hardware, backup, and security constraints
  • Flags a mode that does not fit the site
  • Explains the required proof before an install review

Safety boundary

  • Deployment mode does not grant physical or remote-control authority.

Step 02

Package manifest

Every deployment package carries a deterministic manifest — components, artifact hashes, SBOM and license references, required services, forbidden capabilities, and a rollback package reference.

Inputs

  • Package version
  • Component list
  • Artifact hashes
  • SBOM references
  • License references
  • Required services
  • Deployment-mode compatibility
  • Rollback package reference

Proof generated

  • Package manifest receipt
  • Component checksums
  • Forbidden-capability list
  • Allowed deployment modes
  • Manifest hash

Where it appears in the app

  • DeployWorks
  • SignedPacks
  • Trust

AI Sense support

  • Flags a missing manifest field
  • Flags an incompatible deployment mode
  • Flags forbidden-capability drift

Safety boundary

  • A manifest describes the package. It does not install or activate anything.

Step 03

Integrity verification

Every package is verified against its manifest — hash match, real signature, an authorized and non-revoked signer, a valid policy, and an explicit test-key rejection — before any install review.

Inputs

  • Manifest hash
  • Artifact hashes
  • Signature
  • Signer authorization
  • Key revocation status
  • Signing policy version

Proof generated

  • Integrity verification receipt
  • Hash-match result
  • Signature-valid result
  • Test-key-blocked result
  • Blocker list

Where it appears in the app

  • DeployWorks
  • SignedPacks
  • EnterpriseGuard

AI Sense support

  • Explains a signature failure or hash mismatch
  • Flags a stale signing policy
  • Flags a revoked-signer risk

Safety boundary

  • Integrity verification records a result. It does not activate production behavior.

Step 04

Hardware checklist

Confirm hardware readiness — EdgePod, camera, lighting, fixture, network switch, UPS, tablet/PWA, local storage, and a backup target — with an optional GPU badge, before an install review.

Inputs

  • EdgePod CPU / RAM / storage
  • Camera readiness
  • Lighting readiness
  • Fixture readiness
  • Network switch
  • UPS
  • Tablet / PWA device
  • Local storage capacity
  • Backup target
  • Optional GPU

Proof generated

  • Hardware checklist receipt
  • Per-item status
  • Evidence references
  • Blocker list

Where it appears in the app

  • DeployWorks
  • Stations
  • Commissioning
  • EnterpriseGuard

AI Sense support

  • Flags missing hardware
  • Flags under-sized storage
  • Flags stale device health or an unsupported topology

Safety boundary

  • Hardware readiness does not mean a station is safe or production-approved.

Step 05

Network / firewall matrix

Every network flow is labelled — local station runtime, redacted export, support bundle export, customer portal read-only, counts-only ops metrics, or a blocked command path — with no raw evidence and no command path.

Inputs

  • Source
  • Destination
  • Protocol and port
  • Direction
  • Data class
  • Required / optional
  • Deployment mode

Proof generated

  • Firewall matrix receipt
  • Per-flow data class
  • Command-path-blocked marker
  • Raw-evidence-not-allowed marker
  • IT/OT-review export

Where it appears in the app

  • DeployWorks
  • EnterpriseGuard
  • Trust

AI Sense support

  • Detects a missing firewall rule
  • Detects an overbroad flow
  • Detects a raw-data-leak or command-path risk

Safety boundary

  • Portal, fleet, and ops flows are publish / export only. They do not command hardware or carry raw evidence.

Step 06

Secrets / certificates

Certificate and service-account status is visible — validity, expiry, rotation, revocation freshness, and customer-provisioned certs — while raw secrets, tokens, and private keys are never displayed.

Inputs

  • TLS certificate status
  • Certificate expiry
  • Service account status
  • Token rotation status
  • Customer-provisioned certificates
  • Offline signing trust
  • Revocation-list freshness

Proof generated

  • Certificate status receipt
  • Per-certificate status
  • Expiry timeline
  • Rotation state
  • Blocker list

Where it appears in the app

  • DeployWorks
  • EnterpriseGuard
  • Trust

AI Sense support

  • Flags an expiring certificate
  • Flags missing rotation
  • Flags a stale revocation list or unsupported secret exposure

Safety boundary

  • DeployWorks never displays raw secrets, tokens, or private keys.

Step 07

Offline update plan

Offline updates require signed media, a preflight result, a backup and rollback requirement, a safe install window, a cleared recovery lock, and a post-update verification — recorded as a plan, never executed.

Inputs

  • Signed offline package
  • Media hash
  • Install window
  • Preflight result
  • Backup requirement
  • Rollback requirement
  • Inspection-state restriction
  • Recovery-lock restriction

Proof generated

  • Offline update plan receipt
  • Media hash
  • Preflight result
  • Post-update verification requirement
  • Blocker list

Where it appears in the app

  • DeployWorks
  • EnterpriseGuard

AI Sense support

  • Explains missing offline-package proof
  • Flags an unsafe install window or stale backup
  • Flags a replay-backlog risk

Safety boundary

  • An offline update plan cannot run during unsafe inspection states, activate an unsigned artifact, or clear recovery.

Step 08

Backup / rollback readiness

Install or update requires a backup and a verified rollback path — audit receipts, evidence index, registry snapshot, config hashes, legal-hold and retention state — with private keys, secrets, and raw PLC excluded.

Inputs

  • Audit receipts
  • Evidence index
  • Station registry snapshot
  • Configuration hashes
  • Legal-hold state
  • Retention state
  • Signed-pack receipts
  • Deployment receipts

Proof generated

  • Backup / rollback readiness receipt
  • Backup manifest hash
  • Restore-drill state
  • Rollback package reference
  • Omissions list

Where it appears in the app

  • DeployWorks
  • EnterpriseGuard
  • Trust

AI Sense support

  • Flags a stale backup
  • Flags a missing restore drill
  • Flags a rollback gap or legal-hold conflict

Safety boundary

  • Rollback readiness does not execute a rollback, delete receipts, or clear recovery.

Step 09

Customer install packet

Customer IT/OT teams receive a redacted, reviewable install packet — deployment mode, manifest, integrity, hardware, firewall matrix, certificates, offline plan, backup/rollback, limitations, and an omissions list.

Inputs

  • Deployment mode
  • Package manifest
  • Integrity verification
  • Hardware checklist
  • Network / firewall matrix
  • Certificates checklist
  • Offline update plan
  • Backup / rollback readiness
  • Commissioning checklist
  • Known limitations

Proof generated

  • Customer install packet receipt
  • Redacted sections
  • Known limitations
  • Omissions list
  • Packet hash

Where it appears in the app

  • DeployWorks
  • CustomerTrust
  • EnterpriseGuard
  • Trust

AI Sense support

  • Finds missing install proof
  • Finds an unsupported claim
  • Prepares incomplete customer IT/OT requirements

Safety boundary

  • A customer install packet is review evidence. It is not certification, station approval, or remote control.

AI Sense explains deployment blockers, never installs

AI Sense

One reading layer across every DeployWorks step

Observes evidence, finds missing proof, explains uncertainty, ranks human checks, and prepares handoffs — it never commands hardware.

Reads

  • Evidence bundles
  • Review events
  • QA decisions
  • Vision Twin drift
  • Commissioning blockers
  • Governance decisions
  • Station registry
  • Ops metrics

Produces

  • Findings
  • Evidence-gap warnings
  • Work-package hints
  • Commissioning questions
  • Support summaries

Never

  • No PLC writes
  • No force PASS
  • No recovery clear
  • No robot commands
  • No camera/light commands
  • No production approval
  • No evidence mutation
  • No QA decision mutation

AI Sense observes evidence and guides humans — it records nothing and changes nothing. It does not command a station, write a PLC, clear recovery, reset safety, force a pass, approve production, sign off, or mutate any review, QA decision, commissioning, governance, evidence, or runtime state. Every recommendation is a suggestion for a human to carry out; the PLC and safety circuit remain authoritative.

Customer install packet

Install readiness by reference, never station control

The redacted install packet carries the deployment mode, package manifest, integrity verification, hardware and network checklists, certificate status, the offline update plan, backup / rollback readiness, known limitations, and an explicit omissions list — so a customer IT/OT team can review install readiness without any station ever handing over raw internals or being commanded.

deployment_mode
chosen on-prem / offline / plant-LAN / hybrid pattern by reference
package_manifest
component list, artifact hashes, and forbidden-capability list
integrity_verification
hash-match, signature-valid, and test-key-blocked results
hardware_checklist
per-item readiness status with evidence references
network_firewall_matrix
per-flow data class with the command path marked blocked
certificate_checklist
certificate and rotation status — never a raw secret value
offline_update_plan
signed-media, preflight, backup, and rollback requirements
backup_rollback_readiness
backup manifest hash and verified rollback path reference
known_limitations
what the deployment view cannot know or control
omissions
explicit list of what was withheld
packet_hash
integrity fingerprint of the redacted install packet

The packet never contains raw images or evidence frames, raw PLC coils or registers, private keys or signing secrets, authority tokens, camera, lighting, or robot command payloads, operator personal identity or local file paths.

Signed-in teams run this operationally in the HoldField app, under DeployWorks — where the deployment mode, package manifest, integrity verification, hardware checklist, network / firewall matrix, certificate status, offline update plan, backup / rollback readiness, and the redacted customer install packet are recorded as administrative proof, and where every station stays the local authority: nothing here installs, applies, activates, or commands a station. Open the workspace →