Read Me First — Research Console

The Research Console is the orchestration workspace for structured experiments. Instead of manually clicking through a lab and losing the exact setup, the console lets you define a question, route it to the appropriate strategy/research engine, run controlled parameter sets, and preserve the protocol.

What this lab is designed to do

The Research Console is the orchestration workspace for structured experiments. Instead of manually clicking through a lab and losing the exact setup, the console lets you define a question, route it to the appropriate strategy/research engine, run controlled parameter sets, and preserve the protocol.

Key controls and inputs

• Research prompt / router. Describe the research goal clearly. The AI/HMM layer should help structure the experiment, not override server-authoritative rules or fabricate unavailable data.
• Strategy. Covered Call, CSP/Wheel, LEAPS, regime sweep, premium sensitivity, and conditional workflows may be routed through different adapters.
• Fixed regime. A fixed regime isolates strategy behavior; regime sweeps test sensitivity across environments.
• Seed and paths per run. These control reproducibility and Monte Carlo precision.
• Benchmark. Select the comparison before looking at results. The benchmark should reflect the economic exposure being tested.
• Target delta, minimum IV/RV, cash, and grid settings. These are research variables; change them deliberately and record the range.

What the outputs mean

• Run status and integrity. Confirm the protected server engine is ready and the run completed without integrity errors.
• Parameter/provenance record. This is the audit trail for reproducing the experiment.
• Strategy vs benchmark metrics. Compare paired results rather than isolated headline returns.
• HMM / conditional adapter output. Treat model routing and state estimates as research inputs, not market forecasts.
• Save-to-library result. Preserve completed experiments that may matter later, including negative results.

A good first experiment

1. Write a one-sentence hypothesis—for example, “Does a high IV/RV gate improve Wheel performance after exposure matching?”
2. Choose the Wheel strategy, a fixed regime or regime sweep, a matched benchmark, a seed, and enough paths for a stable estimate.
3. Enter the frozen conditional threshold rather than searching many thresholds during the holdout run.
4. Run the experiment and inspect both performance and provenance.
5. Change only one design element and rerun if you are testing sensitivity.
6. Save the complete result to the Research Library with enough context to explain what was tested and why.

How to interpret the result

Do not judge the strategy from one path, one seed, or one favorable market environment. Read return, drawdown, exposure, trade frequency, and benchmark-relative performance together. A result is more credible when it persists across reasonable parameter changes and when the comparison benchmark has similar economic exposure.

Important assumptions and limitations

• The console can organize and route experiments, but it cannot turn a weak hypothesis or biased design into strong evidence.
• AI-generated research suggestions should be treated as proposals that require validation.
• Large parameter grids increase multiple-testing risk.
• Server-authoritative restrictions are intentional safeguards; client-side changes should not be assumed to alter the validated engine.
• A run should not be interpreted if integrity checks, provenance, or benchmark definitions are missing.

How this complements backtesting

The console is useful for coordinating both simulated and historical validation. A good workflow uses simulation to identify structural behavior, then historical or walk-forward backtesting to challenge the finding. Saved protocols make it possible to rerun the same question as the engine, data, or strategy evolves.