Skip to content
UHPUHPDeveloper Guide
Independent resource · Not affiliated with HarnessRouter · Site data checked 23 Sep 2026

Harness backend

System One Harness

System One is a finite-action decision harness rather than a coding CLI; HarnessRouter exposes it as backend `systemone` and later adds a scoped dual-loop calibration path.

Verified: HarnessRouter: v0.23.10System One: 0.4.0

What System One is

Section titled “What System One is”

System One Harness is an open-source decision harness built around a finite, typed action space. It is not a conventional coding CLI that produces free-form text and shell actions. HarnessRouter first released it as backend systemone in v0.21.0 through PR #225, where the integration used System One 0.3.1 and the TypeSafe Jev decision model.

Current HarnessRouter v0.23.10 has advanced its default System One pin to 0.4.0. The upstream System One v0.4.0 release adds versioned configuration, objective/scoreboard data, benchmarking/reporting surfaces and the documented dual-loop design in which an outer System Two harness calibrates an inner harness configuration.

This is a HarnessRouter/System One implementation relationship. It does not make the System One control model part of the UHP wire protocol.

Typed environment rather than generic tool prose

Section titled “Typed environment rather than generic tool prose”

For a System One turn, HarnessRouter treats the configured MCP server as the environment. Its tools are compiled into a finite set of actions:

  • ordinary enumerable parameters can become typed action choices;
  • environment observation/reset are explicit parts of the loop;
  • a tool requiring unconstrained free text is not silently presented as if it were enumerable, and the trace records that it was not offered;
  • disabledTools are removed from the question/action surface rather than exposed and later refused.

When no external server is configured, the adapter can use the built-in order-desk environment. The environment state and loop steps are persisted under the workspace so a later turn can continue the same decision process.

The provider surface is also different

Section titled “The provider surface is also different”

The original integration uses TypeSafe’s Jev model through OpenRouter’s decisions endpoint. PR #225 records that the endpoint is served at /api/alpha/decisions, not under the usual /api/v1 root, so HarnessRouter registers a dedicated relay root rather than forcing the request through a generic chat-completions shape.

The PR’s measured runner path executed six actions in 1.44 seconds and recorded served model typesafe/jev-1.13-20260917 with 6,304 input / 1,410 output units under the provider’s reporting. Later v0.22.0 / PR #230 adds a direct TypeSafe AI provider path for System One, so OpenRouter is no longer the only provider route in released HarnessRouter.

incomplete is an intentional terminal result

Section titled “incomplete is an intentional terminal result”

System One introduced an important execution-state distinction into HarnessRouter: a run may finish as incomplete with a reason rather than being forced into success or generic failure.

Examples include:

  • the decision model asks for help;
  • a destructive action never clears its configured confidence threshold.

HarnessRouter carries the reason in incomplete_details and does not automatically retry the outcome as if it were an infrastructure error. This is an implementation-level result contract added for the backend; it is not evidence of a new UHP protocol version.

From one loop to dual-loop calibration

Section titled “From one loop to dual-loop calibration”

System One v0.4.0 makes the outer/inner distinction explicit: a System Two process can evaluate and calibrate the configuration used by the faster inner System One loop. HarnessRouter v0.23.0 / PR #232 implements the platform side of that architecture.

A harness can declare that it calibrates exactly one other harness. During the calibrator’s turn, HarnessRouter supplies:

  • HR_API_URL;
  • a short-lived HR_CALIBRATION_TOKEN scoped to the named target harness.

That credential is intentionally narrower than an organization key or provider key. Under PR #232 it can start runs for the target, inspect that target’s sessions/turns/files, read or publish the target harness package, and relaunch its kit. It cannot use unrelated routes, switch to a different harness, or grant itself calibration authority. The target harness id is enforced both in route authorization and ownership checks.

The same release also carries a System One handoff value through the result path so an incomplete result can say which branch received the handoff and under what judgment.

Package-backed configuration as a calibration seam

Section titled “Package-backed configuration as a calibration seam”

PR #232 adds PUT /v1/harnesses/{id}/plugin as the platform operation for publishing the package that represents a target harness configuration. A package with the same name is replaced while unrelated packages remain. In the System One dual-loop model, this acts as the durable configuration update seam that an authorized outer loop can evaluate and revise.

The architectural lesson is broader than System One: an optimizer that can drive another harness should receive a task-scoped capability over exactly the target state it is allowed to inspect and mutate, not a reusable administrator credential. HarnessRouter’s implementation is one concrete example; UHP 2026-09-12 does not standardize this calibrator role.

Current pin and release coordinates

Section titled “Current pin and release coordinates”
CoordinateVerified state
HarnessRouter first releasev0.21.0 / PR #225 / backend 15
System One pin at introduction0.3.1
Current HarnessRouter stable/currentv0.23.10 / 2545a54ec63151355150d0318245bcbaa7dea1db
Current HarnessRouter default System One pin0.4.0
System One latest observed releasev0.4.0, 21 Sep 2026
Direct TypeSafe providerReleased in v0.22.0 / PR #230
Dual-loop platform supportReleased in v0.23.0 / PR #232

Evidence at introduction

Section titled “Evidence at introduction”

PR #225 reports 9 System One runner tests and 5 catalog tests. The combined runner/gateway suites recorded 1,035 passed; the reported 17 failures were media-MCP tests requiring ffmpeg on the machine used for that run. The PR also reports a live OpenRouter turn through the actual runner/relay path.

Those measurements are backend/runtime evidence. They do not substitute for UHP conformance and do not establish that TypeSafe, Jev or System One independently exposes a UHP server.

Section titled “Related pages”

Read HarnessRouter, OpenHands, Harness composition, Loop engineering, Conformance and Release tracker.

Primary sources

Section titled “Primary sources”