A Readiness Claim Needs an Acceptance Criterion

The capstone begins with a question that sounds simple:

Is the robot software ready?

That sentence is too vague to answer responsibly.

Ready for what?

• ready for another software test;
• ready for ROS runtime demonstration;
• ready for simulation;
• ready for hardware integration;
• ready for autonomous physical operation;
• ready for deployment to a competition robot?

Each claim requires different evidence.

Turn readiness into specific claims

Instead of:

The system is ready.

write claims such as:

The Java obstacle-guard rule handles the 0.50 m boundary as specified.

The ROS bringup can be launched reproducibly from a clean Jazzy shell.

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

Java-to-ROS data exchange has not yet been demonstrated.

These statements can be tested or bounded.

Define an acceptance criterion

An acceptance criterion states what evidence must exist before you mark a claim as passed.

For the Java boundary claim:

Acceptance criterion:
JUnit test passes for 0.49, 0.50, and 0.51 m using the specified strict comparison.

For repeatable ROS bringup:

Acceptance criterion:
From a clean shell, source Jazzy and robot_ws, resolve robotnix_bringup, launch demo_pair.launch.py, and observe /talker_demo, /listener_demo, and the expected topic/endpoints.

The criterion should be written before you look at the final evidence whenever possible.

Otherwise it is easy to lower the standard after seeing a failure.

Use four readiness categories

For this capstone, classify each claim as one of:

Pass

Required evidence exists and matches the criterion.

Conditional pass

The claim is supported within a named condition or environment, but stronger deployment requires additional evidence.

Example:

Passes deterministic/local ROS bringup test; physical robot deployment not evaluated.

Blocked

A known missing dependency, failure, or unresolved defect prevents the claim from being accepted.

Not demonstrated

The course does not currently contain evidence for the claim.

This is different from failure.

For example:

Java-to-ROS bridge: not demonstrated

means the integration was not implemented/tested in the required course path. It does not mean a tested bridge failed.

Do not turn “not demonstrated” into embarrassment

Engineers frequently work with incomplete evidence.

The professional response is to mark the boundary clearly.

A system review becomes dangerous when missing evidence is disguised as success.

The phrase:

not demonstrated

can be the most accurate line in the entire report.

Build the Claim-to-Evidence Matrix

Create columns:

Start with at least these claims:

1. Java component boundary behavior;
2. Java invalid-update state preservation;
3. WPILib test/runtime evidence available;
4. ROS Jazzy shell/runtime introspection works;
5. /scan topic type/endpoints understood;
6. QoS failure/repair understood;
7. service/action/parameter interaction models understood;
8. robotnix_bringup workspace builds;
9. bringup launches reproducibly;
10. Java-to-ROS integration demonstrated;
11. physical sensor/motor behavior demonstrated.

Do not fill every status with Pass.

Some canonical course claims should remain conditional or not demonstrated.

Evidence must name its source

This is weak:

Evidence: terminal output

This is stronger:

Evidence: Week 15 local Bringup Verification Record, command ros2 topic info /robotnix/demo, publisher count 1, subscription count 1.

Or:

Evidence: Week 12 supplied deterministic QoS record, RELIABLE inspection subscriber rejected against BEST_EFFORT publisher.

A reviewer should be able to find the source and understand whether it was local, simulated, supplied, or physical.

One artifact can support several claims, but do not stretch it

A JUnit test record can support:

• boundary logic;
• exception behavior;
• state preservation.

It cannot support:

• ROS graph presence;
• DDS delivery;
• wheel movement.

Similarly, a ROS graph snapshot can support node/topic relationships but not Java method execution.

Capstone quality comes from matching evidence to the correct claim.

Worked matrix row

Claim:

The bringup package is visible in the intended overlay.

Acceptance criterion:

A clean shell sources Jazzy and ~/robot_ws/install/setup.bash, then ros2 pkg prefix robotnix_bringup resolves the robot_ws install prefix.

Evidence:

Week 14 Workspace Build and Overlay Record

Status:

Pass in the documented ROS environment

Limitation:

Package visibility does not prove the launch runtime is healthy.

That row is specific enough to review.

Your turn

Create the first version of your Claim-to-Evidence Matrix.

Do not attach screenshots yet.

For every claim, write:

• what must be true;
• what evidence would prove it;
• what evidence you actually have;
• whether the status is pass, conditional pass, blocked, or not demonstrated;
• one stronger claim that the evidence does not justify.

In the next lesson, you will choose representative Java/WPILib evidence rather than dumping every exercise from the course into the capstone.