Physical AI operating requirements should make the approved conditions of use explicit, connect those conditions to evidence and define what happens when a relevant condition becomes invalid or unknown. A statement such as “works in our warehouse” leaves too much unresolved. The team needs to know which tasks, objects, environmental conditions and human interactions the claim covers, and who can authorise a change.
This guide is for robotics systems leads, autonomy leads and verification managers preparing a deployment or expanding an existing use case. Its practical output is a condition-to-evidence matrix with a separate decision for recognising and responding to a boundary change. It helps reviewers answer a specific question: does this proposed operation remain within the conditions we have approved?
Define the operational decision before listing conditions
Begin with the operation being authorised. “Sort approved empty crates at station KESTREL-4” is a more useful scope than “warehouse automation”. Specify the task, equipment boundary, site and configuration, then identify the people who approve the boundary and maintain its assumptions. Commercial acceptance, product release and site authorisation may be separate decisions.
A condition matters when changing it could alter the task outcome, a risk control or the validity of evidence. Relevant conditions can include object geometry, surface properties, visibility, support surfaces, traffic, human access, communications and the behaviour of neighbouring equipment. The list must come from the application and its risk assessment. A universal catalogue cannot decide which conditions are consequential for your robot.
Keep three concepts distinct in the records: the intended operating conditions, the conditions actually exercised during evaluation and the conditions that the deployed arrangement can recognise or assure. They often overlap only partly. A laboratory test may cover a lighting condition that the site never measures. A site check may confirm a floor condition for which no representative test exists.
Make each consequential condition reviewable
Replace adjectives such as “normal”, “clean” and “adequate” with an agreed definition or a controlled reference. A condition can be quantitative, categorical or a defined procedural state. State how it is established, what makes it invalid and how uncertainty is treated. If a parameter is not directly measured, identify the inspection, approved asset list or other arrangement on which the operation depends.
Separate product behaviour from site and personnel obligations. A robot requirement might specify a response to an invalid condition signal. A site procedure might establish who checks the approved crate list before a production batch. Recording both is useful, but a site instruction should not masquerade as demonstrated robot capability. NASA’s requirements guidance supports clear references, verifiable statements and consideration of detection, reporting and recovery.
Also distinguish “outside the boundary” from “boundary status unavailable”. A failed measurement does not establish that the underlying condition is acceptable. Define the response to unavailable, stale or conflicting condition information with the same care as an explicit violation. Responsibility for recognising the condition may sit in a separate subsystem or operational process rather than the learned policy.
Use a condition-to-evidence coverage matrix
The worksheet below is a proposed engineering method. It does not reproduce a normative standard. Add one row per consequential condition or interaction, then connect each row to the requirements and evidence that support the decision. A link to a test report is useful only when its exercised conditions and limitations are visible.
| Worksheet element | Record | Review question |
|---|---|---|
| Condition and scope | Condition ID, approved value or category, task and configuration to which it applies | Can two reviewers identify the same boundary? |
| Recognition or assurance | Measurement, condition signal, inspection or site control, its owner and known limits | How is valid, invalid or unknown status established? |
| Response responsibility | Trigger, allocated requirement, responding subsystem, operational consequence and re-entry authority | Who acts when validity changes, and what permits resumption? |
| Coverage selection | Interior, edge, outside, unavailable-information and interaction cases with selection rationale | Which consequential combinations remain unexamined? |
| Evidence and applicability | Procedure and result references, exercised conditions, configuration and limits of use | Does the evidence address the claim being authorised? |
| Disposition and change trigger | Gap, owner, decision, restriction and conditions that reopen the decision | What may proceed, and what additional work is needed? |
Use states that distinguish planned work, executed evidence, reviewed applicability and authorised use. A team may have all its tests planned while several operational conditions remain unsupported. Equally, a completed test can support one condition without establishing a transition response. Coverage should be assessed against the decision, rather than inferred from the number of attached files.
Record the reason a case was selected. “Low illumination and dark crate together could affect recognition” is a better review trail than “edge case”. Where the test setting differs from deployment, capture the difference and the argument for using the result. NIST’s AI RMF Playbook MEASURE 2.3 calls for evaluation under conditions similar to deployment and documentation of differences between measurement and deployment settings.
Cover boundaries and transitions as well as steady operation
Testing comfortably inside a condition range addresses only part of the question. Select cases near consequential boundaries, outside the approved range and where the condition information is absent. Add combinations where conditions interact. The choice and quantity of cases need a justified engineering method appropriate to the consequences, available evidence and uncertainty.
Examine changes during an operation. A condition that is valid when a cycle begins may cease to be valid before it ends. Specify which part of the system recognises that transition, how the status reaches the responding function and what behaviour follows. A response might inhibit a new task, enter a defined recovery mode or invoke a separately engineered protective function. Its suitability needs application-specific review.
Do not equate a policy confidence score with a validated condition monitor. The score’s relationship to the consequential condition needs evidence. Similarly, a condition checker that works on recorded data has not thereby demonstrated the complete deployed response path. NIST MEASURE 2.6 supports examining behaviour beyond knowledge limits and documenting the conditions under which safe-failure behaviour was evaluated. It does not certify any particular robot or monitor.
Use the separate learned-policy acceptance guide to specify episode outcomes, populations and statistical interpretation. This worksheet addresses which operating conditions and transitions those evaluations need to cover.
Worked example: a proposed crate-sorting boundary expansion
The following example is entirely fictional and unexecuted. KESTREL-4 is a guarded crate-sorting station in proposed configuration K4-B7. Its team has defined boundary BND-27 for empty, opaque crates on an approved asset list. The proposal adds crates with reflective sleeves. These labels and decisions illustrate record structure, not tested performance, safe limits or customer results.
| Condition | Proposed recognition and response | Evidence work and review disposition |
|---|---|---|
| BND-C01: approved opaque crate family | Batch asset check establishes the family. Requirement BND-R12 allocates the response to an invalid batch-authorisation signal. | Plan K4-P31 would examine valid, invalid and unavailable authorisation signals. No result exists. Operational approval remains open. |
| BND-C02: reflective sleeves | Recognition by the vision system has not been established. The proposal cannot assume automatic detection of the new category. | Gap K4-G09 requests a reviewed recognition and assurance arrangement before adding the category to the boundary. |
| BND-C03: illumination within the project-defined range | A proposed condition sensor would publish validity status. Requirement BND-R18 would define behaviour when that status is unavailable. | Plan K4-P34 needs interior, boundary and unavailable-status cases. The proposed sensor and response path require verification. |
| BND-I04: reflective sleeve under reduced illumination | Interaction between object appearance and illumination may affect recognition and subsequent task behaviour. | Case selection rationale K4-A06 requests combined-condition evaluation. Separate tests would not answer this interaction question. |
| BND-T05: validity changes after task initiation | Controller responsibility and the permitted transition state need agreement with the station safety design. | Gap K4-G11 holds the transition claim pending requirements, evaluation and an authorised disposition. |
The review can now make a bounded decision. It could retain the existing proposed category while holding the expansion, request more evidence or revise the assurance arrangement. It cannot mark the reflective category covered merely because the old crate tests exist. In this fictional case, none of the plans has been executed and no operation is authorised by the example.
A useful closure record would connect K4-G09 to the agreed recognition arrangement, its requirements, relevant results and the reviewer’s decision for a named configuration. A different closure record would address K4-G11’s transition behaviour. Keeping those questions separate prevents a successful recognition test from silently closing an unresolved response question.
Review changed conditions without rewriting historical evidence
Reopen the relevant rows when an approved object, model, sensor, condition monitor, response implementation or site assumption changes. A physical relocation can change visibility or neighbouring operations even when the software remains identical. A wider task boundary can require fresh evidence even when the model has not changed.
Compare the proposed boundary with the previous one, identify affected requirements and determine which results remain applicable. Record retained evidence with its original scope and a new applicability decision. Where the argument depends on similarity, state that similarity and its limits. NIST MEASURE 1.2 explicitly connects changes in operational settings with reassessment of measurements and controls.
The robotics change-impact review provides the broader dependency review. The configuration evidence guide explains how to retain results against the tested product configuration. Here, the additional artifact is the changed condition and transition coverage decision.
Manage the boundary review in Arc
Arc’s public capability statements describe connected engineering records, bidirectional traceability, verification records, configuration applicability and controlled changes. A team can configure records for conditions and coverage decisions, then link them to requirements, systems, procedures, results and review context. The team defines those types and relationships.
Configuration-filtered views can help reviewers inspect the requirements and evidence for a proposed station configuration. Branches and reviewable differences can preserve the proposed boundary expansion and its decision history. Arc manages engineering context. Recognition logic, robot responses and evidence sufficiency remain work for the programme’s engineers and authorised reviewers.
Evaluate one boundary change before expanding the workflow
Bring one existing condition list, two representative evidence records and one proposed change to an Arc demo. Configure a small condition-to-evidence matrix, trace the change to its affected requirements and compare the current and proposed configuration views. Ask the reviewer to identify one supported condition, one unresolved combination and the authority needed to close it.
The exercise is successful when another engineer can reconstruct the scope and disposition from the connected records. Use synthetic or agreed evaluation data and define data handling before introducing programme information.
Sources and method
Arc prepared this educational guide and sells requirements management and systems engineering software.
Prepared on 26 October 2026 from selected public NIST and NASA guidance passages retrieved that day and Arc’s canonical capability-page source. The worksheets, record names and fictional example are editorial proposals. No robot test was executed and no application-specific safety assessment was performed. Arc’s individual capability statements retain their published review date of 4 September 2026. The guide does not establish a legal operating domain, certification status or universal safe boundary.
Frequently asked questions
What should physical AI operating requirements describe?
They should describe the approved task and conditions, the evidence that supports those conditions, how relevant boundary violations are recognised, the required response and who authorises continued operation. Conditions that cannot be monitored need an explicit assurance arrangement and an honest account of its limits.
Is an operating boundary the same as a test dataset?
No. A dataset samples some conditions under which the system was evaluated. The operating boundary describes the conditions for which use is authorised. The team must justify how the samples and other evidence support that boundary, including important combinations and transitions.
Does testing each condition separately establish coverage?
It establishes evidence for the tested cases. It does not automatically establish coverage of combinations, changing conditions or the response when a condition becomes unknown. Select additional cases through an engineering assessment of interactions and consequences.
Can the robot always detect that it has left its operating boundary?
Detection capability is itself a requirement to specify and verify. Some conditions are measured directly, others depend on site controls or operator checks, and some remain unknown. Do not claim automatic recognition unless evidence supports the particular condition and configuration.
When should operating-boundary evidence be reviewed again?
Review it when the task, model, sensing, environment, approved objects, condition monitor, response behaviour or deployment assumptions change. Retain previous results with their original scope and record whether they remain applicable, need supplementary evidence or require replacement.