For the complete documentation index, see llms.txt. This page is also available as Markdown.

Kinds

Kinds are the Workflows type system: the semantic meaning and data representation behind every connection.

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

A selector might refer to a named input - for example the input image - like $inputs.image, or to 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.

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.

Kinds declared in Roboflow plugins

Last updated

Was this helpful?