Type-hint parameter validation

Parameters in Kedro come out of YAML, which means they arrive as nested dictionaries with no structure and no guarantees. A typo in a config key, a string where a float belongs, a missing nested field: all of it surfaces as an AttributeError or aKeyError partway through a run that may already have written outputs.

Meanwhile, a lot of people already annotate their node functions. The information needed to catch these mistakes was sitting in the codebase, unused.

What it does

If a node function's parameter is annotated with a Pydantic model or a dataclass, Kedro builds an instance of that model from the raw config and hands the node a validated, typed object instead of a dictionary. If it is annotated with anything else, or not annotated at all, nothing happens. That last property was non-negotiable. This had to be invisible to every existing project.

Delivered as six pull requests

The subsystem is roughly 525 lines of source, and I could have opened one pull request for all of it. Nobody reviews that properly. Instead it went in as six, each independently reviewable and each leaving the codebase working:

• Exceptions and Pydantic utilities. The error types and the helpers everything else builds on.
• Model factory. Constructing a validated instance from raw configuration.
• Type extractor. Reading annotations off node functions and deciding which are usable.
• Parameter validator. The component that ties extraction to construction.
• Context integration. Wiring it into the session so it runs at the right moment.
• Documentation. A guide, written as part of the feature rather than after it.

The follow-ups, which is where the real cost was

Shipping a type-introspection feature into a framework with a very wide user base means meeting type annotations you did not anticipate.

• 1.3.1. X | Y union syntax raised an AttributeError during extraction. Unvalidatable types are now skipped rather than crashed on.
• 1.4.0. Extraction was scanning every pipeline in the project, so a dataset annotated differently in two unrelated pipelines produced spurious conflict warnings on runs that touched neither. Scoped it to only the pipelines actually being run.
• Optional models. An explicit None was being coerced into an empty model instead of staying None.
• Namespaced pipelines. Parameter resolution differs under namespacing, and the extractor had to learn that.

None of these were visible from the design. All of them came from real projects, and each one is now a test.

Outcome

Parameter validation shipped in Kedro 1.3.0 in March 2026, a release I also cut. It is the direct predecessor to KEP-10: having validated the parameters going into a pipeline, the obvious next question is the data.