← Blog
TestLauncher

Physical AI and IoT: Decide What Runs at the Edge

  • Physical AI
  • IoT
  • Engineering
Illustrative deployment boundaries: device sensing and local behaviour, site review and coordination, and remote analysis and updates. Data exchange must be explicitly scoped.

Decide where each function runs by the behaviour it must preserve when connectivity, data quality or equipment fails. For physical AI and IoT, a useful deployment plan separates device behaviour, site coordination and remote services before choosing the platform or operating system.

For Canadian defence, public-sector and dual-use innovators, the hard question is what a system can be trusted to do in its intended environment. TestLauncher focuses on custom platforms, operating-system engineering and quality expertise for that problem. Canada is our first deployment market and current focus; we build for organizations across NATO member countries.

Separate observation, recommendation and control

A model that labels an image, a dashboard that suggests an intervention and software that commands equipment have different consequences when they are wrong. Document which role each component has, what it may change, and who can intervene.

For each output, specify its permitted use, the maximum acceptable age of its inputs, and the response to missing or uncertain information. A confidence score alone does not establish that an action is appropriate. Identify the operating conditions and independent controls needed before connecting model outputs to equipment.

NIST SP 800-82 Revision 3 discusses operational technology security alongside performance, reliability and safety requirements. Those concerns belong in the architecture discussion, not only in a later security review. Our scoping questions below are a proposed engineering approach, not a safety assessment or evidence of certification.

Place functions against explicit constraints

“Edge” can mean software on a device or on a nearby site computer. Name the actual boundary rather than treating the term as a deployment specification.

Device

Candidate responsibilities include sensing, local processing and defined loss-of-connection behaviour. Decision to resolve: what must continue without a network, and on which hardware?

Site platform

Candidate responsibilities include operator review, coordination and local records. Decision to resolve: who can authorize changes, and what happens if the site service stops?

Remote services

Candidate responsibilities include fleet analysis, model evaluation and managed distribution of updates. Decision to resolve: which functions can tolerate delay or disconnection?

These are candidate placements, not a reference design to deploy unchanged. Measure end-to-end delay on the intended hardware and workload. Include sensor acquisition, inference, message queues and operator interaction where relevant; a model’s isolated inference time does not describe the whole system.

If the constraint is coordination or data exchange, start with platform integration. If it concerns drivers, startup, scheduling or recovery, investigate the operating environment. Neither physical AI nor IoT automatically requires a new operating system.

Draw the data flows before making residency claims

For every exchange, record the source, recipient, purpose, payload, storage location, retention period and access permissions. Include raw sensor data, derived features, diagnostic logs, backups, support access and update services.

Local inference does not prove that all data stays local. Diagnostics, external APIs or remote support may create additional flows. Canadian ownership also does not establish a deployment’s data residency. Agree those boundaries for the engagement, including third-party processing and access; our Security & Trust page explains the distinction between current deployments and planned options.

Example scenario: intermittent connectivity in field inspection

This is a hypothetical scoping example, not a delivered customer project or a released TestLauncher product.

Imagine a mobile inspection device that flags possible equipment defects for an operator. A site platform collects reviewed observations; a remote service supports later model evaluation. The inspection team needs useful local behaviour when connectivity drops, without silently treating an unreviewed prediction as an approved finding.

A bounded prototype could test stale sensor inputs, loss of the site connection, a full local queue and a model-version mismatch. For each condition, define what the operator sees, what is retained, and what must wait for review. Agree acceptance criteria with the people responsible for the equipment and its operating environment before testing.

The team might discover that the main gap is an explicit review workflow and reliable synchronization, rather than a new model or OS. That is a useful finding before committing to a larger build. The same decision process can inform physical AI and IoT and embedded-system engagements, with different criteria for each environment.

Define evidence and ownership before a pilot

A proposed discovery engagement could produce:

  1. A responsibility map separating sensing, inference, recommendations, control and operator authority.
  2. A deployment and data-flow diagram, with unresolved access, residency and third-party dependencies identified.
  3. A prototype test plan covering timing, degraded operation, version compatibility and recovery, with named owners and acceptance criteria.
  4. A decision record explaining what to reuse, configure or build, and what evidence is still missing.

NIST’s AI Risk Management Framework organizes risk work around Govern, Map, Measure and Manage, including evaluation before deployment and during operation. A pilot should therefore have a review plan for changes to models, data, hardware and operating conditions. A successful demonstration is not a substitute for that continuing evidence.

Scope the work around the actual constraint

TestLauncher’s custom platform and operating-system engineering engagements are available today. Our Canadian operating-system product and sovereign-email initiative remain in research and development; neither is released. bugAgent is the available quality platform; its conversational capabilities are in active development, not yet released. This guide does not describe an available robotics or physical-AI product from TestLauncher.

Bring your target environment, current architecture, difficult failure condition and deployment requirements. Book a discovery call to define a focused investigation and proposed deliverables.