Checkpoint: Following Ownership from Request to Recovery
Apache Maka’s first architectural ideas now meet in one practical question: when a user request travels through a Host, a Run, and several projections, which parts can be trusted and which parts still need evidence? This checkpoint connects the durable Runtime Event Log with the one-writer Runtime Host and uses that combined model to judge a new state, observation, or action. The result is a working way to follow an execution without confusing its owner, its display, or its next possible step.
Take the running example of a user asking Maka to find and fix a failing test. The request begins at a product entry point, enters a Host that owns the State Root, and becomes an admitted execution in a Session. An AgentRun then carries the concrete attempt. The model and tools produce facts; the event log preserves them; the Host and its clients expose projections of those facts. The path is simple enough to draw, but its meaning depends on the boundaries between each stage.
One execution, several accountable views
The first useful connection is between lifecycle and evidence. The client’s request is an intention. Host admission says that one authority accepted that intention for a particular Session and execution identity. The Run says which concrete attempt is doing the work. RuntimeEvents then record the model/tool interaction, user decisions, and terminal outcome. Only after those facts are committed can the surrounding views safely interpret them.
This path is not a promise that every event appears everywhere. The interface may show a compact tool card, the model may receive a context-limited history, and recovery may inspect only the committed prefix. The point is that each view has a relationship to the same execution facts. A UI status can be stale without changing the terminal fact. A context projection can omit old detail without deleting it. A recovery decision can remain unresolved without turning the unresolved state into failure or success.
The path also makes the Runtime Host’s role more precise. The Host is not simply the first box before the Runtime. It is the owner that decides whether the request may enter the State Root and which execution identity carries it. Once admitted, the Runtime and AgentRun own the model/tool facts. Session Continuity and clients can read or project those facts, but they do not acquire the right to create a second interpretation of the Run.
That distinction matters when a client disconnects. A lost screen does not prove that the Run stopped. A reconnect does not prove that the Run should start again. The client needs the Host’s durable state and the Runtime log to determine whether the work is still active, already terminal, or unresolved. A callback that never arrived is a delivery problem; it is not evidence that the command never ran.
The same reasoning applies to concurrent work. One State Root has one writer Host, but that does not mean only one Session can make progress. The Host can serialize the critical admission work for an individual Session while allowing different Sessions to execute concurrently. The single authority prevents contradictory ownership; it does not require every task to share one serial queue.