Problem
analyze_links_core in src/libsimlin/src/analysis.rs (around line 89) builds the link set from engine::db::model_causal_edges -- which is variable-level -- and reads each link's score series at slot 0 only. For an arrayed (A2A / cross-element) model, the engine computes per-element link scores (one per slot), but get_links collapses them to the variable-level edge and exposes only slot 0. The per-element link scores are not reachable through get_links.
The new GH #652 relative link scores are computed inside analyze_links_core over this same variable-level / slot-0 link set, so they inherit this limitation: relative scores are also variable-level slot-0 only for arrayed models. (#652 explicitly notes this is a separate, inherited gap.)
Why it matters
Capability gap for arrayed models. A user analyzing a model arrayed over (say) regions cannot see which element's link is important -- every region's link score is reported as the slot-0 value. The element-level data exists in the simulation slab; it is just not surfaced through the get_links FFI.
Components affected
src/libsimlin/src/analysis.rs (analyze_links_core, the variable-level edge construction + slot-0 read)src/libsimlin FFI get_links surfacesrc/pysimlin (Sim.get_links() / Link)
Possible approaches
A per-element get_links enhancement: expose the element subscript on each Link, and read the full per-slot score series (mirroring how the per-slot loop-partition / loop-score accessors already work). This composes with the #652 relative-link-score work -- the relative normalization would then run per (target, slot).
Severity
Low-medium (capability gap; arrayed models silently under-report link detail).
Relationship to #652
#652 adds relative link scores at the variable-level slot-0 surface; this issue is the orthogonal element-level dimension of get_links that #652 inherits.
Discovery context
Identified during an LTM-hardening session while reviewing analyze_links_core alongside the #652 relative-link-score work.
Part of epic #488.
Problem
analyze_links_coreinsrc/libsimlin/src/analysis.rs(around line 89) builds the link set fromengine::db::model_causal_edges-- which is variable-level -- and reads each link's score series at slot 0 only. For an arrayed (A2A / cross-element) model, the engine computes per-element link scores (one per slot), butget_linkscollapses them to the variable-level edge and exposes only slot 0. The per-element link scores are not reachable throughget_links.The new GH #652 relative link scores are computed inside
analyze_links_coreover this same variable-level / slot-0 link set, so they inherit this limitation: relative scores are also variable-level slot-0 only for arrayed models. (#652 explicitly notes this is a separate, inherited gap.)Why it matters
Capability gap for arrayed models. A user analyzing a model arrayed over (say) regions cannot see which element's link is important -- every region's link score is reported as the slot-0 value. The element-level data exists in the simulation slab; it is just not surfaced through the
get_linksFFI.Components affected
src/libsimlin/src/analysis.rs(analyze_links_core, the variable-level edge construction + slot-0 read)src/libsimlinFFIget_linkssurfacesrc/pysimlin(Sim.get_links()/Link)Possible approaches
A per-element
get_linksenhancement: expose the element subscript on eachLink, and read the full per-slot score series (mirroring how the per-slot loop-partition / loop-score accessors already work). This composes with the #652 relative-link-score work -- the relative normalization would then run per (target, slot).Severity
Low-medium (capability gap; arrayed models silently under-report link detail).
Relationship to #652
#652 adds relative link scores at the variable-level slot-0 surface; this issue is the orthogonal element-level dimension of
get_linksthat #652 inherits.Discovery context
Identified during an LTM-hardening session while reviewing
analyze_links_corealongside the #652 relative-link-score work.Part of epic #488.