Version 0.1 · 5 November 2026

The Workbench brings research records, execution histories and
portfolio decisions into an inspectable interface. Start with the public demonstrator. It uses
selected, sanitised snapshots. The private Workbench and command-line
pipeline serve the operational environment.

1. Follow a public example

P95 identifies parameter pack/pass 95. The historical trade spans for
discovery and recorded evaluation overlap. Their observed entry and
close dates describe the trades in the export. A declared evaluation
interval must come from the experiment specification.

Use C07 as the worked example in the accompanying paper. Its audit
follows a GBP/USD 4H configuration from the source trial to a specific
DEMO execution and closure. Keep the public example and its dated
evidence scope distinct from the private operating records.

2. Research lifecycle

1. Define the experiment. Specify the instrument,
   interval, strategy build, search bounds, dates, costs and acceptance
   criteria. Preserve the dataset identity and record which windows may
   influence selection.
2. Run Stage 0. Use the approved command-line sweep to
   execute and record Optuna trials. Preserve the run manifest, completed
   trial counts and execution exceptions.
3. Check intake. Verify that outputs and input
   identities agree before screening. Investigate missing or inconsistent
   results using the campaign runbook.
4. Screen at Stage 1. Examine eligible configurations
   and select representative candidates using the recorded policy. HDBSCAN,
   where used, groups parameter vectors. A cluster represents nearby
   configurations under the chosen feature scaling and distance
   measure.
5. Challenge the candidate. Replay the frozen vector
   across the specified windows and cost assumptions. Report overlapping
   and selection-exposed windows explicitly. Reserve the independent
   evaluation label for evidence isolated from selection and tuning.
6. Record a decision. Record the gate version, reason,
   evidence and candidate disposition. Separate pending work, research
   failure and execution error. A failed or parked candidate remains useful
   evidence.

Discovery and maintenance use their approved campaign profiles.
Follow the corresponding runbook for launch, resource limits, retries
and sealing. The Workbench surfaces results and evidence. The
command-line jobs perform research execution.

3. Deployment lifecycle

1. Freeze the strategy identity. Record source
   experiment, candidate, build, parameter vector, pair, timeframe and
   direction.
2. Bind the runtime. Record account environment,
   member, run and versioned deployment policy. Document deliberate changes
   such as supervisor-controlled sizing.
3. Review and authorise. Check ownership, account
   scope and admission policy. Research progression and authority to submit
   orders are recorded separately.
4. Observe. Track run health, signal activity,
   admission and broker events. Distinguish DEMO, LIVE and observe-only
   roles. A healthy heartbeat indicates runtime activity within its
   freshness definition.
5. Review changes. Preserve a new version for changes
   that materially affect outcomes. Link predecessor and successor records
   so the historical comparison remains inspectable.

The private Workbench’s planned read-only workflow begins with
candidate selection and research-stage navigation. It should display
linked curves, portfolio membership and visible gaps. Use source
manifests and release evidence where a relationship is unavailable in
the view.

4. Allocation and execution
lifecycle

A strategy proposes an order. The supervisor evaluates its recorded
constraints and can grant the full request, reduce it or block it. A
reservation links the grant to the local member and run. A broker
acknowledgement, execution and closure each require their own record. An
observe-only result describes a hypothetical decision. The demo’s
historical allocation view exposes decision records and selected
reasons.

Use the exact broker position ID to collect the lifecycle. Entry and
exit execution-order IDs identify orders within it. A single execution
order can have several fills. Local labels and receipts bridge those
identifier systems. Use the original fill event for price comparison and
retain any subsequent adjusted entry field separately.

5. Read metrics in scope

Check sample size, observation dates, dataset version and account
classification before comparing results. A source record’s timestamp is
the time of that record. The test boundaries must be identified
separately. Missing fields remain unknown. Pips PF, cash PF and account
return need separate labels.

6. Reconcile and investigate

1. Fix the account, reporting period and valuation cutoff. Keep DEMO
   and LIVE exports separate.
2. Retain both detailed execution and summary files. Compare
   overlapping views and count each economic event once.
3. Group partial fills by execution order for summary checks. Group
   entry, exit and applicable rollover legs by position for lifecycle
   checks.
4. Resolve local identifiers through exact receipt or ledger links. Use
   timing and price to investigate possible matches. Record unresolved
   ambiguity explicitly.
5. Compare side, quantity, original fill, final close and costs using
   their own evidence fields. Mark unavailable fields individually.
6. Compare account movements against the daily cash report where
   available. Keep unsettled marks and completed settlements separate.
7. Record the covered population and exceptions. Preserve account cash
   for probe executions and report them separately in strategy
   analysis.

If a view appears empty, confirm the dataset, pair and member filters
first. If a broker position cannot be matched, inspect account scope and
identifier namespace. If a portfolio total differs from a broker report,
compare cutoffs, membership, commission and settlement-day conventions
before treating it as an unexplained residual.

7. Feature status

Human review remains part of promotion and deployment authorisation.
For a client integration, agree source systems, field contracts,
permissions, operating responsibilities and acceptance evidence.