01Physical task, models, sensing, frames, and time
Provide an accepted task, robot and end effector, payloads, workspace and obstacles, people or peer machines, sensors and actuators, environmental variation, multiple coordinate frames, unsynchronized clocks, calibration records, latency, missing and stale measurements, and a changed physical configuration. Ask what the software is allowed to believe.
Confirm: The person starts from the operating envelope and hazard owners; inventories exact mechanisms, limits, sensors, actuators, controllers, compute and revisions; distinguishes model geometry and semantics from measured reality; uses named units and coordinate conventions; owns the frame tree and transform direction; records timestamp source, clock domain, synchronization, age and latency; treats calibration as versioned target evidence; validates ranges and quality; models occlusion, noise, drift, bias and uncertainty; rejects unavailable or stale transforms and measurements; detects configuration mismatch; keeps raw observations where diagnosis needs them; and never presents estimated or simulated state as direct physical fact.
02Estimation, planning, actions, control, and execution
Provide noisy partial observations, a changing scene, kinematic and dynamic limits, competing goals, a long-running motion, cancellation and preemption, a planning timeout, controller saturation, contact or proximity evidence, deadline pressure and an interrupted communication path. Ask how intent becomes bounded motion and how motion stops.
Confirm: The person makes estimator assumptions, covariance or other uncertainty and observability limits explicit; separates robot state, world state and goal state; maintains scene freshness; constrains planning by accepted limits and operating modes; checks collision and feasibility without claiming that a model proves the world; assigns unique goals, feedback, terminal states and idempotent higher-level intent; implements cancellation and preemption through every layer; separates planning rate, supervisory rate and low-level control rate; distinguishes command from measured state; handles saturation, watchdogs, timeouts and partial execution; measures latency and jitter on the target; and transitions through the approved machine and safety architecture when evidence is missing or execution cannot continue.
03Middleware, concurrency, lifecycle, hardware, and security
Provide a distributed ROS 2 graph with sensor streams, state, services and actions; lossy and delayed traffic; incompatible quality-of-service profiles; node restart; blocked callbacks; shared non-thread-safe state; hardware command and state interfaces; permission boundaries; changed middleware or package versions; and a supervisor. Ask what must remain true through startup, execution and failure.
Confirm: The person gives each node a coherent responsibility and defines typed interfaces, ownership, rate, size, queue, history, reliability, durability, deadline, lifespan and liveliness from measured need; detects incompatible quality-of-service settings rather than assuming delivery; chooses topics, services and actions by semantics; designs callback groups and executors around concurrency and deadline evidence while avoiding blocking and deadlock; uses managed lifecycle transitions only where a supervisor owns them; separates hardware state and command interfaces and checks resource claims; validates startup ordering, reconnection, restart and cleanup; pins middleware and package versions; inventories package quality claims rather than inheriting them; scopes identities, enclaves, certificates and permissions; protects keys; and treats network security and lifecycle state as necessary controls, not permission to move hardware.
04Simulation, target validation, release, incident, and recovery
Provide a simulator, bench or hardware-in-the-loop setup, a bounded target machine, representative scenes and payloads, seeded variation, known model gaps, a repeatable test method, performance budgets, an exact release candidate, a fault during execution, synchronized traces, a receiving owner and an approved recovery path. Ask which conclusion each environment can support.
Confirm: The person records simulator engine, world, robot model, plugin, bridge, physics, sensor, noise, timing and seed assumptions; identifies every gap to the target; uses simulation for breadth and fault exploration without converting it into physical proof; defines repeatable target tasks, apparatus, scoring and acceptance with domain and safety owners; layers unit, model, interface, replay, simulation, bench, hardware-in-the-loop and bounded target checks; measures callback, transport, estimate, planning, control and end-to-end timing; preserves exact source, dependencies, models, configuration, calibration, toolchain, container or image, firmware and machine identity; stages deployment only through approved access; captures synchronized logs traces bags video operator notes and physical observations; diagnoses the failed boundary; demonstrates rollback or forward correction and return to an accepted state; and lets another owner reproduce the evidence and recovery.
