How Robotics Companies Are Rethinking Systems Engineering at Scale

The first generation of autonomous robots was built by software teams that mostly ignored systems engineering. Move fast, iterate the neural network, ship firmware. The approach worked well enough when robots lived in controlled warehouses, did one thing, and had a narrow failure envelope. It does not work when robots are on public roads, in hospitals, or operating alongside untrained humans — and when a single field incident can trigger a regulatory review or a product recall.

Robotics companies scaling beyond prototype deployments are discovering that the discipline they skipped is now the bottleneck. Requirements management, safety argumentation, and architecture traceability — the workflows that aerospace primes have been doing for decades — are becoming urgent problems for organizations that have never built a formal requirements process in their lives.

The challenge is that the tooling those aerospace primes use was not built for robots.

What Makes Robotics Requirements Different

Classical systems engineering grew up around deterministic systems. A hydraulic actuator either meets its force output specification or it does not. A radio either operates within its frequency band or it does not. Requirements could be written as binary pass/fail conditions, traced to test procedures, and verified with measurement data. The loop closed cleanly.

Autonomous robots break this model in three specific ways.

Behavioral requirements are probabilistic and context-dependent. A mobile manipulation robot operating in a logistics facility might need to handle 300 SKU types, navigate around unpredictable human co-workers, and recover from sensor occlusion without stopping the line. Writing a requirement for that behavior — one that is specific enough to test against and flexible enough to accommodate the real operating environment — is genuinely hard. “The robot shall detect and avoid obstacles” is not a requirement; it is a wish. But translating that wish into a set of verifiable, bounded, quantified conditions requires understanding the full operating context, the sensor stack, the compute budget, and the acceptable failure modes simultaneously.

Most teams end up writing high-level behavioral requirements that cannot be traced to any specific test, then writing separate test scripts that cannot be traced back to any requirement. The gap between them is where field failures live.

Safety cases require live, dynamic traceability. Robotics safety cases — whether structured as GSN (Goal Structuring Notation) arguments, as required by ISO 26262 functional safety frameworks, or as the safety assurance cases emerging under standards like ISO/PAS 8800 for AI in automotive — are not documents you write once. They are living arguments. Every time a sensor is changed, a model is retrained, or an operating domain is expanded, the safety case needs to be re-evaluated. Claims that were valid last quarter may not be valid today.

Legacy requirements tools treat the safety case as a separate artifact from the requirements database. Engineers maintain a spreadsheet or a Word document that maps hazards to mitigations to requirements to test evidence. When the system changes, someone manually updates that spreadsheet — if they remember to. In practice, safety cases in fast-moving robotics programs are usually months out of sync with the actual system.

Multi-modal sensing creates deep requirement interdependencies. A modern autonomous robot might fuse lidar, stereo cameras, IMUs, force-torque sensors, and structured light in a single perception pipeline. Each sensor has its own operating envelope: temperature range, detection latency, minimum illumination, occlusion behavior. The robot’s behavioral requirements depend on assumptions about sensor performance. The sensor performance requirements depend on assumptions about the operating environment. The operating environment assumptions depend on what the product team committed to in the deployment contract.

These interdependencies are a graph, not a hierarchy. Document-based tools — tools that organize requirements into chapters and sub-chapters — cannot represent them accurately. When a sensor spec changes, there is no automated way to surface which behavioral requirements are now at risk. Engineers find out the hard way.

What the Industry Is Actually Doing

The robotics industry’s response to this problem is not uniform, but several patterns are emerging.

The most common early-stage pattern is requirements-by-GitHub. Teams use issue trackers, Confluence pages, and Notion documents as de facto requirements management systems. This works until a system has more than a handful of engineers or more than one deployment environment. At that point, traceability becomes impossible to maintain manually, and the organizational knowledge of why a requirement exists — its rationale, its derivation — starts evaporating.

A subset of scaling robotics companies, particularly those with aerospace or automotive parentage, have tried to adopt enterprise requirements tools: IBM DOORS, Jama Connect, or Polarion. These tools have real strengths. DOORS has mature change management and formal traceability workflows that hold up under regulatory scrutiny. Jama Connect has strong review and collaboration features that work well for cross-functional teams. Polarion integrates requirements with test management in ways that are genuinely useful for V-model development processes.

But robotics teams consistently report the same friction points with these tools. The data models are built around structured text specifications, not graph-connected system models. Integrating with the actual robot stack — the ROS nodes, the simulation environments, the ML training pipelines — requires custom integration work that never quite gets finished. And the AI capabilities in these platforms are largely bolt-on: search assistance, document summarization, or basic change impact notifications. They do not help an engineer figure out which requirements are affected when a new lidar model replaces an old one, or when a new country’s regulatory environment expands the operational design domain.

The leading edge of the industry is converging on a different model: requirements management that is graph-native, model-connected, and AI-assisted from the ground up. The requirements are nodes in a graph. The architecture elements, test cases, safety claims, sensor assumptions, and regulatory references are other nodes. The relationships between them are typed edges that can be queried, analyzed, and traversed automatically.

Where AI Is Actually Adding Value

AI-assisted requirements analysis is past the hype phase in robotics. Engineers have figured out what it is actually good for, which is not the same as what vendors advertised two years ago.

AI is genuinely useful for three specific tasks in robotics requirements work. First, requirements completeness checking — identifying gaps between a behavioral requirement and the sensor or environmental preconditions it implicitly depends on. Second, consistency analysis across large requirement sets — catching contradictions or incompatible assumptions that no individual engineer would notice because no individual engineer reads the whole database. Third, change impact propagation — when an engineer modifies a requirement or an architecture element, surfacing the downstream requirements, safety claims, and test cases that need to be reviewed.

None of these tasks eliminate engineering judgment. All of them save meaningful time and reduce the probability of missing something important.

Flow Engineering, which has been building AI-native requirements tooling aimed at hardware and systems engineering teams, has been gaining adoption in robotics programs that need this kind of capability without committing to a full PLM migration. The tool’s graph-based data model maps naturally to the interdependency structure of robotic systems, and its AI layer is built into the core workflow rather than added as an optional module. Several robotics teams have reported using it specifically to manage the interface between behavioral requirements and safety case argumentation — the connection that breaks most often in document-based workflows. Its adoption in robotics reflects a broader pattern: teams that cannot afford the integration overhead of legacy enterprise tools, but have outgrown ad hoc documentation, are looking for purpose-built alternatives.

What Good Tooling Needs to Support

For any tool to serve a scaling robotics program, it needs to handle four things that most enterprise requirements tools handle poorly.

Operational design domain (ODD) management. The robot’s requirements are conditional on its operating context. Tooling needs to represent ODD as a first-class entity — not a paragraph in a system specification, but a structured artifact that requirements and safety claims can be explicitly linked to.

Model integration, not just document import. Requirements need to be connected to the architecture models where system structure actually lives — SysML models, ROS package graphs, simulation environments. Read-only import is not enough. When the model changes, the requirements should reflect that change.

Living safety case support. The path from hazard to mitigation to requirement to test evidence needs to be maintained dynamically. When any element in that chain changes, the tool should surface the impact automatically and require an explicit resolution before the change is accepted.

Regulatory flexibility. Robotics programs operate under a patchwork of standards — ISO 26262, IEC 62443, ISO/PAS 8800, UL 4600, and increasingly domain-specific frameworks for medical, aviation, and public space robotics. Tooling that is hardcoded for one regulatory framework creates more work than it saves.

Honest Assessment

The robotics industry’s systems engineering problem is real and it is getting harder as deployments scale. The good news is that the industry is solving it — not by adopting aerospace workflows wholesale, which would kill the iteration speed that robotics programs depend on, but by building new workflows that are faster, more connected, and more AI-assisted than anything the defense primes use.

The tooling market is responding, though unevenly. Legacy enterprise tools are adding AI features at varying levels of integration depth. Purpose-built tools are gaining ground among teams that prioritize workflow fit over feature breadth.

What is clear is that the teams shipping autonomous robots at scale in 2026 are the ones that took requirements seriously before they had to. The teams that will struggle in 2027 are the ones still managing requirements in Confluence.