TouchStone

Safety and correctness tests for RL environments

Test the environment
before it teaches
the wrong lesson.

Turn environment requirements into repeatable checks. Inspect each input and assertion, approve the tests you trust, and run them whenever the environment changes.

Review the starter testsSee the workflow

Local prototype. Your adapter, your infrastructure, your approval.

One requirement. A concrete test.Illustrative example
Requirement
An invalid action must not earn reward.
Test input
{"action": "invalid"}
Deterministic assertion
reward == 0
Review
Inspect the requirement and expected result before approval.
Only approved tests enter the CI gate.
A proposed test is a hypothesis until you review it. Experimental results stay separate from the approved suite.

From a requirement
to a regression check.

Keep the judgment in review. Make each subsequent run a reproducible comparison against explicit assertions.

  1. Connect your environment

    A customer-run adapter returns observations from your environment. Keep execution in the infrastructure you already control.

  2. Review candidate tests

    Start with built-in checks or import your own. Inspect the requirement, input, assertions and source, then approve or reject each candidate.

  3. Rerun the approved suite

    Use the CLI or Python interface in your workflow. A failure or an incomplete run cannot become a passing CI result.

A small, inspectable
starting point.

Start with the local starter adapter, review its tests and inspect the resulting evidence. Then connect one environment you own.

Working locally
Candidate review, explicit assertions, approved and experimental runs, and saved results. Tests and their approval are tied to content identity.
Customer-run execution
The CLI and Python interface run where you choose. A container is an optional deployment choice; TouchStone is not a mandatory runtime proxy.
AI-assisted proposals
Use your installed Codex CLI or a customer-configured model command to propose tests. Inspect and edit the resulting inputs and deterministic assertions before approval. Model calls explicitly send context to your configured provider.
Optional cloud evidence
Explicitly sync summaries or full evidence to a separate control plane. Compare runs and review candidates with an authenticated team identity. The control plane is available for local operation; no public hosted service is deployed.
Runtime gateway
A separate gateway container supports HTTP and explicit opt-in TLS payload capture in the controlled Compose example. Only routed traffic is visible; direct connections remain a visibility gap. Production integration is not validated.

A passing suite has a boundary.

It means the approved tests met their assertions for that run. It does not prove universal safety, detect every reward hack, or validate the requirements themselves. Use trusted adapters and independently check expected behavior.

Open test workspace