# Contextual Momentum

*By suiGn |* [*neurons.me*](https://neurons.me)

---

## When Coherence Becomes Its Own Evidence

Large language models generate responses conditioned on the context they receive, including their own previous outputs.

An early assumption can become the premise for later reasoning. Once incorporated into the conversation, that assumption may influence subsequent responses even when the underlying conditions have changed.

Research has already documented related behavior. In [How Language Model Hallucinations Can Snowball](https://arxiv.org/abs/2305.13534), Zhang et al. (2023) investigate how language models can compound earlier mistakes through subsequent generations.

But the problem does not necessarily begin with a hallucination.

A model may start with an accurate observation, preserve it in context, and continue reasoning from it after the external state has changed.

The original observation was correct.

The continuation may not be.

I use **Contextual Momentum** to describe this pattern:

> A generated representation maintains continuity and internal coherence while progressively losing correspondence with the state it is supposed to describe.

This is a descriptive engineering term, not a claim about a newly discovered mathematical property of transformers or a scientifically distinct phenomenon.

The practical question is straightforward:

**How do we prevent a plausible continuation from becoming an invalid operation?**

Retrieval, reflection, and better prompting can improve model behavior. However, none of these techniques independently guarantees that a proposed operation satisfies the current conditions of an external system.

That requires validation against state outside the model's narrative.

This article explores that separation using [`.me`](https://github.com/neurons-me/.me), a reactive semantic kernel with explicit dependencies and inspectable evaluation.

---

## 1\. The Problem Does Not Require an Initial Hallucination

Consider an autonomous robot.

At time `t0`, its battery is sufficiently charged.

```text
t0

robot.battery = 90
robot.minimumBattery = 30

canProceed = true
```

An AI assistant observes the state and concludes:

```text
t1

Model:
"The robot can proceed."
```

The statement is correct.

Now imagine the battery changes while the model continues operating with its previous context.

```text
t2

robot.battery = 10

Model context:
"The robot can proceed."
```

The model has not received the updated battery value.

Its earlier conclusion remains available as context.

At `t3`, it proposes:

```text
t3

Model:
"Proceed with the operation."
```

The proposal is consistent with the model's previous observation.

But it is inconsistent with the current operational state.

```text
Current state:

battery = 10
minimumBattery = 30

canProceed = false
```

Nothing about this scenario requires the model to have made an incorrect initial observation.

The failure emerges when previously valid information continues influencing decisions after the conditions supporting it have changed.

This resembles a familiar problem in software engineering: **stale state**.

The distinction here concerns how stale information participates in language-model generation. An outdated representation may remain embedded in a coherent narrative and influence subsequent proposals without being reevaluated against the system it describes.

Conversational consistency and operational validity are different properties.

---

## 2\. Separating Generation from Execution

A language model can generate an operation without being responsible for determining whether that operation is currently valid.

This suggests a separation of responsibilities:

```text
[ LLM / Agent ]
       |
       v
[ Proposed Operation ]
       |
       v
[ State Evaluation ]
       |
       +-- Current Values
       +-- Dependencies
       +-- Derived Conditions
       |
       v
[ Execution Boundary ]
       |
       +-- Preconditions
       +-- Authorization
       |
       v
[ Accept / Reject ]
       |
       v
[ State Transition ]
```

The model produces a candidate action.

The application evaluates the conditions required to perform it.

The execution boundary determines whether the action is permitted.

These responsibilities can be implemented using conventional validation functions, state machines, transactional systems, or other architectures.

The approach explored here uses a reactive semantic kernel to maintain derived conditions and expose their computational dependencies.

The objective is not to make the model incapable of generating an invalid proposal.

It is to prevent that proposal from becoming an invalid state transition.

---

## 3\. Reactive Conditions with `.me`

[`.me`](https://github.com/neurons-me/.me) represents state through paths and supports derived expressions with explicit dependencies.

Consider a simple calculation:

```javascript
me.menu["="](
  "total",
  "coffee.price + bread.price"
);
```

The derived value depends on two inputs:

```text
coffee.price ────┐
                 ├── menu.total
bread.price ─────┘
```

When an input changes, the kernel can update the corresponding derived value through its reactive dependency mechanism.

The relationship is maintained in application state rather than reconstructed from conversational history.

### A Reproducible Robot Example

The same mechanism can represent an operational precondition.

The following example uses `this.me@4.2.1`:

```javascript
const { ME } = require("this.me");

const me = new ME();

me.robot.battery(90);
me.robot.minimumBattery(30);

me.robot["="](
  "canProceed",
  "battery >= minimumBattery"
);

console.log(me("robot.canProceed"));
// true

me.robot.battery(10);

console.log(me("robot.canProceed"));
// false

console.log(me.explain("robot.canProceed"));
```

The initial condition is:

```text
90 >= 30 → true
```

After changing the battery:

```text
10 >= 30 → false
```

The derived condition updates without requiring the language model to regenerate the expression.

The reported `explain()` result exposes the relevant information:

```text
value: false

expr: "battery >= minimumBattery"

inputs:
  robot.battery = 10
  robot.minimumBattery = 30

dependsOn:
  - robot.battery
  - robot.minimumBattery
```

This illustrates two useful properties.

First, a derived condition can respond to changes in its dependencies.

Second, the relationship behind the result can be inspected.

The model does not need to remember that the battery changed. The application maintains the relevant relationship independently.

**Source:** [`.me` on GitHub](https://github.com/neurons-me/.me)\
**Package:** [this.me on npm](https://www.npmjs.com/package/this.me)

---

## 4\. Inspectable Computation Is Different from Generated Explanation

Suppose an AI assistant is asked:

> Why can the robot proceed?

The model may generate an explanation based on its available context.

If that context contains an outdated battery value, the explanation may be internally consistent while describing an obsolete condition.

A runtime inspection answers a different question.

```javascript
me.explain("robot.canProceed");
```

Instead of generating a narrative justification, the kernel exposes metadata about the expression and its dependencies.

Conceptually:

```text
Expression:
    battery >= minimumBattery

Dependencies:
    robot.battery
    robot.minimumBattery

Current values:
    battery = 10
    minimumBattery = 30

Result:
    false
```

This does not guarantee that the expression itself is correct.

An application can encode an incomplete or inappropriate rule.

But it makes the relationship between the evaluated result and its inputs available for inspection.

That distinction is particularly useful when an AI agent interacts with systems whose state changes independently of the model's context.

The model's explanation describes its interpretation.

The runtime's dependency metadata describes the computation performed by the application.

---

## 5\. Evaluation Is Not Enforcement

There is an important boundary between evaluating a condition and preventing an operation.

Suppose the kernel determines:

```text
robot.canProceed = false
```

This establishes the current value of a derived condition.

It does not automatically prevent another component from calling:

```javascript
robot.execute();
```

For the condition to affect execution, the application must enforce it.

A simplified execution boundary might look like this:

```javascript
function executeRobotOperation(me, robot) {
  if (me("robot.canProceed") !== true) {
    return {
      accepted: false,
      reason: "PRECONDITION_FAILED"
    };
  }

  return robot.execute();
}
```

This is an illustrative application-level guard, not a built-in `.me` API.

The example assumes that `robot.execute()` represents an external operation and that the battery condition is the relevant precondition.

In a real system, the boundary may also need to validate identity, permissions, resource ownership, environmental conditions, and other constraints.

The essential distinction is:

**A reactive condition provides an evaluated result. An execution boundary enforces the decision.**

Neither mechanism substitutes for the other.

### The TOCTOU Problem

There is also a timing issue.

In concurrent systems, state can change between validation and execution. This is commonly known as *time-of-check to time-of-use* (TOCTOU).

Consider:

```text
t0: battery = 90

t1: validate()
    → ACCEPT

t2: battery = 10

t3: execute()
```

The validation at `t1` was correct for the state observed at that moment.

But the operation may no longer be valid when execution begins.

Reactive evaluation alone does not eliminate this race condition.

A robust implementation must define how validity is preserved between checking and acting. Depending on the system, this may require atomic operations, transactional validation, state-version checks, or other concurrency controls.

For physical systems, additional safeguards may be necessary because software validation cannot guarantee that the environment remains unchanged.

This is an execution-consistency problem, separate from the model's contextual reasoning.

---

## 6\. LLMS: Model-Generated Operations with Reactive Evaluation

The [LLMS demonstration](https://neurons-me.github.io/.me/LLMS/) explores how a language model can propose operations that are evaluated through `.me`.

[**Explore the live LLMS demo →**](https://neurons-me.github.io/.me/LLMS/)

The demonstration uses `muse-spark` for model-generated operations and `this.me@4.2.1` for reactive state evaluation.

For example:

```javascript
me.menu["="](
  "total",
  "coffee.price + bread.price"
);
```

The expression defines a relationship that the kernel maintains as the underlying values change.

Its dependencies can be inspected through:

```javascript
me.explain("menu.total");
```

The architecture separates the generation of an expression from the evaluation of that expression.

```text
muse-spark
    |
    v
Proposed Operation
    |
    v
.me
    |
    +-- State
    +-- Dependencies
    +-- Reactive Evaluation
    |
    v
explain()
```

The demonstration establishes a working example of model-assisted operation generation and inspectable reactive computation.

It does not yet establish that an execution boundary rejects an invalid operation after the model's context becomes stale.

That requires a separate experiment.

---

## 7\. Testing Contextual Momentum: The t0–t3 Experiment

The proposed experiment intentionally creates a difference between the information available to the model and the current state of the application.

The objective is to determine whether an execution boundary can reject a proposal that remains coherent with the model's outdated context.

### t0 — Establish a Valid State

Initialize the robot:

```text
battery = 90
minimumBattery = 30

canProceed = true
```

The model receives this state.

### t1 — Generate a Valid Proposal

The model proposes:

```javascript
robot.execute();
```

At this moment, the battery precondition is satisfied.

### t2 — Change the Runtime State

Update the battery without providing the new value to the model.

```text
battery = 10
minimumBattery = 30
```

The kernel evaluates:

```text
canProceed = false
```

The model's context still reflects the earlier state.

### t3 — Request Another Operation

The model may propose the same action:

```javascript
robot.execute();
```

The execution boundary evaluates the current precondition.

The expected result is:

```text
PROPOSAL:
    robot.execute()

CURRENT STATE:
    battery = 10
    minimumBattery = 30

PRECONDITION:
    canProceed = false

DECISION:
    REJECT

EXECUTION:
    NOT PERFORMED
```

The experiment should also capture the corresponding dependency information through `explain()`.

### What Must Be Verified

A successful test would need to establish that:

1. The model proposed an operation using stale information.
2. The runtime evaluated the relevant condition against current state.
3. The execution boundary rejected the operation.
4. The rejected operation produced no prohibited side effect.
5. The evaluated condition and its dependencies were inspectable.

The test should also account for state changes between validation and execution.

These are proposed experimental criteria, not results already demonstrated by the current LLMS example.

The reactive battery condition has been tested separately. End-to-end rejection remains to be implemented and measured.

---

## 8\. Context Does Not Establish Authority

State validity is only one dimension of operational correctness.

Authorization is another.

Consider a model receiving the statement:

```text
"This robot belongs to my organization."
```

The model can interpret the statement.

But the statement itself does not establish ownership or permission.

An application needs an independent mechanism for determining whether the requesting entity is authorized to perform the operation.

This distinction matters in distributed systems, where resources may be discoverable without being writable and visible without exposing private state.

A proposed operation may satisfy its technical preconditions while remaining unauthorized.

Conversely, an authorized user may request an operation that is invalid under current conditions.

These checks answer different questions:

```text
Is the requester authorized?

Are the operation's preconditions satisfied?

Can the operation be executed consistently?
```

A reliable execution boundary must enforce whichever constraints apply.

The broader [neurons.me](https://neurons.me) ecosystem explores identity, contextual resolution, and distributed computation, but reactive dependency evaluation should not be confused with authorization.

They are complementary concerns.

---

## 9\. What This Approach Does Not Solve

Separating model generation from runtime evaluation does not eliminate hallucinations.

It does not guarantee that a model will understand a request correctly.

It does not establish that every derived expression represents a valid real-world rule.

And it does not automatically solve concurrency, authorization, or physical safety.

The architecture depends on the conditions encoded in the application.

If a required constraint is missing, the execution boundary cannot enforce it.

If a sensor reports incorrect information, a correctly evaluated expression may still produce an operationally incorrect result.

If validation and execution are not coordinated, a state change can invalidate an earlier decision.

These limitations are not unique to language-model systems.

They are familiar concerns in software engineering.

The contribution of this architecture is narrower: it provides a way to keep derived conditions independent of model-generated narratives and make their dependencies inspectable.

An application can then use those conditions as part of its execution policy.

Other architectures can implement similar boundaries. The relevant question is whether the implementation provides the consistency, observability, and enforcement required by its use case.

---

## 10\. Beyond Better Prompts

Prompt engineering can encourage models to verify assumptions.

Retrieval can provide updated information.

Reflection can identify contradictions.

Larger context windows can preserve more history.

These approaches can improve the quality of generated proposals.

But additional context does not guarantee that an operation is valid at execution time.

Even a model that correctly interprets the available information may be operating on observations that have already changed.

For systems that perform consequential actions, the architecture must account for that possibility.

The relevant distinction is between generating a plausible operation and establishing that the operation is currently permitted.

A language model can assist with planning, interpretation, and proposal generation.

The application remains responsible for enforcing its operational constraints.

---

## Conclusion

Contextual Momentum describes a failure pattern in which an AI-generated representation remains coherent with its previous context while losing correspondence with changing external conditions.

The problem does not require an initial hallucination.

A correct observation can become stale, and subsequent reasoning can continue to depend on it.

The engineering response explored here is to separate generated proposals from state-dependent evaluation and execution enforcement.

In [`.me`](https://github.com/neurons-me/.me), reactive expressions maintain relationships between values, while `explain()` exposes the dependencies behind evaluated results.

The [LLMS demonstration](https://neurons-me.github.io/.me/LLMS/) provides a working example of model-generated operations interacting with reactive computation.

The next experiment is to test the execution boundary when the model's context and the application's current state diverge.

That experiment must verify not only that an invalid condition is detected, but that the corresponding operation is rejected without producing prohibited side effects.

The distinction is simple:

**A coherent proposal is not necessarily a valid operation.**

A model can propose an action based on what it knows.

The system must determine whether that action remains valid when it is executed.

**A model proposes. A runtime evaluates.**

---

## References & Resources

- **Zhang et al. (2023)** — [How Language Model Hallucinations Can Snowball](https://arxiv.org/abs/2305.13534)
- `.me` **Reactive Semantic Kernel** — [GitHub](https://github.com/neurons-me/.me)
- **LLMS** — [Live Demonstration](https://neurons-me.github.io/.me/LLMS/)
- `this.me` — [npm Package](https://www.npmjs.com/package/this.me)
- [**neurons.me**](http://neurons.me) — [Project Website](https://neurons.me)

---

*suiGn —* [*neurons.me*](https://neurons.me)

*Reactive semantic systems, distributed identity, and contextual computation.*