Production behaviour and design boundaries #

Dataplicity sits alongside the Linux product you already own. For each production function, decide which component is authoritative and design failure handling around that boundary.

This page summarises the boundaries to design around. Detailed wire formats, agent endpoints, rate limits, and release-specific behaviour belong in the device data and control contract. Plan-specific availability belongs in Plans and availability.

The production responsibility split #

Responsibility	Dataplicity	Your product or business system
Device identity and remote operating connection	Yes	Integrate the agent into the product image
Fleet visibility, diagnostics, logs, monitors, jobs, and remote support	Yes	Define the operational policy and response process
Customer-facing product UI	Yes, through Device Classes and Customer Portal	Define the product data, controls, terminology, and permissions
Product telemetry transport and operational history	Yes	Decide which records are business-critical and need stronger application-owned durability
Remote action delivery	Yes	Validate, execute, and independently report consequential physical outcomes
Desired settings	Yes	Apply settings safely on the device and report resulting state
Linux distribution and product application	No replacement required	You own the OS, application, dependencies, and lifecycle
Bootloader, secure boot, and device firmware safety	No	You own the firmware/update architecture and recovery strategy
Physical safety and control interlocks	No	Keep final authority on the device or dedicated safety system
Financial, legal, billing, CRM, ERP, and contract records	No	Keep the authoritative record in the appropriate business system

Dataplicity can operate the connected product without becoming the device firmware, safety controller, ERP, or transaction ledger.

Telemetry: operational data versus authoritative transactions #

Dataplicity telemetry is a strong fit for current product state, monitoring, diagnostics, alerts, customer-visible measurements, and operational history.

Treat a financially, legally, or operationally critical transaction differently. If losing, duplicating, or reordering a record would create an incorrect business outcome, give the event a stable domain identifier and retain it in an application-owned durable journal until the authoritative backend has reconciled it.

For example:

a temperature sample can normally tolerate a bounded gap;
a tank-level trend can normally tolerate delayed delivery;
a fuel transaction, credit consumption, or one-time entitlement should have application-level idempotency and reconciliation.

The detailed telemetry semantics and current local buffering behaviour are documented in What are the guarantees and limits of telemetry delivery? and the device data and control contract.

Commands: choose the right control path #

Dataplicity has two different control paths and they should not be treated as the same contract.

A generic Device Class action is a lightweight request from UI to device. It is suitable for bounded controls such as rebooting a unit, refreshing content, or running diagnostics. A queued or accepted generic action is not proof that the device executed it, and the generic action inbox is not a durable business queue.

A Product Application command is the durable workflow path. It has a stable invocation identity and lifecycle covering delivery, acknowledgement, execution, result, deadline/expiry, cancellation, and controlled redelivery. It accepts an idempotency key so a repeated cloud-side request can resolve to the existing invocation rather than create another. Product Application operations also support idempotent invocation when a key is supplied.

Neither mechanism makes a physical effect exactly-once. The device or authoritative backend still owns local validation, interlocks, deduplication where repetition would matter, and reconciliation of the final business or physical state.

For consequential workflows, separate three concerns:

Request: Dataplicity accepts and delivers an authorised invocation.
Execution: the device application decides whether the operation is valid and performs it.
Verification: the resulting state is reported so the operator or process can tell what actually happened.

This matters most for actions such as unlocking equipment, dispensing product, changing safety-relevant state, or consuming credit.

See What are the guarantees and limits of remote command execution? and the device data and control contract.

Settings: desired state and reported state #

A setting represents what the product should be doing. The device still owns whether and how that value can be applied.

A production implementation should therefore distinguish:

desired value;
last value the device reports as applied;
validation or rejection on the device;
the time each state changed.

With a qualified field agent release that supports the current settings consumer, desired settings persist locally and can converge after reconnect or restart. This does not change the device's responsibility to validate, apply, and report the resulting state.

Offline behaviour is part of the product design #

Connectivity loss should not turn into an undefined state.

For each product function, decide what continues locally when Dataplicity is unreachable:

product control and safety logic;
data collection;
critical event journalling;
cached customer or entitlement data;
operator-visible stale/offline state;
recovery and reconciliation after reconnect.

Dataplicity handles the remote connection, buffering, retry, and reconnect behaviour defined by the qualified agent release. Your application should retain any state whose loss would be commercially or physically unacceptable.

See What happens when a device is offline? and Offline datasets.

Updates: keep the authority you already have #

Dataplicity does not require you to replace a working Linux, container, or firmware-update architecture.

You can continue to use systemd, Docker or Podman, RAUC, Mender, SWUpdate, vendor bootloaders, or your own application updater where those are already the correct tools. Dataplicity can orchestrate and verify fleet changes around those mechanisms without claiming ownership of a rollback or boot path it does not control.

See Software and firmware boundaries.

Customer Portal boundaries #

The Customer Portal is the downstream application for people who operate your product. It can expose assigned devices, sites, product data, history, video, permitted actions, settings, diagnostics, and product-specific workflows.

It is not intended to become the authoritative storefront, billing system, CRM, ERP, warranty ledger, or contract-management system. Integrate those systems where they own the business record.

Current plan quantities and optional capabilities change more often than these architectural boundaries, so they are documented separately under Plans and availability.

Qualify the product you actually ship #

Before a production rollout, test the complete product on representative hardware and networks rather than relying on a feature checklist alone.

At minimum, exercise:

clean install and upgrade of the Dataplicity agent;
device reboot and application restart;
loss and restoration of connectivity;
stale, delayed, duplicate, and out-of-order data where relevant;
full or unavailable local storage for product-owned critical state;
customer, site, and device permission boundaries;
repeated or ambiguous generic actions;
Product Application command redelivery, acknowledgement, expiry, cancellation, and terminal results where used;
settings the device cannot apply;
your chosen software/firmware rollback path;
independent verification after a fleet change.

A successful qualification shows that the product behaves predictably when networks, storage, processes, or devices fail.

Release-specific limits and compatibility #

Some details are necessarily release- or plan-specific: local endpoint versions, payload limits, buffering caps, stream retention, API rate limits, optional capabilities, and minimum agent versions.

Keep those details out of product architecture. Use the current device data and control contract, agent documentation, and Plans and availability when qualifying a release.