RobotnixAcademy

Unit 18 · lesson

Challenge the Evidence Before Someone Else Does

A technical defense is not a ceremony where the reviewer agrees with your conclusion.

The reviewer should be able to challenge the claim, ask where the evidence came from, and force you to state the boundary clearly.

Week 18 begins by stress-testing the Week 17 dossier.

Every strong claim should survive five questions

For each major readiness claim, ask:

  1. What exactly is the claim?
  2. What acceptance criterion defines success?
  3. Which artifact directly supports it?
  4. What does that artifact not prove?
  5. What result would make you downgrade the status?

If you cannot answer all five, the claim is not ready for defense.

Challenge the Java boundary claim

Claim:

The obstacle guard handles the strict 0.50 m boundary correctly.

Evidence:

0.49 -> true
0.50 -> false
0.51 -> false

Challenge:

What does this prove about a physical lidar or motor?

Correct response:

Nothing directly. The evidence demonstrates the Java rule for controlled inputs. Sensor freshness, ROS transport, controller output, and physical motion are separate claims.

A strong defense does not become defensive when the scope is narrowed. It already knows the scope.

Challenge the ROS topic claim

Claim:

The supplied /scan endpoints are QoS compatible under the documented profile.

Evidence:

BEST_EFFORT publisher
BEST_EFFORT subscriber
compatible supplied message observation

Challenge:

Does that prove every scan is delivered?

No.

Best-effort communication can lose messages, and the supplied evidence covers a bounded lesson state.

The claim should remain about endpoint compatibility and the observed sample, not guaranteed delivery.

Challenge the bringup claim

Claim:

The ROS demo bringup is reproducible from a clean shell.

Challenge:

How do you know you were not depending on an old sourced workspace?

Answer with:

clean shell
ROS_DISTRO verified
intended overlay sourced
robotnix_bringup prefix resolved to robot_ws
launch command recorded
post-launch node/topic evidence recorded

The runbook is part of the evidence.

Challenge the integration claim

Claim:

Java-to-ROS integration is not demonstrated.

A reviewer may ask:

But both sides work. Why not call the system integrated?

Your answer should identify the missing bridge/interface trace.

Independent subsystem health is not data exchange.

This is one of the most important conclusions in the course.

A challenge can reveal that a claim is too broad

Suppose your dossier says:

ROS communication: PASS

A reviewer asks:

Which topic? Which endpoints? Which QoS? Which observation window?

If your evidence only covers /scan, the claim should be repaired:

The supplied /scan publisher/subscriber pair satisfies the documented type and QoS compatibility criteria in the Week 12 deterministic evidence.

That narrower claim is stronger because it can be defended.

A challenge can also reveal missing acceptance criteria

Suppose the dossier says:

Logging: PASS

What was the requirement?

If you cannot state what the logs were supposed to demonstrate, the status is meaningless.

Rewrite the claim around a real requirement, such as:

The selected runtime log preserves the rejected value and contextual source needed to reconstruct the incident.

Then point to the actual record.

Practice the difference between evidence and explanation

Evidence:

publisher count: 1
subscription count: 0

Explanation:

The expected subscriber is not visible on this topic in the observed graph.

Hypothesis:

The listener remapping may be wrong.

Do not present the hypothesis as if it were the raw evidence.

A reviewer should be able to see the transition from observation to interpretation.

Build a Challenge Sheet

For each of your six most important claims, write:

Claim ID
Claim
Acceptance criterion
Evidence artifact
Likely reviewer challenge
Your bounded answer
Status change trigger

At least one claim must be from each area:

  • Java/WPILib;
  • ROS runtime;
  • bringup/workspace;
  • integration boundary.

Worked challenge sheet entry

Claim

robotnix_bringup resolves from the intended overlay.

Acceptance criterion

Fresh shell sources Jazzy and ~/robot_ws/install/setup.bash; package prefix resolves under robot_ws.

Evidence

Week 14 Workspace Build and Overlay Record.

Challenge

Could a different workspace with the same package name be shadowing it?

Answer

The recorded ros2 pkg prefix robotnix_bringup output identifies the actual resolved prefix.

Status change trigger

If prefix resolves outside the intended workspace, downgrade the claim and repair the environment.

Your turn

Create six challenge-sheet entries.

Then ask another student, or simulate a skeptical reviewer, to challenge at least three of them with:

How do you know?
What else could explain this?
What does this not prove?
What would make the result fail?

Repair any claim that cannot answer those questions cleanly.

In the next lesson, you will focus on alternative hypotheses, because one observation often has more than one plausible cause.