Defend the System by Following the Evidence, Not by Reading Slides

A technical defense should be easy to challenge and easy to verify.

The reviewer should be able to hear a claim, ask for the evidence, and reach the exact artifact without waiting for you to search through a folder.

Slides can help organize the conversation. They are not the evidence itself.

Build the defense around claims

Use a small number of load-bearing claims, such as:

1. Java boundary behavior meets the tested requirement.
2. Invalid Java state is rejected and previous valid state is preserved.
3. ROS /scan communication evidence matches the documented supplied/local profile.
4. ROS bringup is reproducible from the documented clean-shell procedure.
5. One controlled failure was detected and recovered as predicted.
6. Java-to-ROS integration remains not demonstrated.
7. Physical robot behavior remains outside the required course evidence.

Seven precise claims are easier to defend than thirty vague accomplishments.

One claim should point to one primary artifact

Example:

Claim C-04:
ROS bringup is reproducible from a clean Jazzy shell.

Primary artifact:
Bringup Verification Record

Supporting artifact:
Repeatable Startup Runbook

The reviewer can then inspect:

package prefix
launch command
node list
topic info
shutdown record

without searching unrelated Java tests.

State the limitation before the reviewer has to drag it out

For every claim, include one sentence beginning with:

This does not prove...

Example:

This does not prove the WPILib Java application is connected to the ROS runtime.

That makes the defense stronger because the boundary is already understood.

Use evidence labels consistently

Your defense index should identify evidence as:

local execution evidence
supplied deterministic evidence
source/design artifact
proposed architecture
physical observation

Do not show supplied terminal output and let the reviewer assume it came from your local machine.

Provenance is part of the claim.

Prepare for scope challenges

Reviewer:

You showed a passing JUnit test. Why does that mean the robot is safe?

A bad answer tries to stretch the test.

A strong answer says:

It does not. The JUnit result supports the Java boundary rule under controlled inputs. Physical stopping behavior remains not demonstrated and would require sensor/controller/actuator evidence under an approved hardware test procedure.

You defend the real claim, not the larger claim the reviewer offered.

Prepare for alternative-hypothesis challenges

Reviewer:

The subscriber count was zero. How do you know the listener crashed?

If your evidence did not show a crash, do not accept the premise.

Answer:

Subscriber count zero established the missing endpoint. A listener crash was one hypothesis. ros2 node list and ros2 node info were needed to distinguish a missing process/node from a remapping mismatch.

The defense should preserve the difference between observation and hypothesis.

Prepare for integration challenges

Reviewer:

Where is the Java-to-ROS message trace?

Canonical course answer:

It does not exist in the required course path. The integration contract defines the proposed boundary and verification requirements, so the readiness matrix marks Java-to-ROS integration as NOT DEMONSTRATED.

Do not apologize by inventing evidence.

The honest status is the correct answer.

Prepare for reproducibility challenges

Reviewer:

How do I know the ROS launch only worked because your terminal had hidden setup state?

Point to:

clean-shell runbook
ROS_DISTRO verification
underlay source command
overlay source command
ros2 pkg prefix result
post-launch graph evidence

Then explain that the procedure was written to remove dependency on prior shell history.

Prepare for failure-recovery challenges

Reviewer:

How do you know your repair fixed the defect instead of hiding the failing test?

Show:

original acceptance criterion
injected defect
failure evidence
repair
same detector rerun
recovery evidence

The detector should remain the same.

If you changed the test expectation to make the result pass, that is not recovery evidence.

A defense slide can summarize, but the dossier must contain the details

A useful defense slide might show:

Then the dossier contains the actual test cases, CLI records, runbook, and integration contract.

The slide is navigation.

Do not overwhelm the defense with implementation trivia

You should understand details such as:

CMake install rule
QoS reliability compatibility
Java strict comparison

but not every detail deserves equal presentation time.

Lead with the architecture and readiness decision.

Use implementation evidence when challenged or when it directly supports the claim.

Build the final Defense Packet

Include:

One-page architecture/scope statement

State what systems are in scope and what integration is not demonstrated.

Final readiness table

Use the frozen statuses from Lesson 3.

Evidence index

Every major claim points to exact artifacts.

Controlled failure record

Show detection and recovery.

Integration contract

Show the missing/defined Java-to-ROS boundary.

Next-evidence roadmap

List the two or three most important next verification steps.

Your turn

Prepare a five-minute technical defense.

You may use slides, a document, or the dossier itself, but the defense must answer:

1. What is the strongest readiness claim?
2. Which exact evidence supports it?
3. What failure did you inject and how was recovery verified?
4. What is the Java-to-ROS integration status?
5. What physical evidence is still missing?
6. What is the next engineering milestone?

Then prepare short answers for at least five skeptical reviewer questions.

In the final lesson, you will turn the whole project into a handoff that another engineer can actually continue without relying on your memory.