Appearance
Choose Process placement #
Every Process declares one execution target: Cloud, Edge, or Mixed. Choose it from authority, latency, connectivity, and safety requirements. Do not choose Edge merely to move ordinary application logic closer to a device.
Compare the targets #
| Target | Use when | Important boundary |
|---|---|---|
| Cloud | The workflow depends on Product Records, integrations, central coordination, or cloud-owned authority | Progress depends on connectivity to the cloud |
| Edge | One bound device must continue a bounded local workflow using typed local capabilities, waits, events, and deterministic flow | It cannot use cloud-only record, integration, reservation, setting, or alert steps |
| Mixed | Cloud orchestration needs one or more deliberate, bounded Edge phases | Edge work must be inside explicit Edge segments |
Cloud is the default. Keep a Process there unless a real connected-product requirement justifies local execution.
Use the Edge vocabulary #
Edge Processes support a deliberately small, versioned vocabulary:
- set a bounded execution-local variable
- branch or jump explicitly
- wait for a duration or declared time
- invoke and wait for a typed local Command capability
- wait for or emit a Product event
- complete, fail, or enter reconciliation
Edge does not run arbitrary shell, script, database, protocol, or transformation steps. Put Modbus, CAN, GPIO, machine drivers, specialised transforms, and other device behaviour in normal OEM software. Expose a stable typed capability and invoke it from the Process.
Bind Edge work to a real device role #
An Edge or Mixed Process requires an Edge target binding. The selected Device Class binding must provide the Product Runtime needed to receive the published Edge bundle and run its typed capabilities.
Validate placement before saving. The workspace reports available Edge targets and rejects an unknown or unsuitable binding.
Placement identifies where orchestration runs. It does not grant hardware access or turn a Device Class action into safe machine control.
Make Mixed boundaries explicit #
A Mixed Process remains cloud-orchestrated. Every local phase is an explicit Edge segment with:
- a stable segment identifier
- declared input and optional output
- bounded Edge steps
- an Edge target binding, inherited or selected for the segment
- an explicit next and failure path
- a timeout appropriate to the physical operation
Arbitrary per-node placement is not supported. A normal node outside an Edge segment is cloud work.
The published definition compiles each Edge segment into an immutable device-targeted body and replaces it in cloud orchestration with a durable dispatch. The execution debugger can enter the nested segment while preserving the exact Product Version and taken path.
Do not assume transparent failover #
Cloud, Edge, and Mixed are explicit execution contracts. Dataplicity does not move a Cloud step to Edge because connectivity failed, and it does not rerun an Edge segment in Cloud as a transparent fallback.
Design loss of connectivity as a product state:
- wait within a declared bound
- fail without unsafe side effects
- keep operating under bounded local authority
- enter reconciliation when cloud and physical truth can differ
If the device may restart, prove that local waits and state survive in the way your product requires. If it may remain offline, define how events, outcomes, and conflicts reconcile after reconnect.
Keep hardware safety below the Process #
An Edge Process coordinates intent. Device software and the physical control system must still:
- validate every input against current machine state
- enforce permissions, limits, and interlocks locally
- make duplicate delivery safe
- refuse stale or incompatible capabilities
- reach a safe state after restart, timeout, or cancellation
- report the actual terminal outcome
Do not put emergency stops, hard real-time loops, protective relays, or the only copy of a safety invariant in Product Application orchestration.
Test placement-specific failures #
For Edge and Mixed Processes, test:
- device offline before dispatch
- disconnect during an Edge segment
- duplicate dispatch or Command delivery
- device restart while waiting
- Command rejection, timeout, and incompatible capability
- cloud recovery while local physical work is uncertain
- explicit reconciliation and operator handoff
Use sandbox Scenarios for deterministic Process evidence, then qualify the same boundaries on representative hardware.