nirs4all.pipeline.dagml.resolver module

Materialization resolver — the mechanism-agnostic real-data fetch.

dag-ml’s control core never sees feature matrices; it asks a host for the rows of a view, keyed by stable identity. This resolver is the single object both execution mechanisms call (the CLI process-adapter deserializes wire ids from a NodeTask; an in-process C-ABI callback hands them as a Python list) — it takes only JSON-friendly identity refs and returns plain Python values, so it carries zero FFI.

It is the real sample_id → X/y fetch that the shipped conformance adapters fake (they synthesize features by hashing sample ids). Two correctness invariants, both verified against the live SpectroDataset:

• Order is the caller’s request, by identity. Features are fetched with SpectroDataset.x_rows(), which addresses each stored row by its own sample int (base or augmented) and returns rows in request order — identity-keyed, never positional. (The base-keyed x path expands base→augmented and returns ascending storage order, dropping augmented-only ids; x_rows is the observation-grain read.)

• Real spectra, not a hash. Values come from SpectroDataset.x_rows/.y.

Augmented rows are observation-grain: a train view’s observation_ids may include augmented children; a validation/predict view (include_augmented=False) must not — the resolver refuses an augmented child in such a view (the origin-boundary leakage guard at the host boundary, mirroring exclude’s include_excluded discipline). A child’s target is its origin’s y, so resolve_targets is keyed by the origin’s sample_id (a base id).