Make the Readiness Decision With Conditions Attached

The capstone dossier now contains selected Java/WPILib evidence, selected ROS evidence, a repeatable bringup record, an integration contract, and one controlled failure/recovery record.

Now decide what the evidence actually allows you to claim.

A readiness review is not a popularity vote between green checkmarks and red Xs.

It is a structured decision about scope.

Revisit the four status categories

Pass

The acceptance criterion is met by the required evidence.

Conditional pass

The criterion is met within a named environment or limitation.

Example:

ROS bringup passes in the documented local/supplied Jazzy environment.
Physical robot deployment not evaluated.

Blocked

A known failure or missing dependency prevents the claim.

Not demonstrated

The required evidence does not exist in the course path.

This is the expected status for a canonical Java-to-ROS bridge claim unless you independently implemented and documented one.

Readiness can differ by subsystem

A defensible final review might say:

Java component logic: PASS
WPILib/JUnit evidence: PASS
ROS graph/topic understanding: PASS
ROS bringup reproducibility: PASS or CONDITIONAL PASS
Java-to-ROS integration: NOT DEMONSTRATED
Physical robot behavior: NOT DEMONSTRATED

That is not a failed capstone.

It is an accurate architecture review.

The course never promised that all layers would become one physically integrated robot by Week 18.

Do not average unrelated evidence into one score

Suppose ten software tests pass but the bridge is unimplemented.

You cannot write:

90% ready

unless the project has an explicit weighted readiness model with justified criteria.

Ten Java tests do not compensate for zero integration evidence.

Use claim-level statuses instead.

A conditional pass must name the condition

Weak:

ROS runtime: conditional pass

Stronger:

ROS runtime: CONDITIONAL PASS
Condition: supplied deterministic graph evidence satisfies the course runtime criteria; local network/DDS behavior and physical hardware are not evaluated.

Or for a local build:

ROS bringup: PASS on Ubuntu 24.04 / Jazzy in robot_ws using the documented runbook.

The environment is part of the claim.

Blocked and not demonstrated are different

Blocked

You tried to satisfy the claim and a known issue prevents it.

Example:

Bringup blocked: demo_nodes_cpp dependency unavailable in local environment.

Not demonstrated

The claim was never implemented or tested in the required path.

Example:

Java-to-ROS bridge not demonstrated: no bridge implementation or cross-runtime trace exists.

Do not call an unimplemented feature "failed" unless an implementation actually failed its criterion.

The failure injection should influence one claim

If you injected a stale overlay and recovered it successfully, that supports a claim such as:

The startup runbook can diagnose and recover an unsourced-overlay condition without unnecessary rebuild.

It does not automatically upgrade:

physical robot readiness

Keep failure evidence attached to the requirement it tested.

Write a readiness statement for each major layer

Use these layers:

Java component behavior

What requirement and test evidence exist?

WPILib test/runtime evidence

What was executed or supplied?

ROS graph and communication evidence

What nodes/topics/QoS/configuration were actually observed?

Workspace and bringup

Can the startup procedure be reproduced from a clean shell?

Java-to-ROS integration

Is there an implemented and verified bridge?

Physical robot behavior

What hardware evidence exists?

Each section ends with one status.

Build the Final Readiness Table

Use:

Do not allow blank cells.

If evidence is absent, write:

none in required course path

and select the correct status.

Worked final row

Layer:

Java-to-ROS integration

Claim:

WPILib Java battery state is transmitted into the ROS runtime.

Acceptance criterion:

An explicit bridge is implemented and a correlated value can be traced from Java producer through bridge to ROS consumer.

Evidence:

Integration contract only; no implementation/cross-runtime trace.

Status:

NOT DEMONSTRATED

Next evidence:

Select/implement authorized bridge, define interface, run correlated end-to-end trace.

That row is stronger than pretending the integration exists because both runtimes work independently.

Your turn

Complete the final readiness table for at least six layers.

Then write a 100–150 word executive technical summary that begins with the strongest bounded readiness claim you can defend.

Do not begin with:

Everything works.

Begin with something like:

The Java component and ROS bringup layers satisfy their documented software/runtime acceptance criteria in the tested environments, while Java-to-ROS integration and physical robot behavior remain not demonstrated.

Use your own wording and actual evidence.

The lab will assemble the entire Week 17 dossier and prepare it for the final technical defense in Week 18.