Stage 6: Context Projection and Long-Term State

Course: LoopX Source Code Class · Stage Test
Prerequisite: Stage 5, understanding writeback, consumption, and scheduling
Corresponding overview: Context and state sections of core-mechanisms.md
Goal of this stage: Distinguish canonical facts, read models, and Host context, and understand the role of refresh/frontier.

1. What this stage solves

LoopX does not stuff long-term memory into the chat transcript. It saves Goal, Todo, claim, gate, quota, authority, evidence, and run history, then regenerates each round:

• Status/Dashboard for humans;
• Next action/attention for Agent;
• Turn envelope for Host;
• Cadence/ownership for scheduler;
• Evidence/frontier for validation.

The same fact can have multiple projections, but a projection cannot become the sole source of truth.

2. A judgment to remember first

Facts are recoverable, projections can be recalculated; missing projections are not data loss, only overwriting facts with projections is an accident.

So when encountering “Status shows completion but Goal is not done,” first check the canonical state and receipt; do not directly change the Status.

3. Source code mainline

1. registry.py Reads registered facts such as Goal, Agent, and authority.
2. control_plane/goals/state_resolution.py and goal_frontier/ calculate the current goal frontier.
3. control_plane/todos/contract.py Define the scope, dependencies, task category, and continuation conditions of Todo.
4. control_plane/goals/acceptance.py Perform acceptance using the frozen acceptance basis.
5. control_plane/runtime/run_history.py Save per-round run facts; state_refresh.py::refresh_state_run() rebuild projections after settlement.
6. status.py::collect_status() Generate read models; capability_hooks.py::project_turn_context() generate Host context projections.
7. quota/turn_envelope.py Then compress the context into a contract package within the byte budget.

4. Key objects and contracts

Layer	Typical objects	Lifespan	Recomputable?
canonical fact	Goal state, Todo, claim, gate, quota, evidence, run receipt	Long	No, must be recovered
derived index	frontier, attention queue, next action	Medium	Yes
human projection	Status, Kanban, Dashboard markdown/HTML	Short	Yes
Host projection	turn envelope, Host prompt, selected context	Single round	Yes
acceptance basis	frozen acceptance rules and snapshots	Single acceptance	Should not be overwritten by projection drift

Why completion cannot rely solely on Status

Status may be delayed, filtered, trimmed by permission, or generated by older rules. True completion requires typed result, validation, durable writeback, quota spend, and lifecycle receipt. Status can only help locate progress; it cannot prove submission.

Why frontier must be recalculated

One round of progress may add dependencies, close branches, enable successors, or trigger replanning. Frontier is a projection of “given current facts, what options are available next” and must be recalculated after writeback, rather than using the previous round’s list.

Why acceptance must freeze the basis

If acceptance criteria are changed during execution, the Agent could “complete” by changing the criteria instead of changing the result. Freezing the basis, recording digest/revision, and then writing back observations ensures acceptance is reproducible.

5. An observable chain

registry + goal state + todos + receipts
  → resolve_goal_state / frontier
  acceptance basis (if acceptance is required)
  → run history
  → state_refresh
  → status / attention / next actions
  → capability_hooks.project_turn_context
  → quota turn envelope
  → Host

If a field appears in both Status and envelope, trace which canonical object it comes from, rather than copying from another projection.

6. Experiment

Experiment A: Only change the projection

Modify a Status markdown without changing the Goal state. Reference acceptance: After the next refresh-state display, it returns to the facts; This indicates that the projection is not a source of fact.

Experiment B: Observe changes in the frontier

Close a Todo in a round of progress and add a successor. Reference acceptance: After writing back, frontier recalculates, and a new next action appears; Old next actions cannot be used via cache.

Experiment C: Freezing Acceptance basis

Record the digest/revision of acceptance, then try to change the configuration. Reference acceptance: This acceptance still uses the freezing basis; New configurations only take effect in valid new revisions.

Experimental Reference Answers

1. Manually changing Status is not a factual change; The next refresh will recalculate and overwrite from the canonical state.
2. The frontier should be recalculated from the canonical dependency written back in this round; If the old next action conflicts with the new frontier, it must be disabled.
3. Acceptance should use the frozen basis digest/revision; Configuration changes can only take effect in the new revision and cannot retroactively rewrite the current acceptance.

7. Failure and recovery

Phenomenon	Source of Facts	Restoration
Status and Goal Inconsistencies	registry/state/receipts	Recalculating the projection, no manual modification of status
next action points to closed Todo	frontier recalculation	Refresh and re-pass access
Host Fails to See Key Evidence	context projection/envelope	Check the projection rules and budget, do not paraphrase canonical
Acceptance Standard Drift	acceptance basis	Use the freeze revision to re-execute acceptance
Run History Missing a Round	journal/receipt	Restoring from the submitted stage without recreating the history
Memory repeated injection	Projection deduplication and scope	Deduplication, no deletion of facts

8. Pass through customs and self-test

1. What are the differences in the lifecycle of Goal state, Status, and turn envelope?
2. Why can’t you “fix” the target state by modifying the Status?
3. Why does frontier have to recalculate after writing back?
4. Acceptance: Why is it necessary to freeze basis and digest?
5. What is the relationship between run history and the host context?
6. What is the first action when a projection conflicts with facts?

Reference answers

1. Goal state is a long-term canonical fact; Status is a recalculable human read projection; Turn envelope is a single-round, budget-based, host-oriented contract projection. The three are not interchangeable.
2. Status is just a derived view; modifying it does not produce validation, writeback, or receipt. The next refresh will return to canonical facts and create the illusion that “looks fixed but actually doesn’t.”
3. progress may change Todo dependencies, close branches, or prepare successors; completion may switch to active goals. Only frontier reflects what can be done next based on the state recalculation after writeback.
4. If acceptance rules are modifiable, the Agent can move the goal. Freezing basis, digest, and revision allows acceptance observations to be reproduced and to prove which version of the standard is used.
5. Run history is facts and audits, while Host context is a limited view projected from facts, frontiers, and capability requirements. Host should not read the full history directly, nor treat the history summary as a canonical state.
6. First, locate the canonical fact and receipt to confirm which fact has changed; then revise the projection rules and recalculate. Do not change the display layer first.

9. Source code coordinates

• loopx/registry.py
• loopx/control_plane/goals/state_resolution.py
• loopx/control_plane/goals/acceptance.py
• loopx/control_plane/goals/goal_frontier/
• loopx/control_plane/todos/contract.py
• loopx/control_plane/runtime/run_history.py
• loopx/state_refresh.py
• loopx/status.py
• loopx/control_plane/capability_hooks.py

10. Next

Entering Stage 7: How can the same set of facts and projections be used together with CLI, Dashboard, Goal Mode, and extended hosts?