Documentation Index

Fetch the complete documentation index at: https://docs.leapter.com/llms.txt

Use this file to discover all available pages before exploring further.

​

Type Definitions

Type Definitions let you describe data shapes once and reuse them across your project. They are defined at the project level — every Blueprint in the project can reference the same types, and so can the project’s Inputs and Outputs. You manage them from the Type Definitions entry at the top of the Contents sidebar in the Blueprint Editor. Double-click to open the dedicated Type Definitions editor.

​

Two kinds of type

Leapter has two flavors of type definition.

​

Value Type

A Value Type is a constraint on a primitive value — a string with a specific format, a number in a range, or an enumeration of allowed values. Examples:

• Email — a string that looks like an email address
• PercentScore — a number between 0 and 100
• Currency — an enum of EUR, USD, GBP

Use Value Types when you want a single name and a single set of rules for a value that appears in many places.

​

Data Type

A Data Type is a structured record — a named group of named fields, each with its own type. Data Types compose: a field on a Data Type can itself be a Value Type, another Data Type, or a list of either. Examples:

• Customer — a record with id, name, email (where email is the Email Value Type)
• OrderLine — a record with productId, quantity, unitPrice
• Order — a record with a customer (the Customer Data Type) and lines (a list of OrderLine)

Use Data Types to model the entities your project works with.

​

Creating a type

1. Open the Type Definitions editor (double-click Type Definitions in the Contents sidebar).
2. Click + New and choose Define Value Type or Define Data Type.
3. Give the type a name and configure it:
   • For a Value Type, pick the base primitive (string, number, boolean, date) and add constraints (allowed values, regex, min / max).
   • For a Data Type, add fields. For each field, pick its type — primitive, an existing Value Type, an existing Data Type, or a list.
4. Add a description so the type’s purpose is obvious to anyone reading the project.

​

Using a type

Once defined, a type appears in every type-picker in the project:

• In Inputs and Outputs, when picking the type of an input or output.
• In a Blueprint’s local variables, when picking the type of a local.
• In Call nodes, when the called Blueprint expects an input or returns an output of this type.

Switch a parameter from a primitive type to one of your Type Definitions to give the runtime more information about the data — and to make the spec readable: Customer tells the reader more than three separate string fields ever could.

​

Why types help

• One source of truth — change the rules once and every parameter that references the type updates with it.
• Better AI generation — when you ask AI to create or edit a Blueprint, named types let AI reason about your domain (“an Order has lines”) rather than guess from primitives.
• Better runtime validation — Value Type constraints reject malformed inputs at the boundary, before any logic runs.
• Better readability — a Specification view that mentions Customer and Order reads like business prose; one full of string, string, string does not.

​

Tips

• Start without types. New projects don’t need them — primitive inputs work fine. Reach for Type Definitions when you notice the same shape repeating.
• Name them after domain concepts, not implementation. Customer is better than CustomerObject; Email is better than EmailString.
• Compose, don’t duplicate. If two Data Types share fields, extract a third type for the shared shape.

​

What to do next

• Inputs and Outputs — apply your types to the project’s parameters
• Specification view — see how types appear in the structured document
• Calling Other Blueprints — pass typed values between Blueprints