R4 is learning to carry the work through.

The chapter number stopped telling the whole story

R3 is live, including R3.9. R4.17 remains the latest numbered engineering checkpoint in the records reviewed for this update. But development has continued beyond that chapter: the current frontier is joining the control plane to a real execution route.

A mission contract, a queue and an authorization check can each work in isolation. The next question is whether the same bounded mission preserves its objective, permission and evidence as it moves through all of them. That is where R4 becomes a working system rather than a collection of components.

A recovered result still needs permission

The loop-guard work brings current result checks into the existing execution loop. It checks fresh and cached results before they enter validation, episode capture, learning and persistence. Recovery must not quietly turn an old permission into permission now.

Imagine a job that produced a result just before the reply was lost. On restart, the system should recover that result without repeating the effect. If authority has since expired or been revoked, it should also withhold the result from consumers that no longer have permission to use it. Keeping history and granting current access are separate responsibilities.

The retained loop-guard handoff reports 112 passing selected tests for its frozen candidate. These author-run checks establish the exercised local paths; they do not establish native process-death recovery or independent acceptance.

Start with a deliberately tiny canary

The signed-canary implementation binds a request to an exact actor, resource and project scope. Its prepared trial is deliberately small: one bounded metadata operation, one input and one output, zero model tokens or model cost, and a maximum of sixty seconds. These are design limits for the trial, not a claim that the trial has already run natively.

The signer preparation keeps private signing material local and makes public-key enrollment a separate reviewed operation. Enrollment identifies who may sign. An execution grant determines what that identity may do. Neither can substitute for the other.

The owner-reported 8 October preflight reached route-key enrollment without execution grants. That is progress at the identity boundary, while preserving the distinction between preparation and permission. It does not by itself prove a live mission or close R4.

The next proof is a complete route

The remaining work is to assemble and verify the native mission, task, queue, capture, control and learning owners; authorize the exact bounded operation; and retain evidence from normal execution and failure recovery.

Lost replies, restart, revoked access and missing custody matter as much as the happy path. A clean run should be reconstructable. A blocked run should explain why it stopped. Neither should require rewriting history to make the dashboard look successful.

Independent review, the remaining roadmap gates and formal acceptance still stand between this integration work and an R4 exit. R5 remains the next generation, not a completed or activated capability. No completion percentage is published here because the reviewed records do not establish one.

The WorkMachine keeps its boundary

The WorkMachine remains model-agnostic: a compatible LLM paired with the UBIKITOS harness. The model can propose work; the surrounding system carries identity, scope, authority and evidence through execution.

The exciting change is continuity. R3 makes experience legible. R4 aims to keep a mission moving without losing the conditions that made it acceptable in the first place. The next useful milestone is a bounded, inspectable native demonstration that survives the cases designed to break it.