Context as variable vs addressable context

Verdict

Related, but not the same concept. Prime Intellect’s RLM work makes a large input computable: the root model gets a REPL in which the input is bound as a variable, then iteratively searches, slices, aggregates, and asks sub-models about selected observations. fak’s existing addressable-context work makes context identifiable and governable: bytes have stable references, can be paged, screened, pinned, and materialized into bounded resident views while preserving cache economics.

The clean composition is:

addressable source pages -> governed query operators -> derived context views -> model-visible resident set

A memory address answers where/which bytes? A variable answers what can the program do with them? A view answers which bounded derivation is visible now? The new learning is the middle query/derivation plane, not a rename of fak’s current page identity.

For public fak vocabulary, prefer queryable context for the capability and derived context view for each result. “Context as variable” is a useful RLM teaching metaphor, but variable suggests mutable aliasing and arbitrary code; those are the wrong default contracts for a content-addressed, default-deny kernel.

Source pin and study scope

This is a concept-and-seam study, not a benchmark reproduction. No Prime code is copied. The implementation changed rapidly around the study date, so the revision above, not main, is the authority for source claims.

What the source actually does

At the studied seam, the RLM harness supplies an interactive execution workspace around the root-model rollout. The accompanying system prompt tells the model that the large input is available through an environment variable rather than requiring the whole input to be reasoned over in one forward pass. The model can inspect pieces, compute intermediate state, and call an LLM over selected material before returning a final answer.

The important mechanism is not Python specifically. It is this loop:

  1. Keep the large source outside the root model’s immediate visible prompt.
  2. Give the model operations over a stable source binding.
  3. Let it form small observations and intermediate products.
  4. Spend model tokens on those products, not indiscriminately on all source bytes.
  5. Repeat until an answer condition is met.

Oolong supplies tasks where long-input aggregation matters, which is why simple semantic retrieval is an incomplete baseline: a query may need counts, grouping, joins, ordering, or exhaustive scans rather than the one most similar chunk.

Relation to fak’s current concepts

Plane RLM “context as variable” Existing fak seam Assessment
Identity one environment binding points at the task input abi.Ref, CAS-backed page-out, content hashes, context restore IDs fak is stronger; identity is durable and governable
Access model-directed REPL inspection page fault / page-in, pins, resident-set planning partial overlap; fak controls access but exposes less agent-directed derivation
Transformation arbitrary code can slice, filter, aggregate, and retain intermediates context-plan/view documents specify bounded selection and materialization conceptual overlap, missing one small public query algebra
Visibility only printed/tool-returned observations enter the root rollout bounded resident views and prompt transforms same direction; fak additionally screens admission
Recursion model may call another LLM over a selected observation fak routes model/tool calls but does not yet make recursive context analysis the primitive adjacent, not required for the first spine
Governance container/tool policy bounds execution default-deny adjudication, quarantine, provenance, budgets fak should preserve its stronger structural floor
Cache economics source stays out of repeated root prompts, but observations still accrue stable prefixes, generation cache, planned resident views fak can make the composition explicit and measurable

Current local authorities:

Therefore “context as variable” is not a replacement name for addressable context. It is a useful behavioral layer that addressable context can safely support.

Vocabulary map

Term Keep? Precise meaning in fak
addressable context yes immutable or versioned source bytes have a stable identity/ref
context as variable source term only model can compute over a named large input without seeing it all at once
queryable context recommended capability name bounded operators derive observations from governed source refs
derived context view recommended result name immutable, provenance-stamped output of one query over source refs
context program yes policy/plan selecting queries, budgets, and materialization over turns
context workspace optional UX term task-scoped namespace containing source refs and derived views
agentic search broader adjacent term model chooses iterative searches; often retrieval-oriented and not necessarily exhaustive
recursive language model (RLM) source architecture root LM delegates computation/inspection and may invoke sub-LMs recursively
virtual context / context MMU yes, lower plane paging, residency, protection, and restoration mechanics

“Queryable” is preferable to “programmable” for the first fak spine: it commits to deterministic, inspectable operators, not general-purpose execution. “Derived view” is preferable to “variable value”: it carries source lineage and immutability naturally.

Candidate borrows, with disconfirming checks

1. A bounded query algebra over context refs — survive

2. Arbitrary Python REPL inside fak — reject

3. Recursive sub-model calls as the first spine — defer

4. Aggregation-first evaluation — bind to candidate 1

Minimal working spine

Primary problem: P1 (context limits), with P2 measurement as a witness.

Safety needed in the spine: operator allowlist, source/output byte and record limits, deterministic ordering, timeout/work budget, provenance, quarantine inheritance, and fail-closed handling of malformed plans. Arbitrary eval, network access, mutation, and recursive model calls are explicitly out.

Net-true hypothesis (not yet a gain claim)

The candidate should be kept only if, on an aggregation task, it preserves the exact answer while reducing model-visible bytes versus the real alternative of materializing the whole already-addressed source. Query CPU time, index/build cost, stored derived bytes, and any extra model calls belong in the denominator. Until that paired witness exists, this note claims a conceptual gap, not a performance or quality win.

Registration

This study is registered by its dated note and the surviving candidate filed as #6518. INDEX.md was intentionally not edited in this shared checkout because it already contained peer-owned uncommitted changes; the issue links this note as the durable reverse route.

Concrete meaning: what is “context as a variable”? (clarification 2026-08-12)

It means the long input is data in an execution environment, referenced by a name, rather than text that must all be visible inside every model forward pass.

A simplified interaction looks like this:

execution environment:
    context -> <the complete 500,000-token source>   # outside the LM prompt

model-visible turn:
    "The source is available as `context`. Use bounded operations to answer."

model action:
    count(group(filter(context, status == "failed"), owner))

next model-visible observation:
    {"alice": 19, "bob": 7}                         # only this result enters

The name is not magical and it is not a neural-network variable. It is closer to a read-only database relation, file handle, array, or lazy collection in a tool runtime. The LM writes a small program/query against it. The runtime executes that operation over the complete source and returns a bounded observation. The LM can repeat this loop, keep intermediate derived values, or ask another model to interpret one selected value.

That changes the scaling shape: the model no longer needs all source tokens in its attention window at once, although the external runtime still must read or index the source and the returned observations still consume context. It also does not guarantee correctness: the model can write a bad query, omit needed records, or accumulate too many observations. This is why fak should expose a small typed query algebra, provenance, limits, and exact aggregation witnesses rather than unrestricted eval.

In fak terms:

"context"                  = optional workspace binding (#6524)
abi.Ref / content hash      = addressable source identity (existing)
filter/group/count plan     = queryable-context operation (#6518)
derived immutable result   = derived context view (#6518)
reused result              = materialized/memoized view (#6525)
why/how/replay              = derivation explanation (#6528)
quality/cost counterfactual = aggregation evaluation (#6526)
helper-model interpretation = governed later recursion (#6527)

So “context as a variable” is the programming-interface metaphor; “queryable context over addressable sources” is the more precise fak system contract.

Filed follow-on graph

The surviving opportunities are now tracked rather than deferred in prose:

Dependency order: #6518 -> {#6524, #6525, #6526, #6528} -> #6527.

Is this “just lazy load”? Page/cache/filter/call clarification (2026-08-12)

Partly, but “lazy load” names only one transition. “Context as a variable” combines an ergonomic binding with a demand-driven dataflow. A correct implementation must not collapse the following stages:

Stage Input -> output Does it create new semantic bytes? Typical cache/identity
bind name -> immutable source/view identity no workspace manifest / resolver
page/fetch nonresident ref -> the same source bytes resident no CAS/blob/page cache
filter/query source ref + canonical plan -> derived view yes derived/materialized-view cache
admit resident source/view -> model-visible prompt view no semantic derivation, but serialization may change resident/prompt plan; provider KV cache is downstream
call recipe -> call-result snapshot yes, and may have effects idempotency/call-outcome cache, then result blob/page cache
refresh old call snapshot -> new explicitly requested snapshot yes never an implicit page fault

A binding should therefore be lazy/inert by default: creating or listing it performs no source read, query, call, or prompt admission. A later demand names which operation is required. Metadata demand may need no bytes. Source demand may page in existing bytes. Query demand may page source bytes and compute a new immutable derived view. Prompt demand separately admits selected bytes.

Relation to fak’s existing MMU and context-plan machinery

This is intentionally a layer over existing mechanisms, not a parallel paging system:

The missing first-class contract is to connect a human/task-scoped name to those fetch/materialize/admit stages with exact identities, independent budgets, and observable reasons. #6531 tracks that integration.

Filtering and caching apply to variables—but at the right identity

A filter does not mutate tickets. It creates a new immutable view, for example:

tickets                       -> source snapshot hash S1
failed = filter(tickets, ...) -> view hash V1, lineage (S1, plan P1)

failed may itself be named, paged out, queried again, admitted, shared, or evicted. Its cache key must include the complete source snapshot(s), canonical plan/operator version, policy/taint identity, and output bounds. Caching only by the alias failed is incorrect because aliases can be rebound. This is the materialized-view contract in #6525.

Several caches remain deliberately distinct:

Cache Reuses Must not be confused with
page/blob cache exact existing source or view bytes query-result correctness
plan cache selection/planning decision materialized result bytes
derived-view cache source snapshot + query semantics -> immutable view alias name or provider KV
call/idempotency cache witnessed execution outcome for a canonical call recipe/scope paging an existing result
provider KV/prefix cache model computation for stable serialized prefix source truth or tool-result cache

Relation to calls

A tool/model call can produce a large result that becomes addressable context, but dereferencing a variable must not silently reissue the call. The safe model is:

call recipe R1 --explicit execution--> call snapshot C1 -> result ref S1
tickets@rev7 -------------------------------------------> S1

Reading, paging, filtering, or admitting tickets@rev7 uses S1 and executes zero calls. An explicit refresh adjudicates R1 again, possibly reuses a witnessed idempotent outcome, and creates C2/S2 plus a new binding revision. Only a structurally proven read-only recipe may be deferred until first demand; effectful calls can never hide behind lazy dereference. This is tracked in #6532.

First-class naming model

Human aliases and machine identities serve different purposes:

human alias:       tickets
qualified binding task-42@7:tickets
kind:              call_snapshot
immutable target:  sha256:S1
resolved record:   workspace rev + alias + kind + S1 + policy/taint

Every operation resolves the alias to an exact target before fetch/query/call, and provenance/cache keys use that target—not tickets or an unresolved latest. #6533 tracks the shared naming and conformance contract.

The resulting architecture is:

#6533 names/identity
       |
#6524 workspace bindings
       |
#6531 demand lifecycle: bind -> fetch -> materialize -> admit
       |                 |          |
       |              ctxmmu     #6518 query
       |                            |
       |                         #6525 view cache
       |                            |
       +------------------------- #6528 explain/replay
       |
#6532 explicit call snapshot/refresh (never implicit on read)
       |
#6526 exact aggregation counterfactual -> #6527 optional helper model

Canonical reader-facing explainer

The maintained conceptual route is docs/explainers/context-as-a-variable.md. Use that page for the binding, lazy-load, filtering, cache-tier, call-snapshot, and implementation-order model. This dated note remains the pinned-source research trail and candidate analysis.