Problem
PROPERTY_MAPPING (with allowed_values and strict_validation) gives feature groups a declarative way to define option value spaces, validated at matching time. There is no declarative counterpart for controlled vocabularies of values inside columns: data-value checks live in imperative per-feature-group hooks (validate_input_features, validate_output_features, BaseValidator).
This asymmetry invites a design mistake. When modeling a domain semantic layer (closed vocabularies for what a column may contain), it looks natural to encode those vocabularies as option value spaces on feature group classes. That validates the wrong thing at the wrong time: options describe how to compute a feature and are checked when a feature request is matched, while data vocabularies describe row values and must be checked when data flows through. Nothing in the docs or the pattern guides says this directly.
Suggestion
- Docs: a short pattern page on where domain vocabularies and semantic contracts should live relative to feature groups. Recommended shape: a plain, dependency-free contract module that declares vocabularies and field catalogs, from which feature groups derive their feature surface. Feature groups then enforce the contract as edges in the graph but do not declare data schemas, and the contract stays importable by tooling that cannot depend on mloda.
- Optional, larger: a declarative mechanism for column-value vocabularies analogous to
allowed_values, for example a per-column allowed-values declaration that a default validate_output_features enforces.
The docs page alone would resolve the confusion in one read.
Problem
PROPERTY_MAPPING(withallowed_valuesandstrict_validation) gives feature groups a declarative way to define option value spaces, validated at matching time. There is no declarative counterpart for controlled vocabularies of values inside columns: data-value checks live in imperative per-feature-group hooks (validate_input_features,validate_output_features,BaseValidator).This asymmetry invites a design mistake. When modeling a domain semantic layer (closed vocabularies for what a column may contain), it looks natural to encode those vocabularies as option value spaces on feature group classes. That validates the wrong thing at the wrong time: options describe how to compute a feature and are checked when a feature request is matched, while data vocabularies describe row values and must be checked when data flows through. Nothing in the docs or the pattern guides says this directly.
Suggestion
allowed_values, for example a per-column allowed-values declaration that a defaultvalidate_output_featuresenforces.The docs page alone would resolve the confusion in one read.