Skip to content
UHPUHPDeveloper Guide
Independent developer guide. Not affiliated with HarnessRouter or the official UHP project.

System One Harness

System One is a finite-action decision harness with its own UHP server and a separately released HarnessRouter backend. Its historical Core report, typed action space and dual-loop calibration have distinct evidence scopes.

Page reviewed 4 Oct 2026 Source and review policy

HarnessRouter checked 4 Oct: v0.29.0System One: 0.4.0

Choose the project server or the HarnessRouter backend

Section titled “Choose the project server or the HarnessRouter backend”

System One has two published UHP integration paths, which should not be collapsed into one claim. Its own versioned README at v0.4.0 documents s1 serve as a UHP server. HarnessRouter separately exposes backend systemone behind CE’s gateway and provider configuration.

PathOwner of the outer HTTP contractEvidence scope
s1 serveSystem One Harness itselfProject-authored historical Core report
CE backend systemoneHarnessRouterVersion-pinned adapter and CE’s separately measured reports

The standalone server example is:

Terminal window
s1 serve --api-key choose-a-secret --port 8710

Select a private API key and configure the documented model-provider credential separately. This command is source-checked only; no server or model turn was started here.

The checked-in report was generated 19 September 2026 at 23:05:04 UTC against System One Harness 0.1.0, UHP 2026-09-12, suite 2026.9.12.post1, at loopback port 8710. It records 40 passed, 0 failed, 0 skipped, 0 errored, with highest class Core. It is evidence of a project-native server, but not an independent rerun, current 85-check Full result or TypeSafe endorsement of UHP.

Decide what an incomplete run means

Section titled “Decide what an incomplete run means”

For a finite-action workflow, an unmet confidence gate or request for help can legitimately end the run without completing the business goal. Inspect the reason and last environment state, then choose whether a human decision or configuration calibration is needed. Do not retry indefinitely as if the provider connection failed. Conformance tests protocol obligations; your application’s acceptance case must also check the intended environment terminal condition and destructive-action threshold.

Keep the historical CE measurements below distinct from this standalone report. The current project’s README still describes some already-shipped CE integration as a milestone; release and adapter source take precedence for CE availability.

HarnessRouter integration, checked 4 October 2026: the v0.29.0 entrypoint retains the default pin System One 0.4.0. This is source-verified adapter configuration, not a fresh runtime or provider test. HarnessRouter now has 20 released backends; the earlier counts and measurements below retain their dated scope.

Historical detail: the implementation narrative below preserves the 24 Sep 2026 source snapshot. Later upstream releases and HarnessRouter releases must not be inferred from that snapshot.

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.12 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.

HarnessRouter v0.23.11 / PR #257 also fixes the console’s live presentation of this existing result data. The POST-stream and event-bus paths now retain terminal incomplete_details, so a handoff or step-cap reason appears when the turn settles instead of only after history is reloaded. This is console delivery fidelity, not a new System One or UHP result field.

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.12 / 5c2d3bb3e8b07297f2e82fd3a5075d430fb8f446
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”