Unit 18 · lesson

Prove the Robot Before You Trust It

A design review is not a sales pitch.

Your job is to show where the system works, where it is uncertain, and what evidence supports the claim.

Verification matrix

Connect every important requirement to a test.

Requirement	Test	Evidence
R-01	complete route from start pose	pose/state log
R-06	activate stop during motion	command + output trace
R-10	inject stale localization message	fault/state log

A requirement without a test is mostly a hope.

Include bad conditions

At least four tests should challenge assumptions.

Examples:

wheel slip;
sensor dropout;
delayed message;
target partly hidden;
higher payload;
obstacle appears;
failed acquisition;
operator stop.

Use simulation, recorded/supplied data, analytical traces, or a safely supervised physical system.

Architecture defense

Your final dossier should contain:

mission and constraints;
requirement set;
system architecture;
power and communication paths;
mechanism decision;
sensor/measurement chain;
control strategy;
autonomy state graph;
human authority and stop boundary;
failure/recovery analysis;
verification matrix;
limitations and next revision.

The final question

Do not conclude with "the robot works."

Conclude with a bounded claim:

Under the tested conditions, the design satisfied ______. It did not yet prove ______. The highest remaining risk is ______ because ______.

That is how an engineering review sounds when confidence follows evidence instead of replacing it.

Build a verification matrix

Your final review should connect requirements to evidence.

Requirement	Verification method	Evidence	Result
R-01 route completion	simulation mission	state + pose log	pass/fail
R-04 localization error	checkpoint comparison	error table	pass/fail
R-06 safe stop	injected stale pose	stop trace	pass/fail
R-08 recovery	simulated sensor loss	recovery state log	pass/fail

A requirement with no verification method is still a hope.

Include a failure on purpose

A perfect demo teaches very little about robustness.

Inject one bounded failure in simulation or analyze a supplied failure trace:

stale localization;
dropped sensor;
delayed message;
wheel slip;
blocked route;
perception miss.

Predict the expected system response before running or analyzing the case.

Then compare:

predicted response
      ↓
observed evidence
      ↓
difference
      ↓
architecture revision or justified acceptance

Defend the tradeoffs

The final defense should answer questions such as:

Why is this sensor appropriate for the operating boundary?
What fails if this processor disappears?
Where is human authority enforced?
Which requirement drove the mechanism choice?
What evidence shows the controller is stable enough?
Which risk remains unresolved?

A trustworthy engineering review includes limitations. Hiding uncertainty does not make the system stronger. It only makes the documentation less accurate.