> ## 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 > Define reusable Value Types and Data Types at the project level so your inputs, outputs, and call signatures share a single source of truth. 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](/fundamentals/leapter-canvas/inputs-and-outputs). You manage them from the **Type Definitions** entry at the top of the Contents sidebar in the [Blueprint Editor](/fundamentals/leapter-canvas/introduction). Double-click to open the dedicated Type Definitions editor. The Type Definitions editor in its empty state — Define Value Type and Define Data Type buttons offer the two starting points ## 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](/fundamentals/leapter-canvas/inputs-and-outputs)**, when picking the type of an input or output. * In a [Blueprint](/fundamentals/leapter-canvas/introduction)'s local variables, when picking the type of a local. * In **[Call nodes](/fundamentals/leapter-canvas/calling-other-blueprints)**, 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](/fundamentals/create-blueprint/ai-prompt) or [edit](/fundamentals/change-your-blueprint/ai-editing) 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](/fundamentals/leapter-canvas/inputs-and-outputs)** — apply your types to the project's parameters * **[Specification view](/fundamentals/leapter-canvas/specification-view)** — see how types appear in the structured document * **[Calling Other Blueprints](/fundamentals/leapter-canvas/calling-other-blueprints)** — pass typed values between Blueprints