ADR-0001 — nirs4all connector ownership¶
Status: Accepted
Date: 2026-05-28
Tags:
connectors,nirs4all,nirs4all-io,scope,phase-2-gate
Context¶
Three documents currently claim ownership of the bridge between
nirs4all’s SpectroDataset and dag-ml-data’s
CoordinatorDataPlanEnvelope:
dag-ml-data/docs/ROADMAP.mdPhase 4 “nirs4all Connector” — declares aSpectroDatasetconnector, dense signal representations and compatibility tests as part ofdag-ml-data.nirs4all-io/docs/REDESIGN_FORMATS_AND_IO.mdAppendix I — describesnirs4all-ioas the dataset-assembly bridge that materializesSpectroDatasetfrom heterogeneous inputs and ultimately produces aCoordinatorDataPlanEnvelope.dag-ml/docs/design/source/dag_ml_synthese.md— refers todag-ml-dataenvelopes as the host-emitted contract thatdag-mlconsumes.
nirs4all-io/docs/PHASE2_GATE.md item 7 records the resulting blocker:
nobody knows who owns the conversion, so the connector is not buildable.
dag-ml-data’s AGENTS.md is unambiguous on what dag-ml-data does NOT
do: “Do not add NIRS-specific assumptions to core types.” A
SpectroDataset connector that inspects NIRS-specific axes, source
descriptors or signal types would be exactly that violation.
Decision¶
nirs4all-io owns the bridge.
nirs4all-iois the only crate allowed to consumeSpectroDatasetand emit aCoordinatorDataPlanEnvelope. It depends ondag-ml-datafor the envelope shape; it does not modifydag-ml-data’s core types.dag-ml-dataaccepts io-emitted envelopes through the existing C ABI and JSON surfaces. It treats them as opaque, schema-validated contract artifacts — no NIRS-specific code paths, noSpectroDatasetawareness.dag-ml-dataROADMAP Phase 4 is descoped. The “nirs4all connector” bullet is reclassified as out-of-scope fordag-ml-dataand moved intonirs4all-io’s Phase 2 deliverables.dag-mlcontinues to consume envelopes through itsdag-ml-dataC ABI binding without knowing aboutnirs4all.
Consequences¶
Positive¶
dag-ml-dataretains its NIRS-agnostic invariant. Every other ML domain (omics, audio, time series, finance) can target the same envelope contract without seeing spectroscopy-shaped APIs.nirs4all-iobecomes the natural home forSpectroDataset-aware knowledge: signal types, repetition handling, augmentation origin, fold layout. That knowledge already exists there.The PHASE2_GATE blocker is removed:
nirs4all-iocan implement the bridge against the (now public)dag-ml-datacontract surface without coordination ondag-ml-datacore changes.
Negative / mitigations¶
nirs4all-iocarries the maintenance burden of cross-crate version alignment withdag-ml-data. Mitigation: the existingscripts/validate_contracts.pyruns against the published envelope schema digest in both repos, catching wire-shape drift before it reachesnirs4all-io.A NIRS-specific axis kind that has no parallel in other domains would still need a
dag-ml-datacore change to be representable. This ADR does not block such changes — it forbidsnirs4all-io-specific business logic from leaking intodag-ml-data. TheAxisKind::Wavenumberaddition shipped alongside this ADR is the canonical example: it’s a generic spectroscopy axis (used in IR spectroscopy, Raman, etc.), not aSpectroDatasetrepresentation detail, so it belongs in core.
Implementation notes¶
This ADR is paired with:
AxisKind::Wavenumberadded tocrates/dag-ml-data-core/src/model.rs— closes the structural blocker onPHASE2_GATEitem 2 (cm⁻¹axis missing for IR/Raman spectroscopy).docs/ROADMAP.mdPhase 4 status updated to “descoped, owned bynirs4all-io”.
No dag-ml-data API change beyond AxisKind::Wavenumber. No
dag-ml change required. nirs4all-io should reference this ADR in
its own Phase 2 design when picking up the bridge.
References¶
dag-ml-data/AGENTS.md—dag-ml-databoundary (do not add NIRS-specific assumptions).nirs4all-io/docs/REDESIGN_FORMATS_AND_IO.mdAppendix I — bridge scope.nirs4all-io/docs/PHASE2_GATE.mditem 7 — blocker this ADR resolves.dag-ml-data/docs/contracts/coordinator_data_plan_envelope.schema.json— the v1 envelope contractnirs4all-iotargets.