Requirements management for robotics and Physical AI connects a task to a measurable system obligation, its operating conditions, the interface where it is observed and the evidence needed for acceptance. The useful handoff is a requirement record with accountable owners, a verification approach, the assessed configuration and explicit open assumptions. A model benchmark contributes to that record when its claim and limits are clear.
From “the model is fast” to a requirement the test team can use
Picture a perception engineer handing over a new model and saying it detects obstacles quickly. The systems engineer needs to know what “quickly” means for the system. The controller engineer needs to know when a detection has actually arrived. The verification engineer needs two observable events and a defensible way to measure the time between them.
Those questions belong in the same handoff. Otherwise, each person can produce a reasonable answer to a different question. A timing benchmark might measure model execution, while the system obligation concerns the interval from a sensor frame arriving to a detection being delivered at an interface.
NASA's requirement-writing guidance supports clear product obligations, quantitative criteria, rationale and recorded unresolved assumptions. Applied here, that means agreeing the claim before choosing how to prove it. The twelve-field record below is an editorial teaching format for that conversation.
A warehouse replay example with a defined timing boundary
WR-01 is a fictional supervised indoor warehouse replay bench. All identifiers and evidence states in this example are teaching labels. The 80 ms target is invented for the bench, with no customer rationale, stopping-distance meaning, physical operating release or safety acceptance. No actual execution, measurement or reviewer decision is supplied.
The accepted historical teaching configuration is CFG-A = H1/L1/F1.4/M1/CAL-07/MAP-03. Candidate CFG-B = H1/L1/F1.4/M2/CAL-07/MAP-03. Only M1 → M2 is declared to change.
| Manifest element | Historical teaching CFG-A | Candidate teaching CFG-B |
|---|---|---|
| Hardware | H1 | H1 |
| Lidar | L1 | L1 |
| Firmware | F1.4 | F1.4 |
| Perception model | M1 | M2 |
| Calibration | CAL-07 | CAL-07 |
| Map | MAP-03 | MAP-03 |
Unchanged labels alone do not prove artifact identity, dependency independence or evidence applicability. A real handoff would identify the underlying artifacts and the references or digests used to distinguish them.
Start with the weak statement:
The robot shall detect obstacles quickly.
It leaves the condition, interval and delivery boundary open. In WR-01, SYS-PER-01 v1 instead states:
For DSET-07 v1 under LOAD-02, elapsed time from replayed sensor-frame arrival to detection delivery at IF-DET-01 v1 shall not exceed 80 ms.
That sentence gives the team a common target: a specified dataset and load, two events, an interface and a limit. TEST-LAT-01 v1 is the named teaching procedure for assessing it. The sentence still needs a measurement specification beside it. Where is arrival observed? What counts as delivery? How are the events paired? Which clock basis makes their difference meaningful? The annotated record exposes those questions rather than letting the number conceal them.
The twelve-field requirement handoff
Copy the fields into the controlled record used by the team. Keep the obligation concise, then use the other fields to preserve what interface and verification owners need. Each open action below belongs to a role only. Actual assignments, dates and approvals remain unknown.
| Field | WR-01 entry | Question or action for the responsible role |
|---|---|---|
| Source and rationale | Fictional NEED-01 concerns timely perception data for the supervised warehouse replay exercise. SYS-PER-01 v1 addresses that bench need. | Systems owner supplies the real source and explains why the interval and target are justified. The invented 80 ms limit provides no customer authority. |
| System and operating boundary | WR-01 assesses perception timing on a supervised indoor warehouse replay bench. | Systems owner defines the product boundary. Live navigation, controller response, braking and operation around people need separate claims and evidence. |
| Conditions | DSET-07 v1 under LOAD-02. | Dataset and fixture owners identify content, version, replay conditions, load definition and limits. Their actual details are unknown. |
| Measured variable | Elapsed time between paired sensor-frame arrival and detection delivery events. | Verification owner defines event association and which observations the criterion covers, including missing, repeated, invalid and out-of-order detections. |
| Units | Milliseconds for the interval. Any assessed positions at IF-DET-01 need an agreed length unit. | Interface and verification owners document capture/report units and conversions. Spatial-output units are unknown, rather than inferred from field names. |
| Reference frame | The interval needs a time basis. Related spatial outputs need a frame, axes and transforms where relevant. | Clock and spatial-frame facts are unknown. Endpoint owners justify any N/A for the scalar claim and check whether frame handling affects event association. |
| Start and end events | Start: replayed sensor-frame arrival. End: detection delivery at IF-DET-01 v1. | Perception and controller endpoint owners agree observation locations and meanings. Queue entry, processing start and controller consumption may describe different events. |
| Criterion | SYS-PER-01 v1's defined interval shall not exceed the invented 80 ms bench target. | Verification owner preserves the criterion and establishes a valid comparison. A real target needs an authorised rationale. |
| Owners | Systems/requirement owner, perception endpoint owner, controller endpoint owner, verification owner and baseline authority are roles to assign. | Identify accountability and the decisions each role may make. No real reviewer, review date or completed approval is supplied. |
| Verification approach | Test using TEST-LAT-01 v1 for DSET-07 v1, LOAD-02 and the stated timing boundary. | Verification owner defines capture, clock basis/resolution, pairing, sample handling, load checks and anomaly rules. A common clock is an option to assess, not a supplied fact. |
| Assessed configuration | Teaching historical CFG-A: H1/L1/F1.4/M1/CAL-07/MAP-03. Planned candidate CFG-B: H1/L1/F1.4/M2/CAL-07/MAP-03. | Configuration owner records what the rig actually assessed and links the programme baseline separately. Actual model, runtime, firmware and fixture identities/digests remain unknown. |
| Open assumption or action | Actual clock/load/event/frame/digest, execution/report and reviewer facts are unresolved. | Record the role responsible for each gap, evidence needed and next decision. Add an agreed due date when one exists. No date is invented here. |
The table is useful because the same uncertainty has a place to live and a person to resolve it. If LOAD-02 is only a label, the fixture owner must define it before a real result can support the stated condition. If the arrival timestamp is captured at a different event from the requirement's start, the endpoint and verification owners must reconcile that difference.
Agree the interface meanings on both sides — IF-DET-01 v1 identifies the delivery boundary, but its name does not define its behaviour. The producer and consumer need agreement on timestamp meaning, detection association, missing or invalid data and any relevant spatial conventions. NASA's interface-management guidance connects defined interface characteristics and compatibility with verification planning.
Units deserve the same care. ROS REP 103 explains the integration problems caused by inconsistent conventions and allows justified, documented exceptions. It lists seconds as the base time unit. WR-01 explicitly uses milliseconds for this interval, so a ROS-facing implementation would need an agreed representation and conversion. The exercise does not assume ROS adoption or a particular spatial frame.
Keep the trace short enough to explain — For this handoff, NEED-01 motivates SYS-PER-01 v1. The requirement uses IF-DET-01 v1 as its observation boundary and is assessed by TEST-LAT-01 v1. The procedure's record identifies the configuration and conditions assessed. The evidence then records the outcome and the claim a reviewer considers supportable.
NASA's requirements-management guidance supports maintained traceability between expectations, requirements, design information and test plans or procedures. The traceability matrix guide explains the general relationship types. Here, the practical check is whether an owner can follow this one bench claim without guessing what a link means.
EVID-LAT-A is an assumed fictional historical pass for CFG-A, without a measured value or execution date. EVID-LAT-B is Pending for CFG-B, with no candidate run or result supplied. CR-014 and RUN-042 are teaching change and run labels only, rather than real provenance or Arc identifiers.
Turn the handoff into an acceptance question
Work through the record in the order that resolves the claim. The systems owner confirms the need and scope. The endpoint owners agree the events at IF-DET-01. The verification owner establishes that TEST-LAT-01 can observe those events under the specified conditions and records the configuration actually assessed. The authorised reviewer then judges what the evidence supports.
That sequence makes a gap actionable. An unknown clock basis asks for measurement evidence. An undefined load asks for fixture definition. A mismatch between planned CFG-B and the artifacts on the rig asks for configuration reconciliation. None becomes a valid measurement because a CI job finished.
A replay timing claim also has a defined reach. Detection correctness, environmental coverage, control response and hazard controls need their own requirements and evidence. NIST's voluntary AI RMF MEASURE guidance calls for documented test sets, metrics and tools, attention to deployment-like conditions and recorded limits on generalisation. That helps frame the next evidence question without expanding this bench result into a physical operating claim.
When CR-014 proposes M2, SYS-PER-01 may remain at v1 while its evidence needs reassessment. Use the model-change dossier for the wider dependency sweep and the configuration-specific evidence ledger for the applicability decision.
Two questions that sharpen the handoff
Can the wording be reviewed before the clock basis is settled?
Yes, as a draft obligation with an owned measurement gap. Reviewers can agree that the sentence captures the intended interval while leaving evidence closure open. A real latency decision still needs the start and end timestamps, their resolution and any relevant clock relationship to support the comparison.
Why keep a reference-frame field for a scalar interval?
It separates time basis from spatial-output semantics. The interval is scalar, but the observations used to pair detections may involve frame handling. A justified N/A can be appropriate for a narrowly defined scalar claim. If positions are assessed, their frame, axes and transforms need an explicit definition.
Try the handoff on one real obligation
Bring one requirement to its systems, interface and verification owners. Complete the twelve fields together and leave missing facts as named actions. Ask the authorised reviewer to state the precise claim the available evidence can support. That exercise gives a requirements-workflow evaluation a concrete purpose, including an Arc evaluation, without assuming any particular product representation or automation.