What the next RC-01 checks need to establish

The planning checkpoint

RC-01 has reached a useful planning checkpoint. The voice qualification criteria, a manually controlled perception-to-conversation design, and production asset standards have been approved on paper. The next stage is to establish what those designs can support in an exact, supervised configuration. The new qualification cases have not been run, and hardware changes and powered testing remain on hold.

That leaves a practical engineering question: what evidence would justify moving from individual bench demonstrations toward integration readiness?

Establish a complete conversation path

Ash’s Michael voice at speed 1.15 is accepted for its voice and pacing. The existing manual Pi-to-Windows route now has a provisional bench designation in the project record. That decision identifies the route to qualify; it makes no operational change and does not authorize a qualification run.

The remaining questions concern the whole exchange. Did the listener capture the complete question? Did recognition preserve its meaning? Was the answer supported by the selected source? Did the correct reply reach the selected output, and was it actually heard?

Earlier pilots provide useful, bounded observations. They also retain recognition failures, open factual-grounding issues and unresolved practical delay. A software playback-complete message records a software event. Human listening and evidence of the physical output are still needed for an acoustic claim. Windows playback cannot establish independent Pi speaker performance.

The prepared voice suite contains 36 new cases, all unrun. It starts with a small supervised checkpoint after the exact route, devices, consent, evidence destinations and test scope are settled. A successful checkpoint would support review of deeper qualification. Broader acceptance would require the applicable full cases and an owner review of the results for that build and route.

Failures remain part of that record. A fast successful response cannot cancel out a stale reply, a lost question or an unsupported answer.

Keep perception advisory

The approved integration direction gives perception a deliberately limited role. A manually started coordinator would read context without changing the existing perception services. Presence information could inform a human-started conversation, but a presence change would not start recording, generate a reply or trigger speech.

Consider an old observation that someone was nearby. Before that information could help a reply, the coordinator would need to distinguish a current observation from a startup snapshot, a stale record or an unknown state. If freshness cannot be established, the context must remain unknown or be omitted. An old observation must not become a confident statement about the room now.

The design also retains explicit capture and playback controls, with recording closed during playback. Cancellation must invalidate pending work, and uncertain playback must not be automatically replayed after a restart.

Those are adopted design requirements. The coordinator has not been installed, and its 24 integration cases remain unrun. The interfaces for reliable completion, cancellation and exclusive ownership across the existing voice routes still need evidence and scoped implementation decisions. Running perception and voice on the same system does not, by itself, demonstrate that these boundaries work.

Qualify the actual target

The same discipline applies to the visual and physical parts of RC-01. An approved appearance, prepared asset, bounded renderer test and accepted production placement are separate milestones. Existing animation pilots can help select what to review, but the production target and its display and performance limits still need to be settled.

Historical results keep their original conditions. A browser check, a voice replay and a live bench observation answer different questions. Adding them together would obscure which part of the system was actually exercised.

For the physical build, the Physical Ash Engineering Plan (linked below) describes the approved paper direction and the review ahead. Hardware changes and powered testing remain on hold until the specific hardware and design have been identified, reviewed and approved on paper. Later controlled physical validation will still be necessary. Paper review prepares a later test decision; the physical result still has to be observed.

The current checkpoint

Completed preparation: the test criteria, integration design and asset standards are documented and adopted within their stated scope.

Observed results: earlier bounded demonstrations remain useful evidence, with their original failures and limitations. This checkpoint adds no new runtime or hardware test result.

Next decision: settle the exact prerequisites and authorized scope for the next validation activity. The new qualification runs depend on that separate authorization.

The value of these gates is that each future result can support a clear engineering claim. A useful next milestone will identify the route, conditions and observed outcome closely enough that another review can tell exactly what was established and what remains open.

Evidence cutoff: 12 October 2026. This checkpoint reflects the current approved paper directions and dated project records; it is not a new test report.