# Helmsman: from research candidate to monitor

> Stable identity, evidence gates, and visible deployment states in the Helmsman operator workspace.

Published: 2026-09-22  
Work period: June to July 2026  
Product: [Helmsman](https://adityadalmia.com/projects/helmsman/)  
Canonical HTML: https://adityadalmia.com/blog/helmsman-control-plane/

A research candidate becomes expensive the moment another system must schedule it, explain it, and remember why it exists.

That transition is the core of the Helmsman workspace, the operator-facing part of the broader platform. A candidate can remain cheap research data. A selected candidate can become a reviewable thesis and monitor specification. Compilation and execution stay separate again.

I helped design and integrate this workspace with the surrounding research and execution systems, working with collaborators and AI-assisted implementation. The useful engineering story is the boundary between those systems, not a claim of sole authorship.

## Follow one candidate across the boundary

Imagine a researcher investigating whether a defined pattern after a move from $100 to $103 deserves continued observation. Those prices are an invented example, not a result or trading recommendation.

In Structure Lab, the researcher makes the pattern explicit and registers a frozen candidate. Registration gives the configuration a stable identity. It does not create a monitor, schedule work, or establish that the idea is useful.

The candidate can then accumulate evaluation records. When the operator decides it deserves attention, Compose is the explicit promotion step. The operator selects the definition, states the claim, records what would invalidate it, and reviews the evidence status. The API creates two operational objects:

- A **thesis**: the claim, its context, and what would disprove it.
- A **monitor**: the specification of what the platform should observe for that thesis.

The monitor starts as a specification at `log_only`, an observation-only stage. It is not silently executed. Compilation, deployment, and later promotion remain separate actions.

![Helmsman monitor detail showing spec deployment state, log-only promotion stage, and no agent or compiled target in a synthetic example.](https://adityadalmia.com/_astro/monitor-state-synthetic.Q_i1BxlR_Z1yBqns.webp)

*Actual Helmsman frontend, rendered locally with invented data. Deployment state and promotion stage remain separate; no agent or compiled target is attached. The $12 value is a hypothetical monthly software budget, not trading capital or measured spending. This fixture does not prove a successful promotion or execution.*

This two-tier design rejects two tempting shortcuts. Turning every candidate into a monitor would give throwaway experiments an operational lifecycle. Retyping a chosen candidate into a new object would lose the identity and evidence already attached to it.

## Identity belongs to the API

The registry computes a hash over a canonical JSON representation of each configuration. Canonicalization sorts object keys before serialization, so clients do not each invent their own cross-language hashing rules. Registering the same configuration returns the existing definition; changing it produces a new append-only row with optional lineage to its parent.

That hash answers a narrow question: is this the same frozen configuration under the registry’s serialization contract? It does not certify that the idea works.

The separation also prevented a subtle collision. The workspace already had a narrative compilation path that could update monitors by thesis and agent name. Reusing the same identity for a structure-derived monitor could let a later compilation overwrite the frozen condition. The promotion path uses a distinct structure-monitor identity tied to the definition hash.

This is the kind of failure that rarely appears in a feature tour. Both paths can work in isolation while their shared naming scheme corrupts the boundary between them.

## Preview is information, not permission

Compose asks the server for derived fields such as the monitor name and schedule. The browser does not reconstruct them independently. When the operator submits the promotion, the write path checks the definition, evidence, and duplicate status again.

The repeated check matters because a preview can become stale. Two requests can also arrive together. The implementation performs an early duplicate lookup, then opens a database transaction, takes a transaction-scoped advisory lock for the definition, market, and interval, and repeats the lookup. The thesis, monitor, required decision gate, and entity-creation events then commit together.

The lock coordinates this promotion path; it is not a claim of global exactly-once behaviour across every possible writer. The definition and evidence also live in a separate research database, so the operation is not a distributed transaction across both stores.

We rejected an executable-flow preview for a related reason. The available compiler endpoint produced a change bundle and updated stored state. Using it merely to render a preview would make viewing the form a mutation. The current preview stays narrower until there is a genuinely side-effect-free rendering contract.

## Make inadequate evidence durable

The difficult case is a promising candidate without adequate later evidence. “Out of sample” means data that was not used to shape the definition. If a rule was tuned on January through June and then checked on July, July is the out-of-sample period.

The workspace allows the operator to record such a candidate, but it does not let a warning vanish after one click. Promotion without positive out-of-sample evidence requires an explicit acknowledgement. That acknowledgement creates a durable decision gate which blocks advancement from observation-only `log_only` to `paper` until a human resolves it.

Paper operation means simulation. For example, the system might record an imaginary $100 purchase and $103 sale without committing those dollars. The label does not prove that a complete simulator is running.

A regression in this evidence gate illustrates why the distinction matters. A candidate could have favourable results on development data and one later period too thin to evaluate. An earlier classifier could treat the development result as sufficient merely because later data existed. The corrected classifier considers whether the later period itself contains enough scored evidence. Seven focused tests cover absent, development-only, thin, positive, and negative cases; they passed in the September 22 source review.

Those are unit tests of classification logic. They do not exercise current database permissions, concurrent production requests, or a complete deployed workflow.

## The workspace preserves disagreement and failure

The signed-in interface groups theses, monitors, jobs, decisions, and audits rather than reducing the system to one dashboard. Monitors show deployment state separately from promotion stage. Jobs identify their execution system and expose schedule, run, status, and heartbeat fields. Decisions separate accepted architecture, unresolved owner questions, and rejected proposals. Audit history keeps prior failures visible.

That structure was observed read-only on September 22 in an existing authenticated session. Structure Lab rendered a chart, and the Evidence view exposed its evaluation and leaderboard fields. Some displayed audit history was dated July 11, so it is historical evidence rather than a current health signal. Compose was deliberately not opened because its source-labelled GET path can initialize database objects. Live captures are not published because those records contain private research details, identifiers, and budgets. The two screenshots here instead render the actual frontend against a local, read-only synthetic API.

This separation is useful when something is missing. No evaluation record should render as “zero,” because zero implies a measurement. A monitor in `spec` is not deployed. A schedule definition is not a successful run. An old audit receipt is not current availability.

![Synthetic Helmsman desk with one research thesis, a specification that is not armed, no signals, and a failing monitor-evidence audit.](https://adityadalmia.com/_astro/desk-synthetic.DHTdiS1l_1S7nII.webp)

*A local synthetic Desk view makes incomplete work visible: the monitor exists as a specification and its audit reports missing execution evidence. All counts, dates, names, and amounts are invented fixture values. The screen demonstrates presentation of state, not a live audit, research result, or successful scheduler run.*

## What is implemented, and what remains unproven

Private source implements the definition registry, promotion boundary, evidence gate, transaction and lifecycle checks described here. Historical July records cover development integration and deployment. The current read-only review established authenticated navigation and the structure of the workspace; it did not trigger a research job, promote a candidate, compile a flow, or establish the provenance of displayed data.

The owner reports that the product is still at the mock-data stage while real-data integration is being developed; the read-only review did not independently establish record provenance. A source selector labelled “DB” does not establish that every record is current, authentic, or complete. The frontend health endpoint also returns a static success response without checking every dependency.

The design I would preserve is the explicit cost boundary: candidates remain cheap to create and discard; an operational commitment acquires identity, evidence, state, and an audit trail. The next strong receipt would follow one authorised synthetic or public-safe candidate through current ingestion, evaluation, promotion, compilation, and execution, with each transition recorded.