Seeded Optuna Maintenance in the Alpha Workbench
A technical note on moving from a deployed FX research candidate to a rolling recalibration queue, using the Alpha Workbench to expose trial quality, trade count, profit factor and review status without treating discovery results as deployable alpha.
1. Why maintenance matters
Systematic trading research does not end when a candidate is found. Markets move, data windows roll forward, and parameter regions that looked promising in one period can decay in another. The Alpha Workbench therefore treats each candidate as a monitored research object rather than a finished product.
The purpose of seeded maintenance is to periodically ask a narrow and practical question:
This is deliberately more conservative than a fresh broad search. The maintenance sweep is seeded from an existing candidate so that the process explores continuity, drift and adjacent alternatives rather than constantly starting from zero.
2. The operating loop
The current Workbench process keeps heavy computation in scripted workflows while the Reflex console provides visibility, review status and operator control. The aim is to manage the full research-to-deployment lifecycle of algorithmic candidates: hypothesis formation, seeded recalibration, evidence capture, candidate review, deployment tracking, telemetry monitoring and historic performance analysis. Automated strategies may run continuously once deployed, but promotion, retirement and material lifecycle decisions remain governed by an auditable review process.
In this model, automation is used where it adds consistency and repeatability, while human review is retained at the points where judgement, risk control and evidential interpretation matter most.
A candidate’s known parameter set is exported from the database into a reproducible seed file. The seed preserves provenance back to the source run and pass number.
Rolling Optuna runs explore recent windows such as 6M and 9M. Outputs are treated as discovery evidence, not promotion evidence.
The Workbench shows trial metrics, due status, survivor flags, heartbeat health and generated commands for operator review.
3. What the Workbench shows
The Maintenance Control view is designed to answer practical operating questions: which candidates are due for recalibration, which services are alive, what recent windows say, and which generated command should be run by the operator. The aim is to make research maintenance visible and auditable rather than hidden in ad hoc terminal history.
| Workbench field | What it means | How it should be read |
|---|---|---|
candidate_id |
The tracked research candidate, usually tied to a source run and pass. | An identity and audit key, not a claim of tradability. |
beat_age |
Age of the most recent heartbeat from a deployed demo/shadow process. | Operational health check only. |
6M PF / 9M PF |
Profit factor observed in recent rolling maintenance windows. | Useful signal for review, but insufficient for promotion. |
6M trades / 9M trades |
Trade density in the recent window. | Low counts are flagged because sparse evidence is fragile. |
smoke command / full command |
Reproducible shell commands for either a small workflow proof or a full maintenance sweep. | Smoke commands prove the operational path; full commands produce reviewable maintenance evidence. |
4. The maintenance ledger
Each rolling maintenance cycle is recorded as an auditable event. The ledger captures the candidate being recalibrated, the windows used, the number of trials, the seed and manifest references, completion status and human review status. This separates computation from promotion: a maintenance sweep can complete successfully while still producing no deployable result.
This distinction is important. A trial can be profitable in a rolling window and still be rejected, parked or routed into deeper validation. The maintenance ledger therefore supports both positive and negative evidence. It records not only what looked promising, but also what was tested and deliberately not advanced.
5. What “candidate” means at this stage
After a rolling maintenance sweep, attractive Optuna trials are not treated as deployable strategies. They are treated as candidate research objects. Each candidate must still pass through further review: cohort and loss-pocket discovery, density-based trade-state clustering, out-of-sample confirmation, and execution-engine retesting.
In practical terms, the process looks for repeated groups of trades that behave unusually well or badly, checks whether those behaviours are stable rather than accidental, and then retests any proposed rule outside the original discovery window. Only after that evidence exists can a candidate move from “surfaced by optimisation” to “worthy of promotion review.”
A useful maintenance result might have reasonable trade count, positive net pips, acceptable profit factor and no obvious window-level failure. Even then, it remains a research object rather than a trading decision.
| Label | Meaning | Next action |
|---|---|---|
| SURFACED | A parameter configuration has appeared in a search or maintenance sweep. | Review metrics and decide whether it deserves diagnostic work. |
| WATCHLIST | The candidate is interesting but not strong enough for promotion. | Monitor, compare with neighbouring candidates, or wait for more evidence. |
| DEMO / SHADOW | The candidate has been approved for controlled observation only. | Collect forward telemetry and compare expected behaviour with observed behaviour. |
6. Deeper validation in common terms
The next stages are not just “run more scripts”. They are distinct analytical techniques designed to reduce self-deception in noisy market data.
Cohort and loss-pocket discovery
This stage looks for repeated pockets of good or bad behaviour by grouping trades using interpretable decision-time dimensions: direction, hour, session, volatility bucket, spread bucket, regime, trend class, confidence band, retry status and compact combinations of those features. The output is a set of favourable or hostile cohorts, with trade count, total pips, average pips, win rate and profit factor.
In plain English, it asks: are the losses concentrated in repeatable conditions that can be described and tested?
Density-based trade-state clustering
This stage treats each trade as a point in a multi-feature state space using decision-time information. Dense groups of similar trades are identified and summarised. A cluster is interesting when similar trades repeatedly show poor outcomes, or when a suspected loss pocket also appears as a dense and coherent group rather than as scattered noise.
In plain English, it asks: do similar trade states naturally group into useful behavioural regimes, or is the apparent pattern just a loose collection of accidents?
Out-of-sample confirmation and execution-engine retesting
Any proposed rule, veto or gate has to be tested outside the discovery window and then retested in the actual execution engine. This protects against a common failure mode: a rule that looks useful in analysis but does not behave the same way once coded into the strategy.
7. Current technical position
The current Alpha Workbench stack now has the main pieces needed to tell this story responsibly:
- candidate provenance from database-backed run and pass records;
- seed export from known candidates;
- rolling Optuna maintenance over configurable windows;
- trial output files including trade count, net pips, average pips, profit factor and rejection flags;
- candidate registry and evidence tables;
- heartbeat telemetry for deployed demo/shadow services;
- a maintenance-cycle ledger, generated operator commands and review-status tracking for controlled recalibration workflows.
The management layer is still evolving. Docker/service orchestration should remain cautious and operator-reviewed until the Workbench has tighter controls around allowed operations, service identity, restart safety, adoption of existing broker state and audit logging of every transition.
8. What is deliberately not claimed
This note does not claim that any rolling maintenance trial is tradeable. It does not publish live account results, broker information, deployable parameter sets, private infrastructure paths or unmanaged service commands. The purpose is to show research process maturity: a repeatable loop for surfacing, reviewing and validating candidates under an audit trail.
The risk-management layer — position sizing, drawdown control, exposure limits, correlation checks and tail-risk monitoring — is an important later stage. It should be added after the current alpha evidence and demo/live parity workflow has matured, not mixed into this maintenance note prematurely.
9. Conclusion
The Alpha Workbench is becoming more than a backtest dashboard. It is an evidence-producing engineering system. A candidate can now be tracked, seeded, re-swept, reviewed, compared across rolling windows and routed into deeper validation without pretending that a single profitable result is enough.
That distinction is central to the Lucitech approach: find potential alpha, but make the audit trail strong enough that promotion, rejection and retirement decisions can be explained later.