- flexibility: run the same recipe with different parameters without modifying the code
- reusability: recipes can be parametrized in such a way that they can be used for different use cases all together (good examples of this are the generic prebuilt recipes, which support any dataset or use case)
- self-documenting: if you write an input config class once, your recipe and all of its input parameters are automatically documented, both for business and technical users, in code and in the UI.
Basic Configuration Structure
Every recipe configuration inherits from a magic classInputConfig
and defines the parameters your recipe expects in the same way as Pydantic models. Only the configuration classes that inherit from InputConfig
in your code get automatically transformed into UI widgets.
Above is an example of parameter selection in the UI for a config defined in the custom recipe as. You can set the description, title and default value for the resulting widget by using typing.Annotated
and pydantic.Field
as shown below.
When users run your recipe, by default they will only be forced to input the values for which you have not set defaults. This allows you to simplify the input interface to your recipe as much as possible, leaving the user only with the mandatory decision to be made, while also enabling the flexibility to change fine-grained parameters if needed.

Config parameters selection in the UI that map to the config above; the default learning_rate parameter is hidden, unless "Advanced parameters" is toggled.
Using Your Configuration
Once you’ve defined your configuration class, you can pass it to your@recipe_main
method (the input configuration must be the first parameter of the function, before the RecipeContext). When you run your recipe with input parameters, Adaptive Engine will create a typed and validated input object, and call @recipe_main
with an instantiated MyConfig
class.
Supported field types
Type annotations in your config parameters allow Adaptive to validate user input and make sure widgets render correctly according to their type in the UI. You can use most types and leverage pydantic validation (operators such asmax_value
, ge
etc.). There are also “magic” Adaptive types you can use in your config, which are platform-aware. This means that, when rendered in the UI, they allow you to select an entity that exists in your deployment as an input parameter - namely models, datasets and graders. If you pass one of these magic input parameters via SDK, it will also be validated for existence within your Adaptive deployment.
Below you will find examples usage of both basic python types and Adaptive magic classes.
Basic Types
Adaptive Types
Adaptive provides special support for model fields, allowing you to pass model instances to your recipes:model.path
(used to spawn the model), dataset.file
(used to load a dataset file) and grader.grader
(used to instantiate a grader).