Freeze the Acceptance Criteria, Then Make the Final Readiness Decision

The final readiness decision should not move because you want a cleaner-looking report.

By now, your Claim-to-Evidence Matrix already contains acceptance criteria. Week 18 uses those criteria as written.

Do not weaken them after seeing the final evidence.

Re-check every row against its original criterion

For each readiness claim, compare:

acceptance criterion
actual evidence
status

If the evidence satisfies the criterion, mark the appropriate pass category.

If the evidence is missing, use NOT DEMONSTRATED.

If a known failure prevents acceptance, use BLOCKED.

If the criterion is met only within a named environment or scope, use CONDITIONAL PASS.

A pass is not permission to make a larger claim

Example:

Claim:
robotnix_bringup launches the demo pair reproducibly.

Status:
PASS in documented Jazzy environment.

Do not rewrite the conclusion as:

The whole robot software stack is ready.

The pass applies to the exact claim.

Conditional pass should be useful, not vague

Weak:

CONDITIONAL PASS because more testing is needed.

Stronger:

CONDITIONAL PASS for supplied/local ROS runtime evidence.
Condition: physical network behavior and hardware are outside the tested course path.

The condition tells the next engineer what still has to happen.

Preserve not-demonstrated integration if that is the evidence

The canonical course does not require an implemented Java-to-ROS bridge.

If your dossier contains only a proposed integration contract, the correct row remains:

Java-to-ROS integration: NOT DEMONSTRATED

Do not upgrade it because the Java and ROS subsystems each pass independently.

A missing bridge is not solved by confidence.

Physical readiness also requires physical evidence

If you did not test:

• real sensor freshness/accuracy;
• actual controller output;
• actuator response;
• stopping distance;
• power/safety interlocks;

then do not claim physical deployment readiness.

The final report can still be strong:

software component behavior demonstrated
ROS bringup demonstrated
physical deployment not demonstrated

That is a valid engineering conclusion.

Contradictory evidence must lower confidence

Suppose your bringup record passes once but another clean-shell run resolves the wrong workspace.

Do not choose the nicer result.

Investigate the contradiction.

Until the startup procedure is reproducible, the bringup claim may need to become:

BLOCKED

or:

CONDITIONAL PASS pending environment cleanup

Readiness depends on repeatability, not the best run you can find.

Use the next-evidence column as the roadmap

Every non-final claim should end with a specific next evidence requirement.

Examples:

Implement authorized Java-to-ROS bridge and correlate one value end to end.

Run physical sensor calibration and controlled stopping-distance test under approved safety procedure.

Repeat clean-shell bringup on a second machine using only the runbook.

Avoid:

do more testing

The next step should be actionable.

Write the final readiness statement

Use this structure:

Demonstrated

Name the layers that meet their criteria.

Conditional or blocked

Name any layer that depends on environment or unresolved defects.

Not demonstrated

Name integration or physical claims without evidence.

Next evidence

Name the most important evidence required to increase readiness.

A defensible example:

The selected Java component behavior and ROS 2 Jazzy bringup satisfy their documented software/runtime acceptance criteria in the tested or supplied environments. The startup procedure is reproducible when the intended overlay is sourced and verified. Java-to-ROS data exchange remains not demonstrated because no bridge or correlated cross-runtime trace exists. Physical sensor, controller, and actuator behavior are also not demonstrated in the required course path. The next readiness milestone is an explicitly selected integration mechanism with an end-to-end data trace, followed by controlled hardware verification under an approved safety procedure.

Use your own evidence and wording.

Do not add marketing language

Avoid:

production-ready
battle-tested
fully autonomous
safe for deployment

unless your acceptance framework actually defines and proves those states.

Technical review language should be narrower than marketing language.

Your turn

Freeze your final readiness table.

For every row:

• retain the original acceptance criterion;
• cite the exact evidence artifact;
• select one allowed status;
• write the condition/block/next evidence;
• identify one challenge that could downgrade the claim.

Then write the final readiness statement.

In the next lesson, you will turn the dossier into a concise technical defense that lets the reviewer move from each claim directly to its evidence.