# 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. 

!!! example "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](https://github.com/roboflow/inference/issues/608)). 

    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](https://github.com/roboflow/inference/releases/tag/v0.18.0).

    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](/workflows/blocks_bundling.md) page.

    This warning **will be removed end of Q1 2025**.


## Kinds declared in Roboflow plugins
<!--- AUTOGENERATED_KINDS_LIST -->
<!--- AUTOGENERATED_KINDS_LIST -->

<style>
/* hide edit button for generated pages */
article > a.md-content__button.md-icon:first-child {
    display: none;
}
</style>