01Input
Raw market data and a trading idea
The system starts with the exact data, code, parameters, market session, and assumptions that a research claim depends on.
Multi-Asset Research Lab
Can a trading idea be trusted before money is put at risk?
This is a research and validation platform for systematic trading. It turns raw market data into verified datasets, reproducible experiments, and auditable results so a research claim can be challenged before it becomes a capital decision.
What it produces
- 01Verified datasets
- 02Reproducible experiments
- 03Auditable results
- 04Visible failures
- 05Controlled decisions
Plain-English description
A quality-control system for quantitative trading research
The lab is designed to stop weak data, irreproducible experiments, and overstated model claims before they reach a trading decision.
02Quality control
Verify, reproduce, and preserve
It checks data identity, locks provenance, reconstructs experiments, and prevents results from being silently changed after the fact.
03Output
Evidence that can be audited
The result can be reviewed, compared, challenged, or rejected before it is allowed to influence a future trading system.
Does it make money? Not currently.
The system does not trade, manage a fund, sell signals, or generate software revenue. No performance result on this site should be read as a claim that the platform is already profitable.
It is the wind tunnel, not the aircraft.
Its job is to reduce the chance that future systematic strategies are built on corrupted data, hidden assumptions, overfit results, or infrastructure that cannot reproduce its own claims.
Long-term application
What this foundation could support
These are future applications of the infrastructure, not products or revenue streams that exist today.
- Multi-asset systematic strategy development
- Reproducible data and experiment workflows
- Evidence lineage, review, and failure controls
- Demonstration of quantitative engineering capability
System architecture
Build the proof system before the research engine
The lab deliberately starts with contracts and evidence mechanics. A future model runner will inherit these boundaries rather than inventing them after results appear.
01Complete foundation
Research contracts
Immutable declarations define assets, sessions, bar schemas, costs, datasets, code revisions, environments, slices, parameters, and randomness before execution exists.
02Narrow concrete adapter
Controlled data boundary
A provider-neutral HTTPS transport admits only bounded, allowlisted public GET requests. The first concrete lifecycle is fixed to historical BTCUSDT five-minute bars.
03Verified lifecycle
Canonical evidence
Raw response bytes, normalized CSV, manifests, receipts, and observations use deterministic identities so equivalent evidence remains byte-stable across machines and paths.
04Offline verifiable
Persistent research runs
Completed evidence is published atomically into immutable run bundles with exact-tree verification, completion markers, bounded rollback, and relocation-safe identity.
Evidence lifecycle
One bounded chain from declaration to offline verification
Each step narrows what may happen next. A later stage cannot silently repair or reinterpret an earlier stage.
- 01
Declare
Bind the exact asset, interval, dataset, code, environment, and research boundary.
- 02
Plan
Construct the request and expected artifact graph without network or filesystem mutation.
- 03
Capture
Store exact public response bytes through a bounded no-retry HTTPS boundary.
- 04
Normalize
Convert the admitted raw structure into canonical CSV and independently verify it.
- 05
Publish
Create one deterministic run bundle only after all source evidence reconciles.
- 06
Reload and verify
Reconstruct the fixed graph from untrusted disk JSON and delegate to the authoritative verifier.
Current state
The foundation now reaches verified offline runs
The implementation has progressed from pure declarations to a complete, bounded evidence lifecycle while keeping experiment execution outside the repository.
Foundation operational
Data evidence can be planned, captured, normalized, published, reloaded, and independently verified.
That statement concerns research evidence only. It does not establish provider truth, research fitness, model validity, strategy approval, or execution authority.
- 01Asset-neutral core contracts
- 02Deterministic DatasetManifest and ExperimentManifest identity
- 03Synthetic fixture verification and controlled local ingestion
- 04Bounded provider-neutral HTTPS response capture
- 05Fixed Binance USD-M BTCUSDT raw snapshot adapter
- 06Raw kline to canonical CSV normalization
- 07Atomic persistent research-run bundles
- 08Safe planning and acknowledged publication CLI
- 09Sanitized transport failure diagnostics
- 10Bounded run deserialization and offline verify-run CLI
Proof, not profit
Failures the system refused to hide
These are not hypothetical slogans. They are classes of failure the current implementation has been designed and tested to reject without manufacturing successful-looking evidence.
01Rejected
TLS transport failure
The request stopped and produced no dataset or run bundle.
Unavailable data is not silently converted into research evidence.
02Rejected
Corrupted or oversized JSON
Bounded parsing rejected the input with a sanitized failure.
A file existing on disk is not enough for the system to trust it.
03Rejected
Unexpected file inside a run
Exact-tree verification rejected the completed directory.
Extra evidence cannot be slipped into an already defined run.
04Rejected
Symlink or path indirection
The loader refused ambiguous and redirected filesystem paths.
Convenient path resolution does not outrank evidence identity.
05Rejected
Hash or observation mismatch
Canonical identity reconciliation failed closed.
Labels, filenames, and completion markers cannot overrule the bytes.
06Rejected
Broken output stream
The CLI returned a stable unexpected-failure boundary.
Even reporting failures remain visible instead of looking successful.
Current phase roadmap
What is complete, what is next, and what is not approved
The roadmap separates engineering progress from trading permission. Completing a technical layer never automatically unlocks the next operational state.
- 01Complete
Research contracts
Asset, dataset, cost, session, environment, and experiment declarations.
- 02Complete
Market-data evidence
Controlled public capture, exact bytes, canonical normalization, and verification.
- 03Complete
Verifiable run bundles
Atomic publication, exact-tree checks, bounded reload, and offline verification.
- 04In progress
Experiment run and result identity
Deterministic contracts for binding experiments to observations and typed metrics.
- 05Planned
Synthetic experiment runner
A tightly bounded in-memory proof before historical research execution.
- 06Planned
Historical multi-asset validation
Time-respecting experiments across additional assets after the runner is proven.
- 07Not approved
Paper evaluation
Requires separate evidence, controls, and an explicit future review.
- 08Not approved
Live trading
Not part of the current system and not authorized by research progress.
Direct answers
Questions a skeptical visitor should ask
The project is easier to trust when its current limits are answered directly instead of hidden behind architecture diagrams.
Does the system trade?
No. It does not place orders, manage positions, connect to a broker, or provide entry and short permission.
Does it make money today?
No. There is no live trading, fund, signal subscription, or software revenue. The current output is research infrastructure and verifiable evidence.
Why build infrastructure before strategies?
A profitable-looking backtest is weak evidence when the data, code, assumptions, and result history cannot be reproduced. The lab builds those controls first.
Why start with BTCUSDT?
It provides a continuous, liquid, public-data environment for proving the first end-to-end lifecycle. It is a controlled starting point, not the final asset universe.
Why call it multi-asset with one concrete adapter?
The contracts and evidence model are asset-neutral. Multi-asset capability is an architecture under validation, not a claim that multiple assets are already running.
Is this a finished product?
No. It is an active proprietary research build. The website documents what is operational, what remains planned, and what is explicitly not approved.
Is the source code public?
The core research implementation is private. This public site presents the architecture, demonstrated boundaries, and research progression without exposing operational internals.
What must happen before paper or live trading?
The project would need completed experiment contracts, a bounded runner, historical and forward validation, operational controls, and a separate explicit approval process. Research progress alone grants no permission.
Repository boundary
The framework and the BTC freezer remain separate systems
The new lab is not a rename or migration of the existing BTC research assistant. It establishes reusable contracts and evidence boundaries without inheriting operational behavior by accident.
- Contracts, data evidence, run identity, verification
- Volatility models, freezer observations, operational validation
- Evidence is not execution authority
- Future validated artifact boundary only
Hard boundaries
What the lab cannot authorize
The absence of an execution layer is a design requirement, not an unfinished trading feature.
- No experiment execution yet
- No feature or model runner
- No strategy selection or approval
- No freezer-state mutation
- No paper or live trading
- No position, sizing, leverage, or order API
- No credentials or private exchange endpoints
- No automatic retries or alternate providers
- No database, scheduler, server, or deployment requirement
- No dependency on the separate BTC research repository
Next build
Move from evidence identity toward synthetic experiment proof
The next increments remain declaration-first. Results will gain deterministic identities before any real experiment runner is introduced.
Experiment run identity
Bind one exact ExperimentManifest to declared dataset-observation identities without executing code.
Typed result evidence
Record deterministic research metrics while keeping evidence separate from model or strategy approval.
Synthetic-only runner
Only after the run and result contracts are frozen, add a tightly bounded in-memory execution proof using synthetic data.