When a Digital Twin Finds a Problem: An Offline Workflow for Human Action

A digital twin can monitor an asset, compare current behavior with expected behavior, and warn that something may be changing. That is valuable. It is not the end of the work.

Someone still has to go to the equipment, understand the situation, make safe observations, and decide what happens next. That person may be on a roof, in a mechanical room, on a factory floor, or in another place where a network connection is unreliable.

The next practical transformation use case is to connect digital-twin insight to a controlled human workflow that can continue offline.

I worked at GE Digital on teams focused primarily on healthcare and predictive analytics. My own area also included HVAC in facilities and manufacturing. That experience made the last mile of predictive work especially interesting: an alert matters only when it reaches the right person in a form that supports a safe and useful response.

Before I moved into software development, I also spent about six years as a hospital plant engineer at John Muir Medical Center in Walnut Creek, California. Engineers made rounds, took readings, recorded observations, and performed maintenance. The physical equipment, the operating record, and the judgment of the person standing in front of the machine all mattered.

This article presents a hypothetical architecture using digital twins, predictive analytics, and StepCard. It is based on established operating principles and current StepCard capabilities, but it does not describe a completed GE or customer implementation. GE does not sponsor or endorse StepCard, and no integration between the products is claimed.

The Gap Between an Alert and the Work

A digital twin is a software representation of an asset, system, or process. Live and historical data can help it detect abnormal behavior, predict possible problems, and test scenarios without disturbing the physical equipment.

Predictive analytics can therefore answer questions such as:

  • Is this unit behaving differently from its normal pattern?
  • Is the change important enough to investigate?
  • Which asset or subsystem should receive attention first?
  • What may happen if the condition continues?

The model usually cannot see everything a qualified person sees at the site. It may not know that a panel is damaged, a label is wrong, access is unsafe, a recent repair was not recorded, or the equipment does not match its digital record.

The human workflow closes that gap.

A Realistic HVAC Example

Consider a facility with several air-handling units. Sensors provide operating data to a digital twin or predictive-analytics service. The system identifies a pattern that differs from the unit’s established behavior.

This hypothetical example does not assume that the model has diagnosed the cause. It has identified a condition worth reviewing.

A controlled process could then:

  1. associate the alert with the correct asset and approved procedure;
  2. tell the responsible technician why the asset was flagged;
  3. provide a versioned StepCard workflow for qualified personnel;
  4. let the technician follow the workflow without a network connection;
  5. record observations, readings, decisions, and escalation locally; and
  6. export or synchronize the trace after connectivity returns.

The workflow would not authorize unsafe work. It would contain clear stop conditions and escalation paths. Site safety rules, equipment documentation, and the judgment of qualified personnel would remain authoritative.

The same pattern could apply to a pump, compressor, production line, or other monitored equipment. The details would change. The operating principle would not.

What StepCard Contributes

StepCard is an offline-first runtime for deterministic decision workflows carried in QR codes. A StepCard workflow can ask bounded questions, branch on answers, present actions, and retain a local session trace.

The same approved workflow and the same inputs produce the same result. That is useful when a team needs a procedure that is reviewable, versioned, and able to run without depending on a live AI service.

StepCard can currently:

  • build and edit structured workflows visually;
  • encode compact workflows in QR codes;
  • execute the core workflow offline;
  • collect manual answers and observations;
  • stop or escalate based on defined rules; and
  • retain and export a structured session trace.

StepCard is not the digital twin. It is a possible human-action layer between a machine-generated condition and the person who must investigate it.

What Would Still Need to Be Built

The automatic connection from a twin alert to a StepCard workflow is a proposed extension, not a completed product integration.

A production design would need a governed service that maps:

  • the asset identity;
  • the alert type and severity;
  • the equipment model and configuration;
  • the approved procedure and version;
  • the worker’s role and authorization; and
  • the site’s safety and escalation rules.

The service should select only an approved workflow. It should not let a generative model create unreviewed maintenance instructions at the moment of an alert.

Signed workflow packages, expiration rules, asset validation, change approval, and a safe fallback would also be important. A stale procedure delivered reliably is still a bad procedure.

A Proposed Operating Architecture

The accompanying diagram separates current capabilities from the proposed integration.

Sensors and operating systems provide data to the digital twin or predictive model. When the model identifies a condition, a governed mapping layer checks the asset, alert class, procedure version, and authorization. It then provides the approved StepCard workflow to the technician.

The technician can continue through the bounded workflow offline. The local trace can later return observations and outcomes to the maintenance record and, where appropriate, the analytical system.

Human review remains present at both ends. People approve the workflow before use and assess the evidence after the work.

Start With Workflow Selection, Not Workflow Generation

There are two ways to interpret a “dynamic” workflow.

The safer first phase is dynamic selection. The system chooses an existing, approved workflow based on a controlled alert taxonomy and verified asset record.

Dynamic generation is a later and more difficult problem. Even when software can assemble a technically plausible procedure, the result would require validation, approval, version control, and testing before operational use.

For a first pilot, the twin should never improvise instructions.

Pilot One Asset Class

A useful pilot could involve one facility, one type of HVAC asset, and a small set of well-understood alert classes.

The pilot could begin in shadow mode. The predictive system would flag a condition and select a workflow, but the existing maintenance process would remain in control. The team would compare the proposed routing and collected evidence with what qualified personnel actually needed.

Only after the mapping and procedures prove reliable should the workflow become part of normal operations.

Proposed measures could include:

  • time from a trusted alert to acknowledgment;
  • percentage of alerts routed to the correct approved workflow;
  • percentage of sessions completed or safely escalated;
  • completeness of field observations;
  • number of asset or procedure mismatches;
  • false or low-value alerts;
  • time spent reconnecting field evidence with the maintenance record; and
  • technician reports of unclear or unnecessary steps.

These are proposed measures, not reported results.

Risks That Must Be Designed In

The main risks are not limited to model accuracy.

They include:

  • a sensor problem mistaken for an equipment problem;
  • an incorrect asset-to-workflow mapping;
  • a workflow that is valid for the model but not the installed configuration;
  • an expired or altered QR workflow;
  • unsafe instructions or missing stop conditions;
  • exposure of facility or maintenance data;
  • conflicts when local records synchronize;
  • weak identity or authorization controls; and
  • automation that discourages a technician from reporting an exception.

The design should make uncertainty visible. It should always give qualified personnel a way to stop, explain an exception, and escalate.

Key Questions and Example Answers

These questions provide a practical starting point. They are based on sound transformation discipline without disclosing any proprietary customer or course methodology.

What business outcome are we trying to improve?

Example answer: Reduce the time between a trusted equipment alert and a safe, documented field response.

What does the digital twin know, and what does it not know?

Example answer: It knows the sensor history, asset model, and detected pattern. It may not know the physical condition at the site, recent undocumented changes, access hazards, or whether the asset record is correct.

What is the smallest useful pilot?

Example answer: One facility, one HVAC asset class, two or three approved alert types, and existing procedures converted into reviewed StepCard workflows.

Should the system select or generate the workflow?

Example answer: Start by selecting a versioned, approved workflow. Do not generate live maintenance instructions during the pilot.

What must work without a network?

Example answer: Asset confirmation, the bounded procedure, manual data entry, stop and escalation instructions, and the local session trace.

Which decisions must remain human?

Example answer: Safety assessment, authorization to perform work, diagnosis, exceptions, repair decisions, and approval of any new or changed procedure.

What information should return after the work?

Example answer: The verified asset, workflow version, observations, readings, completion or escalation status, timestamps, and any documented exception. Access should be limited to information the organization has a legitimate reason to retain.

How will we know whether the pilot is useful?

Example answer: The correct people receive the correct approved workflow, field evidence is more complete, exceptions remain visible, and the process does not add unsafe delay or unnecessary work.

Who owns the system?

Example answer: Operations, maintenance, engineering, safety, and security share ownership. The analytical model and workflow software support their decisions; they do not replace accountability.

The Practical Transformation Opportunity

Digital twins have become good at representing conditions that people cannot watch continuously. Offline workflows can make those conditions useful where the physical work occurs.

The valuable connection is not a machine issuing orders to a person. It is a governed exchange:

The machine identifies a condition. The system provides approved context. A qualified person observes reality, acts within safe boundaries, and returns better evidence.

That is a realistic way for machines and people to communicate even when the network does not follow the worker into the field.


Sources and Disclosure

The operating example and integration architecture in this article are hypothetical. They do not describe a completed GE, StepCard, or customer deployment. Product names belong to their respective owners.

Leave a Comment