> Source: https://builder-docs.ema.ai/core-concepts/type-system
> Title: Type System

# Type System

Every port (input or output) in a GWE workflow has a type. The engine enforces type-checking at configuration time, ensuring that data passed between agents matches the expected format. This prevents runtime errors and provides intellisense-like support in the Workflow Builder.

## Well-Known Types

GWE provides a set of built-in types that have special support across the platform and SDKs.

### Primitive Types

Type

Description

Example

`STRING`

Text values

`"Hello, world"`

`FLOAT`

Floating-point numbers

`0.95`

`Integer` (proto: INT)

Whole numbers

`42`

`Boolean` (proto: BOOL)

True or false

`true`

`Struct` (proto: STRUCT)

Structured key-value data

`{"key": "value"}`

### Framework Types

These types represent common data structures used across Ema's agent ecosystem. They receive special treatment in the engine and SDKs, including automatic formatting for LLM consumption.

Type

Description

`Document`

Document content with metadata (title, source, format)

`SearchResult`

Web or knowledge-base search result with URL, snippet, and relevance score

`TextWithSources`

Text content with inline source citations

`ChatConversation`

Prior conversation history (message list with roles)

`ExtractionColumn`

Defines column schema for entity extraction

`MatchedSegment`

A chunk or segment matched from a larger document (defined in the Search service, not registered as a GWE well-known type)

`Ruleset`

A set of business rules for validation agents

`Date`

Calendar date value

`DateTime`

Date and time value

`Any`

Accepts any type (used for generic ports)

> Additional framework types (such as DatastoreConnection, FusionLlmConfig, DataProtectionConfig, and others) are used internally by the platform.

> Framework types are automatically prepared for LLM consumption when passed to LLM-based agents. For example, a `SearchResult` is formatted with its title, URL, and snippet in a way that the LLM can reference and cite.

## Array Types

An array type represents an ordered list of a single element type. Array types use the syntax `array { <element_type> }`.

**Examples:**

-   `array { STRING }`: A list of strings (analogous to `[]string` in Go).
-   `array { Document }`: A list of documents.
-   `array { array { STRING } }`: A nested array (analogous to `[][]string` in Go).

Arrays are used heavily in multi-binding patterns where an agent consumes outputs from multiple upstream agents.

### Array Type-Checking

When a multi-binding connects multiple upstream outputs to an array input:

-   All bound values must match the array's **element type**.
-   For nested arrays, the element type may itself be an array type.

## Enumerations

User-defined enumerations represent a fixed set of possible values. Enumerations are particularly useful for **classification** tasks where an agent must select from predefined categories.

**Example Ticket Priority Enum:**

```
Enum: TicketPriority
 Values: [LOW, MEDIUM, HIGH, CRITICAL]
```

When an agent output is an enum type, it can be used in [run-if conditions](/legacy-docs/core-concepts/conditionals) to drive branching logic:

```
CLASSIFY (output: priority, type: TicketPriority)
 +-- [run-if priority == HIGH] --> Escalate
 +-- [run-if priority == LOW] --> AutoResolve
```

Enumerations are defined as part of the agent's output specification. The Workflow Builder displays the available values when configuring conditional branches.

* * *

**Next**: [Workflow Validation](/legacy-docs/core-concepts/workflow-validation)