First Checkpoint: From Goal to Accountable Action

LoopX's Goal state, work graph, and governed-turn contract are three views of one problem: how to make the next agent action both legal now and recoverable later. The useful judgment is not whether a project has an open task or a successful-looking run, but whether current facts identify the right frontier, the right actor, the right boundary, and the evidence needed for the next transition. The following model brings those relationships together without adding another lifecycle layer.

One causal loop, not three separate features

The state substrate answers where durable facts live. The work graph answers which work survives current conditions. The interaction contract answers what the user, Agent, and CLI should do with that surviving work. They form a causal chain rather than a collection of conveniences.

A Goal supplies the durable boundary: the objective, the repository or project scope, the acceptance conditions, authority sources, and the conditions under which work may continue or stop. Its state surfaces preserve the facts that outlive a session. A Todo then gives one piece of work an identity, task class, owner route, dependencies, evidence expectations, and continuation semantics. The frontier is the result after those items pass through Gate, claim, capability, workspace, freshness, and priority checks. It is not simply the set of unchecked boxes.

From that frontier, LoopX produces an interaction contract. This is the point at which the system stops speaking in vague terms such as “the agent should keep going.” The user channel may ask for a scoped decision. The Agent channel may require one independent Todo to be attempted, or may require a read-only observation, repair, or replan. The CLI channel may require validation and durable writeback before one spend. One channel does not erase the others.

The Agent and host then perform a bounded action. The result can be a changed artifact, an external observation, a provider receipt, or a concrete blocker. Independent validation determines whether that result supports the claimed transition. Only after that check does the owning state path record the accepted delta. The refreshed state produces the next frontier and contract. A scheduler may then decide when the host should look again, but it does not decide that the work was authorized or completed.

flowchart LR F["Durable facts\nGoal, state, evidence"] --> W["Work graph\nfrontier and scope"] W --> I["Interaction contract\nuser, Agent, CLI"] I --> T["Bounded Turn"] T --> V["Validation and readback"] V --> K["Accepted delta\nor concrete blocker"] K --> D["Durable writeback"] D --> S["Spend once\nwhen allowed"] S --> N["Recompute\ncontinue, wait, ask, repair, terminal"] N --> W I --> U["Scoped user decision\nor explicit wait"] U --> W

The direction of the arrows matters. Durable facts constrain the work graph; the work graph constrains the turn; the turn returns evidence; accepted evidence changes durable facts. A dashboard or prompt can display the result of this process, but cannot jump from “the Agent says it is done” directly to “the Goal is complete.”

The same model also explains why these concepts must not be collapsed. If state, work selection, and execution were one mutable object, a host could replace a Goal with its latest plan and erase another peer's progress. If the work graph were only a list of open items, a user Gate could freeze unrelated work and a monitor could consume delivery turns before its due time. If the interaction contract were only a Boolean, a host would have to guess whether false means “ask the owner,” “wait for CI,” “repair the workspace,” “no candidate for this peer,” or “the Goal is terminal.” Each guess would create a different recovery behavior.