Observer trajectory lives on an ENVIRONMENT SLOT, so containers cannot carry it: dict fields, list elements and function parameters have no history

[InauguralPhysicist]

Found by phugoid rung 4 (the N-aircraft swarm), 2026-08-26, eigenscript v0.41.0.

This body has been rewritten twice. The original claimed a runtime-sized population "cannot be observed per-aircraft at all"; the first correction weakened that to "only a lexical name, so it forces eval-generated source". Both were false — each was a negative claim published after a non-exhaustive search. eval works, and so do closures. The accurate statement is below, and it is a claim about the mechanism rather than an enumeration of what I happened to try. See the correction comments for the history.

The mechanism

Observer trajectory is keyed to an environment slot — env_obs_slot(Env *e, int idx) returns e->obs[idx] (src/eigenscript.h:1352), and the header says so directly at line 346: "The Value carries no observer state."

So a per-entity observer channel requires a persistent environment slot per entity. That is the whole rule, and it predicts every case:

form	persistent env slot?	trajectory
distinct named locals	yes	works
closure captured local (one factory call per entity)	yes	works, N chosen at runtime
eval-generated names	yes	works, N chosen at runtime
dict field ch.a	no — a Value in a container	equilibrium, no history
list element xs[0]	no — a Value in a container	equilibrium, no history
function parameter	slot exists but the frame dies each call	equilibrium, no history

Closures, verified with N from argv:

define make_ch as:
    local q is 0.0
    define step(v) as:
        q is v
        return report of q
    return step

$ eigenscript g8.eigs 6
closure channels (n=6 from argv): ["moving","oscillating","moving","oscillating","moving","oscillating"]

Alternating decaying/oscillating trajectories, correct per-channel verdicts, ordinary static source that lints normally.

What the actual gap is

Containers cannot carry observer state, so per-entity observation cannot be expressed the way a consumer would naturally reach for it — a fleet is a list, a registry is a dict, and neither can be observed element-wise. The available forms all require one binding per entity: a named local, or a closures captured local.

That is a real ergonomic gap and it has a sharp failure mode: the obvious loop

loop while i < n:
    local q is fleet[i][2]        # ONE binding, rebound N times
    if diverging of q: ...

does not merely lose resolution, it manufactures verdicts — the window becomes the round-robin interleave, so a monotonically decaying trajectory reads oscillating:

shared binding : a-verdict=oscillating   b-verdict=oscillating
named bindings : a-verdict=moving        b-verdict=oscillating

That is silent-wrong with no diagnostic, and it is what rung 4s own first draft shipped in every arm.

The ask, unchanged and now correctly weighted

Make dict-field and list-element assignment carry trajectory keyed by (container identity, key). With closures available this is convenience rather than necessity — but it is the form consumers reach for first, and the alternative failure is silent rather than loud.

A secondary and cheaper mitigation: make the interleaved-binding case detectable. A binding whose observed values jump between unrelated trajectories is a bug in every case I can construct, and the observer has the history to notice.

[InauguralPhysicist]

Correction from the reporter, and it weakens this issue substantially. Posting before anyone acts on it.

What I got wrong

The body says "the number of observable channels is fixed at authoring time", "that program cannot be written correctly today", and lists exactly two workarounds. There is a third, and it works. eval synthesizes named bindings at runtime, and those bindings carry observer trajectory exactly like hand-written ones:

NCH is 4                       # runtime value
decl is ""
k is 0
loop while k < NCH:
    decl is decl + "ch" + (str of k) + " is 0.0\n"
    k is k + 1
eval of decl                   # synthesizes ch0..ch3 as real named bindings

Driving four channels — two monotonically decaying, two oscillating — and reading each:

  ch0 -> moving        ch1 -> oscillating
  ch2 -> moving        ch3 -> oscillating

Correct per-channel verdicts, with N chosen at runtime, through the real predicate lattice — not a userland re-implementation. The generated define can be evald once at startup, so the hot loop is a plain compiled call and pays no eval cost. A blind review of my own consumer reproduced this at N=32 with per-aircraft counts that track each aircrafts amplitude, matching my own run_solo oracle exactly at N=4.

So "cannot be written correctly" is false and I should not have written it. A negative claim needs an exhaustive search of the alternatives; I tried four addressing forms, found them all dead, and stopped.

What still stands, re-verified

• Only a named binding carries trajectory. Dict fields, list elements and function parameters all report equilibrium — the table in the body reproduces exactly, and I have since re-confirmed it independently.
• A shared binding manufactures verdicts: the window becomes the round-robin interleave, so a monotonically decaying trajectory reads oscillating. That is the silent-wrong that motivated the report and it is unchanged.

The corrected ask

Not "make the impossible possible" but: the only addressable channel is a lexical name, so a runtime-sized population forces a program to generate its own source. That is a real ergonomic and safety gap — a consumer wanting per-entity observation must build strings and eval them, losing lint, static checking and any hope of the AOT compiling it — but it is a much weaker claim than the one I filed, and it should be prioritised as such.

The concrete request stands unchanged and is the cheap fix: make dict-field and list-element assignment carry trajectory keyed by (container identity, key). That is what a consumer reaches for first, and it would remove the need to generate source.

Apologies for the churn. Consumer-side ledger and the rungs own write-up are being corrected in the same pass.

[InauguralPhysicist]

Third correction, and the body is now rewritten rather than annotated — a reader hitting the title or body was still getting the false version, which is on me.

The previous correction was also a non-exhaustive negative claim. It said the only addressable channel is a lexical name, so a runtime-sized population "forces a program to generate its own source", costing lint, static checking and AOT. A closure does it with none of that:

$ eigenscript g8.eigs 6
closure channels (n=6 from argv): ["moving","oscillating","moving","oscillating","moving","oscillating"]
$ eigenscript --lint g8.eigs
no issues found            # ordinary static source; the eval form lints clean while hiding everything

Each factory call creates a fresh Env, so its captured local is its own slot. Graded against the consumers own per-entity oracle at N=32, zero mismatches, non-degenerate counts.

That is three rounds in which I published a "cannot" after testing a handful of forms. The body now states the mechanism — trajectory is keyed to an environment slot (env_obs_slot, src/eigenscript.h:1352; "The Value carries no observer state", line 346) — from which every case follows, instead of an enumeration that keeps acquiring exceptions.

[InauguralPhysicist]

One more row for the table, found while testing the mechanism claim — and it is the row a consumer is most likely to hit.

A for-body local carries no trajectory; a loop while-body local does.

form	persistent env slot?	trajectory
for x in xs: body local	fresh env per iteration	none
loop while body local	one env, persists	works — and INTERLEAVES if it reads several entities

Both follow from the slot keying in the body, but the asymmetry is nasty in practice, because the two loops read as interchangeable and the failure modes are opposite:

• write the per-entity read in a for body and every verdict is equilibrium — the observer says nothing, loudly enough to notice;
• write the same thing in a loop while body and the single binding accumulates the round-robin interleave — the observer says something confident and wrong, which is the silent-wrong this issue is about.

Rung 4 hit the second form. A consumer refactoring loop while to for (or the reverse) changes which of those two they get, with no diagnostic either way.