Module controller_adapter 

Mechanical derivation of ControllerManifests from a thin host-controller descriptor — the dag-ml side of the OperatorController -> ControllerManifest adapter (DEC-CTRL-001 / the “B1” adapter).

Why this lives in the core

Today every host hand-authors a static array of manifest literals (the nirs4all bridge’s controller_manifests() ships five) and Studio rebuilds a parallel node registry by walking importable Python classes. Both encode, by hand, the per-kind facts that are actually deterministic — the “Inferable” rows of the controller-adapter spec: a model node supports FIT_CV/REFIT/PREDICT, fits per fold, emits a prediction and an artifact port; a transform maps x -> x_out; and so on. Encoding those facts once, natively, means every binding (Python / R / WASM / cluster) derives the same validated manifest for free instead of re-deriving — or drifting from — them.

The two-layer projection

An OperatorController.matches() predicate mixes two independent routing dimensions that project to different places:

1. keyword / DSL position -> operator_kind (“Layer 1”). This is a compile-time lowering rule owned by the DSL compiler, not a manifest field; by the time a manifest is derived the host already knows the NodeKind, so it is an input here. Given that kind, this module fills in the mechanical defaults via manifest_kind_template.
2. operator class / type -> operator_selectors (“Layer 2”). These are supplied verbatim by the host as OperatorSelectors (the existing selector vocabulary) and are how a specialization manifest (e.g. a native PLS controller) out-ranks a generic kind-level catch-all.

This module invents no new capability/policy vocabulary: a derived manifest is an ordinary ControllerManifest over the existing ControllerCapability / ControllerFitScope / RngPolicy / ArtifactPolicy enums, and every derivation is run through ControllerManifest::validate before it is returned, so it can never produce a manifest the registry would reject.

Structs

HostControllerSpec

Host-side description of one OperatorController, the input from which a validated ControllerManifest is mechanically derived.

ManifestKindTemplate

The mechanical, per-NodeKind portion of a ControllerManifest: the fields a host does not need to author because they follow deterministically from the node kind. HostControllerSpec::derive composes one of these with the host-supplied identity/selectors/overrides.

Constants

REPRESENTATION_TABULAR_NUMERIC

Frozen representation id for a generic numeric feature table — the modality-neutral default stamped on data ports of a derived manifest. Published by the dag-ml-data representation registry (docs/contracts/representation_registry.v1.json, registry id dag-ml-data.representation_registry.v1, type_id = "table").

REPRESENTATION_TARGET_NUMERIC

Frozen representation id for a generic numeric target — the modality-neutral default stamped on target ports of a derived manifest. Published by the same registry (type_id = "target"). This replaces the previous coarse behaviour that (incorrectly) stamped the feature-table id on target ports.

Functions

derive_host_controller_registry

Derive every spec and register the manifests into a fresh ControllerRegistry, surfacing the first derivation or duplicate-id error. This is the one call a runtime needs to turn its declared host controllers into a resolvable registry — the replacement for a hardcoded static node registry.

manifest_kind_template

Return the deterministic manifest defaults for kind.

representation_type_id

Return the frozen type_id registered for representation_id, or None when the id is outside the mirrored registry subset ([FROZEN_REPRESENTATION_TYPES]). Hosts use this to type a port while building an explicit data_requirements override; the adapter uses it to synthesize the default one.