ltm: scalar module output feeding an arrayed reader emits a single scalar constant-0 link score, dropping all arrayed loops through modules #716

Summary

A SCALAR module output feeding an ARRAYED reader gets its input -> module (really module-output -> arrayed-reader) link score emitted as a single scalar $⁚ltm⁚link_score⁚{m}→{growth} variable that evaluates to a constant 0. There are NO per-target-element $⁚ltm⁚link_score⁚{m}→{growth}[{elem}] variables. As a result, every arrayed feedback loop that runs through a module is dropped by LTM discovery (the loop product is 0, so the loop never forms) and mis-scored in exhaustive mode. This is an arrayed-link-score emission gap for the module-output-as-source case, not a settled equilibrium.

Empirical evidence

Probed on an arrayed fixture: arrayed stock s[Region]; a scalar multi-output module m (pos/neg producer); per-element reader growth[Region] = f(m·pos); loop closes s[e] -> m -> growth[e] -> s[e].

• The element-level causal graph correctly carries the subscripted edges (s[nyc] -> m, s[boston] -> m; exit reader growth[nyc]).
• But the m -> growth link score is emitted as a single scalar $⁚ltm⁚link_score⁚m→growth whose value is constant 0. There are NO $⁚ltm⁚link_score⁚m→growth[nyc] per-element variables.
• The module internals are demonstrably alive (m·$⁚ltm⁚composite⁚input_val = -1, internal input_val→pos = +1, input_val→neg = -1), so the 0 is an emission gap, not an equilibrium.
• Consequence: discovery returns loops: [] for the arrayed loop s[e] -> m -> growth[e] -> s[e]. The per-exit-port recompute (the GH ltm: discovery mode can report the wrong loop polarity (sign error) through a multi-output module #698 family, PR ltm: discovery-mode correctness fixes from deep review #705) can never apply to arrayed loops through a module because they never form.

Root cause direction

Ordinary scalar-source -> arrayed-target edges get per-target-element link scores via try_scalar_to_arrayed_link_scores (src/simlin-engine/src/db/ltm/link_scores.rs), named $⁚ltm⁚link_score⁚{from}→{to}[{elem}]. But the module-output-as-source case takes a different path: module-involved links are built by module_link_score_equation (src/simlin-engine/src/db.rs ~line 580 / the dispatch at ~756-778) and its per-shape twin in src/simlin-engine/src/db/ltm/compile.rs, which produce a single scalar LtmSyntheticVar with dimensions: vec![]. So a module-output -> arrayed-reader edge never reaches the per-target-element emission that an ordinary scalar -> arrayed edge does.

Likely fix: route module-output -> arrayed-reader links through the per-target-element emission (mirroring try_scalar_to_arrayed_link_scores), emitting one $⁚ltm⁚link_score⁚{m}→{to}[{elem}] per reader element, so the arrayed loop product is per-element and the loops form. The discovery parser specifically needs the element on the to side (a single Bare-A2A var would be undiscoverable, the same reasoning that motivated try_scalar_to_arrayed_link_scores putting the element on to).

Why it matters

Correctness/completeness. Any model with an arrayed reader of a module output (a common shape -- a scalar policy/macro feeding per-region dynamics) silently loses its entire arrayed feedback-loop class through the module, with no diagnostic. The modeler sees loops: [] (or a loop list missing the module loops) and is taught the wrong mental model ("no feedback here"). Discovery is also the regime large/auto-flipped models fall into, so this bites exactly where it is least visible.

Distinct from existing tracking

• ltm-finding: discovery mode silently drops ALL cross-element (cross-agg) reducer loops #696 (discovery silently drops cross-element/cross-agg reducer loops): the dropped loops there traverse a hoisted $⁚ltm⁚agg⁚{n} node and the drop is a DFS visiting-set reachability problem; link scores are present and non-zero. Here the source is a module, the link score is absent per-element / constant-0, and the drop is an emission gap. Different node kind, different root cause.
• ltm: discovery mode can report the wrong loop polarity (sign error) through a multi-output module #698 (discovery reports wrong loop polarity through a multi-output module): same fixture shape (pos/neg multi-output submodel), but ltm: discovery mode can report the wrong loop polarity (sign error) through a multi-output module #698 is about a present, non-zero scalar link score getting the wrong sign in a scalar loop. Here the arrayed loop never forms at all because the link score is constant-0 and not emitted per-element. Sign-of-a-present-score vs absence-of-a-score.
• ltm: a generated reference to an absent cross-module LTM variable compiles cleanly and reads a silent constant 0 #683 (generated reference to an absent cross-module LTM var reads constant-0): about composite references to passthrough modules that expose no composite. Same silent-zero hazard family, but a different root cause (absent composite reference vs scalar-instead-of-per-element emission of a module link score that does exist scalar-ly).
• libsimlin: get_links is variable-level / slot-0 only for arrayed models #665 (get_links is variable-level / slot-0 only for arrayed models): an FFI surfacing limitation on top of correctly-computed per-element scores. Here the per-element scores are never emitted in the first place.

Components affected

• src/simlin-engine/src/db.rs (module_link_score_equation, the module-involved link dispatch at ~756-778)
• src/simlin-engine/src/db/ltm/compile.rs (link_score_equation_text_shaped, the per-shape module twin)
• src/simlin-engine/src/db/ltm/link_scores.rs (try_scalar_to_arrayed_link_scores -- the per-target-element emission the module path should mirror; emit_link_scores_for_edge dispatch)
• Downstream: src/simlin-engine/src/ltm_finding.rs (discovery, the arrayed loop never forms), exhaustive loop-score builder (mis-scored loop product)

Secondary observation (possibly distinct)

Feeding a scalar module input from an arrayed source (src "s") or a single element (src "s[nyc]") fails to compile with failed to compile fragments for variables: m, m, m. This is the mirror direction (arrayed/element-as-source into a scalar module input) and may be a separate validation/compile gap rather than an LTM-emission gap; noting it here for context. If it proves orthogonal during the fix, it warrants its own issue.

Discovery context

Empirically discovered during PR #705 review follow-up (LTM implementer), 2026-06-03, via probes on the arrayed pos/neg-module fixture described above. Part of LTM tracking epic #488. Related discussion: PR #705 review thread r3353758167.