How it works
From one sentence to a backtested strategy
HyperPM turns a PM's one-line request into a strategy that runs, passes the gates, is backtested and can be saved as a version. Agents make the judgement calls; the platform's deterministic code does the validation and the backtests; every step is recorded and can be replayed. This page shows the path, who does each step and why the result can be trusted. Every number on it is read from the running system.
Enter the access code on the Agent page first, then reopen this run.
–
strategy families
–
categories
–
agents
–
tools
–
latest regression passed
–
backtest engine
Six steps from a sentence to a backtest report
The tag on each step says who does it: the user, an agent (a model) or the platform (deterministic code). Models only do what needs judgement; the platform does the rest on its own.
- 01user
State the request
One sentence with the entry logic, such as “BTC 4h, go long on the 20/50 moving-average cross, ATR stop”. When there is no entry logic at all, the main agent asks one question instead of guessing.
what you see · a message in the conversation; the board on the right fills in as the run progresses
- 02platform (deterministic)
Parse it into a specification
Before any code, the platform parses the request into a structured specification: symbols and bar size, entry family, exits and risk, parameters. Every later step is checked against it.
what you see · the Spec tab on the board
- 03platform (deterministic)
Load the skill pack
By the entry family in the specification, one strategy family pack is loaded into the coding agent: how to recognise the family, its parameter conventions, how to implement it, the usual pitfalls and a reference module. A new strategy type is a new pack, not a change to the agent.
what you see · the “load capability” row in the activity tree, linked to the skill library
- 04agent (model)
Write the module
The coding agent writes the module from the pack, or patches an existing one symbol by symbol. It can call only a handful of tools and never touches the engine, the market data or the database.
what you see · the Code tab updating live
- 05platform (deterministic)
Gates, then the backtest
Every revision goes straight through the static gate (the syntax tree is read, nothing is executed) and a fidelity check against the specification; only then is it backtested, inside an isolated worker sandbox. Changing an existing module, or approval mode, shows an approval card before compute is spent.
what you see · the validate and backtest rows in the activity tree, the approval card, the Result tab
- 06agents + platform
Report, analysis, tuning, library
The platform computes the report and the robustness checks; the analysis agent may only cite numbers from that report. The tuning agent proposes candidates and the platform backtests and ranks them. The data agent answers market and documentation questions, and every number it gives is checked against the tool results. A version you like is saved to the library in one click.
what you see · the Report, Tuning and Chart tabs, and the strategy library
Division of labour: five agents, one job each
Each agent has its own few tools, budget and prompt; only the main agent sees the request first. The engine, the market data and the database are not tools, so a model never reaches them.
The full tool list with argument schemas is on the Architecture page.
Why the result can be trusted
Judgement goes to the model; verification never does.
- Specification before code: every revision is checked for fidelity against the specification and sent back when it drifts.
- Rejected without running: the static gate reads the syntax tree, so forbidden imports and constructs are refused before anything executes.
- User code runs only inside the worker sandbox; the API process never executes strategy code.
- Every number has a source: the numbers in analyses, tuning recommendations and data answers are checked against what the platform computed, and a mismatch is sent back for a rewrite.
- Compute is spent only after a yes: changing an existing module, backtesting candidate parameters and restoring an old version all show an approval card first.
- Budgets are capped: each run has a ceiling on steps, model calls, tokens and wall clock; repeated failures of one tool and idle replies have their own limits, and waiting for approval does not count.
- Regression-tested: every strategy family pack ships with a standard request set that is re-run after changes, and the pass rate is published in the skill library.
HyperPM builds. PM.finance allocates.
HyperPM turns ideas into verified strategies; PM.finance allocates capital to them. A strategy built, gated, backtested and saved here is ready to be presented there.