The factory floor is not a staging environment

{
  "testBoundary": "isolated simulation",
  "dataSource": "synthetic fixtures",
  "liveSystemAccess": false,
  "equipmentCommands": false
}

# The factory floor is not a staging environment

Set clear test boundaries, simulate failures, and review industrial software changes before live use.

FIELDNOTES sample · 2026-09-07 · Industrial software · 3 min read

Source: https://awake-iris-z6ww.here.now/notes/the-factory-floor-is-not-a-staging-environment/

> Sample note: demonstration content, not a published article by the site owner.

## Define the test boundary

An industrial application can influence operations without sending a machine command. A stale production count, a delayed notification, or a misleading status display can change a human decision. Start a test plan by naming the decisions the software supports, the systems it touches, and the consequences of incorrect information.

Separate unit tests, interface tests, controlled simulation, and any approved live validation. Each provides different evidence. Passing a parser test says nothing about network isolation; passing a simulated workflow says nothing about the safety of a physical process. Record what each environment can demonstrate and what remains unverified.

Keep development credentials and network paths separate from operational systems. Verify the separation rather than trusting an environment name. A read-only integration still creates load and exposes information, so its access and traffic need review too.

## Simulate the uncomfortable cases

Build fixtures from synthetic or appropriately approved, sanitized data. Exercise missing fields, duplicated messages, out-of-order events, interrupted connections, and stale timestamps. Include recovery: a consumer that survives disconnection but processes a backlog incorrectly is not ready for release.

Write expected outcomes before running the tests. For a stale measurement, the expected result might be an explicit unavailable state rather than a plausible-looking number. Check that logs explain the condition without exposing credentials or sensitive operational details. Use a planning record like this to make the boundary visible; these labels do not enforce isolation.

```json
{
  "testBoundary": "isolated simulation",
  "dataSource": "synthetic fixtures",
  "liveSystemAccess": false,
  "equipmentCommands": false
}
```

## Make review a release input

Treat the change description as part of the release, not paperwork added afterward. Explain the affected interfaces, changed assumptions, validation evidence, unresolved risks, and recovery approach. Include the people responsible for operations, software ownership, and applicable safety review before deciding whether live validation is appropriate.

A software approval is not a substitute for site safety procedures or qualified engineering assessment. Changes involving control behavior, interlocks, or protective functions belong within the established safety and change-management process. Keep ordinary application testing outside that boundary.

Agree on a validation window, an accountable observer, and stop conditions. A deployment should not depend on someone noticing trouble by chance. The release decision should acknowledge simulation limits rather than presenting simulated success as proof of safe physical behavior.

## Verify recovery, not just startup

Define reliability in terms users can recognize: information freshness, delivery completeness, visible failure states, and time to restore service. A running process is only one signal. Compare expected and observed records, and make gaps distinguishable from legitimate periods of inactivity.

Rehearse application recovery in the isolated environment, including configuration restoration and handling of partially processed data. Do not assume reverting application code reverses database changes or messages already delivered. Document where recovery requires reconciliation or an explicitly reviewed forward fix.

After an approved release, inspect the agreed signals and ask the responsible operators whether the information remains understandable. Close the change with evidence and remaining limitations. Production can confirm carefully scoped assumptions; it should not become the place where basic failure behavior is first discovered.

Tags: Testing, Change control, Reliability