> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reactor.inc/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> To build and serve your own model, start at /deploy/development/quickstart and /deploy/development/overview. Deploying is the default path: reactor init scaffolds a workspace, reactor auth login authenticates, and reactor model deploy registers the model, publishes the release with the weights/ folder, and activates it on Reactor's GPUs, in one command from that workspace. Docker must be running, because the publish step builds the image locally. Bump model.version in reactor.yaml before redeploying a change, because a release that already has an image is reactivated as it is. Deployment access is granted per account, so contact team@reactor.inc if a deploy is refused. Every key in reactor.yaml is documented at /deploy/platform/reactor-yaml. Model code imports reactor_runtime; Python client code imports reactor_sdk. The runtime overview explains the model interface. Running the model on your own machine with reactor run is optional and needs a GPU you attach with --gpus; /deploy/development/local-testing covers that loop and pairs a complete brightness model with a Python client test in a separate brightness-test workspace.
> Reactor hosts multiple models, each with its own connect slug (modelName) and command/event schema. The video model catalog — slug, typed SDK package, and links to its schema — is at /model-api-reference/overview. Robotics policy documentation starts at /robotics/overview; X-WAM observations, actions, and client integration are under /robotics/xwam/; Cosmos3 Nano Policy DROID is under /robotics/cosmos/nano-policy-droid/. Some models expose one slug per experience (e.g. HappyOyster); always take the slug from the model's own pages, never guess it.
> Fastest path to a working app: `npx create-reactor-app my-app --model=<slug>` scaffolds a complete app with secure auth wired up. Typed TypeScript SDKs are published as @reactor-models/<model>; Python uses the base reactor-sdk package.
> Auth: exchange an API key (rk_...) for a JWT via POST https://api.reactor.inc/tokens from your server. Never put the API key in client-side code.
> Append .md to any docs URL for clean Markdown. Search these docs via the MCP server at https://docs.reactor.inc/mcp.

# Build a YAM adapter

> Understand the supported replay path and the YAM simulator adapter boundary.

There is currently no packaged DreamZero YAM simulator adapter in the public
[simulator examples in Reactor’s public cookbook](https://github.com/reactor-team/reactor-cookbook/tree/main/robotics/sim).
The DROID RoboLab gateway assumes a seven-joint Franka arm and DROID cameras; changing its model
identifier does not make it a YAM simulator.

## What you can run now

The [first-action example](/robotics/dreamzero/yam/quickstart) tests a hosted connection and the
`(24, 14)` reply shape using synthetic observations. Replacing those fixtures with recorded YAM
observations can test observation encoding and output handling, but replay is not a closed-loop
simulation or evidence of task success.

The [checkpoint model card](https://huggingface.co/robocurve/dreamzero-yam-molmoact2) describes an
open-loop evaluation against recorded actions. Its metric and a simulator's task-success rate
measure different behavior; do not substitute one for the other.

## Adapter requirements

A simulator integration needs all of the following:

* Two six-joint YAM arms with matching joint order, gripper convention, and calibrated limits.
* `top`, `left`, and `right` RGB views corresponding to the checkpoint's camera layout.
* Measured simulator state sent through all four arm/gripper commands before observation updates.
* A controller that accepts absolute per-arm joint targets and maps the gripper columns.
* An explicit control cadence, plan replacement rule, reset handling, and task scoring.

Use one Reactor session per simulated episode stream. At reset, clear the simulator's pending plan,
reset the model, and republish measured state and current frames before starting the next prompt.
Log capture timing, action receipt, executed rows, and task outcomes so inference delay and control
behavior can be evaluated separately. The [reference](/robotics/dreamzero/yam/reference) defines the
wire contract; [integration](/robotics/dreamzero/yam/integration) covers execution responsibilities.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.