Skip to content

Kinds

In Workflows, some values can’t be set in advance and are only determined during execution. This is similar to writing a function where you don’t know the exact input values upfront — they’re only provided at runtime, either from user inputs or from other function outputs.

To manage this, Workflows use selectors, which act like references, pointing to data without containing it directly.

selectors

Selectors might refer to a named input - for example input image - like $inputs.image or predictions generated by a previous step - like $steps.my_model.predictions

In the Workflows ecosystem, users focus on data purpose (e.g., “image”) without worrying about its exact format. Meanwhile, developers building workflow blocks need precise data formats. Kinds serve both needs - they simplify data handling for users while ensuring developers work with the correct data structure.

What are the Kinds?

Kinds is Workflows type system with each kind defining:

  • name - expressing semantic meaning of the underlying data - like image or point;

  • Python data representation - the data type and format that blocks creators should expect when handling the data within blocks;

  • optional serialized data representation - defining what is the format of the kind that external systems should use to integrate with Workflows ecosystem - when needed, custom kinds serializers and deserializers are provided to ensure seamless translation;

Using kinds streamlines compatibility: when a step outputs data of a certain kind and another step requires that same kind, the workflow engine assumes they’ll be compatible, reducing the need for compatibility checks and providing compile-time verification of Workflows definitions.

Note

As for now, kinds are such simplistic that do not support types polymorphism - and developers are asked to use unions of kinds to solve that problem. As defining extensive unions of kinds may be problematic, this problem will probably be addressed in Execution Engine v2.

Warning

In inference release 0.18.0 we decided to make drastic move to heal the ecosystem from the problem with ambiguous kinds names (Batch[X] vs X - see more here).

The change is breaking only if there is remote Workflow plugin depending on imports from inference.core.workflows.execution_engine.entities.types module, which is not the case to the best of our knowledge. We removed problematic kinds as if they never existed in the ecosystem and fixed all blocks from roboflow_core plugin. If there is anyone impacted by the change - here is the migration guide.

This warning will be removed end of Q1 2025.

Warning

Support for proper serialization and deserialization of any arbitrary kind was introduced in Execution Engine v1.3.0 (released with inference 0.26.0). Workflows plugins created prior that change may be updated - see refreshed Blocks Bundling page.

This warning will be removed end of Q1 2025.

Kinds declared in Roboflow plugins