Skip to main content
This page documents data structures used in the Open Reward Standard. Type definitions are shown in TypeScript notation but apply to any language implementation.

Core Types

JSONValue

Recursive type representing any valid JSON value:
Used throughout the protocol for flexible, task-specific data.

Block Types

Blocks are the fundamental unit of content in ORS. They can be text or images.

TextBlock

Text content with optional metadata:
Fields:
  • type: Always "text" (literal)
  • text: The text content (string)
  • detail: Optional metadata about this text block (object)
Example:

ImageBlock

Image content encoded as base64:
Fields:
  • type: Always "image" (literal)
  • data: Base64-encoded image data (string)
  • mimeType: MIME type like "image/png", "image/jpeg" (string)
  • detail: Optional metadata about this image (object)
Example:

Blocks

Array of blocks (text and/or images):
Usage: Prompts and tool outputs are represented as blocks. Example (multi-modal prompt):

Tool Types

ToolSpec

Specification for an available tool:
Fields:
  • name: Tool identifier, used when calling the tool (string)
  • description: Human-readable description of what the tool does (string)
  • input_schema: JSON Schema defining tool parameters, or null if the tool takes no parameters (always present in output, nullable)
Example:
Note: If input_schema is null, the tool takes no parameters.

ToolOutput

Result of executing a tool:
Fields:
  • blocks: Output content (array of TextBlock/ImageBlock, required)
  • reward: RL reward signal (number, optional)
  • finished: Whether episode is complete (boolean, default: false). Optional in input — always present in output.
  • metadata: Optional additional data (object)
Example (successful completion):
Example (intermediate step):
Key Fields: finished:
  • Critical for episode termination
  • When true, the episode is complete
  • Agent should stop calling tools and delete the session
  • Represents task completion (success or failure)
reward:
  • RL feedback signal
  • Environment-defined; common patterns include sparse rewards (only at episode end) and dense rewards (after each action)

ToolCall

Request to execute a tool:
Fields:
  • name: Tool to call (string, required)
  • input: Tool parameters matching its input_schema (object, required)
  • task_id: Optional identifier for SSE reconnection (string). When provided, clients can reconnect to an in-progress or recently completed tool call and retrieve its result within a 60-second linger window.
Example:

ListToolsOutput

Response from GET /{env_name}/tools:
Example:

Tool Result Types

Tool execution returns one of two result types:

RunToolSuccess

Successful tool execution:
Example:

RunToolError

Failed tool execution:
Example:

RunToolOutput

Union type for tool results:
The ok field discriminates between success and error:
  • ok: true → result has output field
  • ok: false → result has error field
Usage: Returned in SSE end event from POST /{env_name}/call.

Task Types

Task

Tasks are environment-specific JSON objects:
No fixed schema - each environment defines its own task structure. Examples: Math environment:
Coding environment:
Web navigation:

Split

Categorization of task lists:
Fields:
  • name: Split identifier (string)
  • type: Split category (string, one of: “train”, “validation”, “test”)
Example:
Common splits:
  • {"name": "train", "type": "train"} - Training tasks
  • {"name": "validation", "type": "validation"} - Validation tasks
  • {"name": "test", "type": "test"} - Test tasks
Custom splits: Environments can define custom splits (e.g., “hard”, “easy”) which default to type “validation”.

ListTasks

Request body for POST /{env_name}/tasks:
Example:

NumTasks

Request body for POST /{env_name}/num_tasks:
Fields:
  • split: Split name to count tasks in (string, required)

GetTask

Request body for POST /{env_name}/task:
Fields:
  • split: Split name (string, required)
  • index: Task index within the split (number, required)

GetTaskRange

Request body for POST /{env_name}/task_range:
Fields:
  • split: Split name (string, required)
  • start: Start index, inclusive (number, optional)
  • stop: Stop index, exclusive (number, optional)

Session Types

CreateSession

Request to create an episode:
Fields:
  • env_name: Environment to instantiate (string, optional — defaults to first registered environment)
  • task_spec: Task data for this episode (object, optional — provide this or split+index)
  • split: Split name to load task from (string, optional — required with index if task_spec not provided)
  • index: Task index within the split (number, optional — required with split if task_spec not provided)
  • secrets: API keys, credentials, etc. (object, optional, defaults to {})
Exactly one of task_spec or the split+index pair must be provided. Providing both or neither is a validation error.
Example (with inline task spec):
Example (with split and index):
Security note: Secrets are passed to the environment but should not be logged or persisted by the server.

Type Examples by Use Case

Discovery Flow

Episode Flow

Type Validation

Implementations should validate:

Input Validation

  • Tool calls match the tool’s input_schema
  • Required fields are present
  • Types match specifications

Output Guarantees

  • ToolOutput.blocks is non-empty array
  • ToolOutput.finished is boolean
  • ToolOutput.reward is number or null
  • Block type is exactly “text” or “image”

Episode Invariants

  • Once finished: true is returned, no more tools should be called
  • Session IDs are unique across the server
  • Tool names match those in list_tools() output

Language-Specific Notes

Python (Reference Implementation)

TypeScript

JSON Schema

For validation in any language, use JSON Schema:

Next Steps

HTTP API

See how these types are used in API endpoints

Sessions

Understand episode lifecycle and state

Tools Concept

Learn about tool design and usage

Implementation Guide

Implement these types in your server

Key Takeaway: ORS uses simple, composable types. Blocks provide flexible content representation. ToolOutput bundles content, rewards, and episode termination. Task structure is environment-specific for maximum flexibility.