A robot task is not a prompt. It is a verifiable workflow.

A prompt such as 'inspect the west utility corridor and bring back anything unusual' leaves too much unresolved. Which corridor boundary is authoritative? Which sensors are required? May the robot open a door, enter an occupied zone, or ask another platform for help? What counts as complete? What evidence must return before the task can close? A demonstration can improvise these details. A production workflow cannot.

The NodeRiQ task contract is a proposed programme pattern, not a published implementation schema. Publicly, it can be described as a bounded record containing the objective, operating zone, required capabilities, prohibited actions, dependencies, completion evidence, time and energy constraints, escalation owner, and safe end states. The record should survive every translation from business request to robot-specific command.

Hard-coding a mission to one robot creates a brittle system. The more durable request is capability-based: move a payload of a defined class, read a gauge within a specified view envelope, traverse a route class, manipulate an object with a required tool, or maintain a sensor watch for a defined period. Device identity matters later for calibration, certification scope, maintenance, and accountability; it should not be the first abstraction in task design.

Open-RMF demonstrates one practical mechanism for mobile fleets: capable fleet adapters respond to a task notice with proposals, and a dispatcher awards the work according to configured criteria such as finish time or cost. NodeRiQ's public programme can learn from that pattern without claiming to replace Open-RMF or expose a universal fleet API. The research question is how capability, uncertainty, shared context, and human priority should shape assignment across a wider set of autonomous devices.

A useful task graph makes hidden assumptions visible. A drone cannot begin an inspection until the airspace and weather gate is valid. A mobile robot cannot deliver a part until the receiving workcell is ready. A manipulator cannot close the handoff until payload identity and placement are verified. A downstream task should not advance because the previous command returned success; it should advance because the required physical evidence arrived.

Continuous progress understanding is one of the notable 2026 research signals. Gemini Robotics ER 2 reports progress classification and moment-finding work that helps identify when a step completes or fails. For an operating system, those model outputs should be treated as evidence with confidence and provenance, not as unquestionable state. Device events, external sensors, workcell state, and human confirmation can corroborate or challenge the model's interpretation.

NodeRiQ is the applied programme for shared situational context, distributed coordination, and evidence-aware recommendations. NowFlow is the surrounding human and enterprise workflow surface: intake, approval, exception routing, accountability, and durable review. NeuralOS is the relevant edge-runtime context for local inference and robotics integration. These relationships explain a possible productisation direction; they do not establish a released end-to-end NodeRiQ product or a fielded integration.

Hard-real-time actuation, collision avoidance, emergency stop, certified safety functions, and platform stabilization remain local and classical. The high-level planner can request a bounded action, but a device-local controller must reject anything outside its current safety envelope. This is consistent with the wider field: industrial standards distinguish the robot machine from the integrated application, while current robotics foundation-model releases describe interfaces to lower-level safety-critical controllers rather than replacing them.

A robotic workflow should be designed around expected exceptions: the route is occupied, a lift is unavailable, the object moved, the gauge is unreadable, the battery forecast changed, the payload identity conflicts, the receiving cell is not ready, the link degraded, or a person entered the operating zone. The system needs more than retry. It needs to decide whether to gather new evidence, reassign, wait, return to a safe point, request teleoperation, or escalate to a human.

Every exception should preserve the causal record: what was expected, what was observed, which policy or physical constraint blocked progress, which alternatives remained, who changed the plan, and whether the recovery returned the system to a known state. That record is the foundation for evaluation and for improving the task contract instead of simply tuning the model after every incident.

A NodeRiQ robotic-workflow PoC should begin with one non-production task that crosses at least two device or system boundaries. For example: an inspection robot captures a reading, a planner classifies the exception, a mobile robot carries a service kit, a human approves access to the final zone, and the work closes only when the instrument and payload states are reconciled.

The decisive tests are operational: can the same task be replayed; can a device be swapped through an adapter without changing the work-order meaning; does stale evidence block assignment; does human rejection propagate to every participant; does the task recover after a dropped link; and can the team explain why the final state is complete? Throughput matters later. First, the workflow must remain understandable under pressure.

NodeRiQ is publicly presented as an AI-first applied research and productisation programme. The workflow described here is a design and evaluation structure derived from current robotics systems, standards, and Neura Parse's published programme principles. It does not claim a released robot-control product, a completed customer deployment, a universal adapter catalogue, certified safety, or validated performance.

That boundary makes the proposal more useful. A prospective pilot can ask for a bounded workflow, name the devices and infrastructure already present, choose one exception that matters operationally, and agree on the evidence needed to expand. The outcome of the first engagement is a measured decision about the next operating envelope—not a promise of general autonomy.