Strategy lab or quantitative capstone
Connect hypothesis formation, rule specification, implementation, backtesting, sensitivity review, and virtual forward observation.
Give students one quantitative trading lab where they can turn a hypothesis into visual rules or Python, inspect historical behavior, challenge overfitting, and observe the frozen strategy in virtual forward time.
Give students a complete experimental lifecycle instead of judging a strategy by one optimized historical result.
Connect hypothesis formation, rule specification, implementation, backtesting, sensitivity review, and virtual forward observation.
Students specify a simple thesis, build it visually or in Python, inspect historical trades, revise once, and monitor the strategy virtually.
All paths require entry, exit, sizing, market-data, and risk concepts. Quantitative courses should define their own statistics and programming baseline.
Use supported universes, triggers, indicators, schedules, sizing, exits, custom logic, backtests, and virtual strategy deployment.
Grade the economic rationale, reproducibility, assumptions, transaction path, overfitting analysis, failure modes, and forward comparison.
Available data, packages, fills, slippage assumptions, instruments, order behavior, and live-account eligibility depend on current support.
The platform supplies an execution and simulation surface; the student remains responsible for the hypothesis, implementation, and critique.
Define universe, data trigger, signal, sizing, exits, schedule, and portfolio controls.
Use explicit configuration or code to expose unstated assumptions in a trading idea.
Review trades and hypothetical performance for look-ahead, overfitting, parameter sensitivity, and regime dependence.
Observe a strategy in a virtual portfolio and document differences between historical expectations and new data.
Give students an ambiguous strategy description and require a complete, testable visual specification.
Compare a standard indicator with a supported custom implementation and explain any differences.
Vary a small, justified parameter set and discuss whether the result is stable or tuned to history.
Separate development and evaluation periods conceptually, preserve the final rule set, and critique out-of-sample behavior.
Implement the same supported concept twice and compare expressiveness, transparency, and maintenance cost.
Deploy a tested strategy virtually, maintain a change log, and analyze divergence without rewriting history.
State the hypothesis, expected mechanism, data, universe, horizon, controls, and falsification criteria.
Build the complete strategy with explicit decisions and record implementation constraints.
Inspect trades, challenge assumptions, run bounded sensitivity analysis, and freeze a final version.
Observe without tuning, document incidents and differences, then present an evidence-based critique.
Python strategies run in a supported, bounded environment. Investfly is not a general notebook, unlimited package host, exchange-level order-book simulator, or low-latency execution laboratory.
No. The visual builder supports a no-code path for explicit strategy rules, while programming-oriented sections can use the Python SDK.
Supported strategies follow the shared Investfly path through historical backtesting and virtual portfolio deployment, enabling comparison between hypothetical history and subsequent observation.
No. Python runs in a bounded environment with selected supported packages and interfaces. Investfly should be used as a strategy testing and deployment surface, not an unrestricted compute environment.
Create a free instructor account and choose whether students begin with visual rules, Python, or both.
Runtime, data, instruments, packages, and simulated results depend on current platform support.