Strategies

A strategy is the playbook: what to see in the market, how to read it, when to act, where levels may sit, and how to exit.

Build for the conditions you care about — trend, range, expansion, and more. Bind the playbook to an agent, then deploy that agent on Radar, in Arena, or on the trade terminal.

Author in the Strategy Builder, or start from Commander in plain language (compile → review → apply) and refine after.

Identity

Field	Role
Name · tagline · description	How you recognize the playbook in the library
Primary timeframe	Authored main candle — see Strategy timeframe below
Regime timeframe	Ladder successor of primary — server-derived, read-only
Cadence	Persona badge derived from primary TF
Revision	Optimistic concurrency — content mutations carry it; stale writes conflict
Active	Whether the strategy may be bound / stay live under quota
Fork lineage	forkedFromStrategyId when this playbook was forked

Strategy timeframe

The primary timeframe is the strategy’s own bar. It is the anchor for:

• Column at-rung reads and Confirmed/Developing defaults (Metrics)
• Condition holds and soft-stop closes (Conditions · Exit policy)
• Entry decisions (every authorable trigger decides on this bar’s close)

Authorable main candles

Selection is against the platform’s enabled timeframe set (not a frozen compile-time list). A TF may be the main candle only when it is enabled and both neighbors exist on that ladder:

Requirement	Why
In the enabled set	Non-ingested series would always read empty
Has a lower rung	Lower-TF / _ltf signals and columns need a predecessor
Has a higher rung	Regime / _htf context needs a successor — never collapses onto itself

Floor and ceiling of the enabled ladder are therefore not authorable as main candles.

Regime timeframe

Always the next higher enabled rung above primary. Not authored; changing primary moves regime with it.

Cadence (persona)

Display-only projection from primary TF:

Persona	Primary TF band
Scalper	≤ 15m
Intraday	30m–2h
Swing	4h–12h
Position	≥ 1d

Changing timeframe

A primary-TF change is a structural edit — server requires an explicit confirm. It reshapes the anchor for briefing columns, conditions, entry, and soft stop. Bound agents feel it on the next successful apply / propagation.

Column-level timeframe pins (anchor / lower / regime / absolute) stay on Metrics.

Universe (preview cohort)

The strategy does not persist a fixed coin list. Runtime evaluation uses the platform’s active universe (and deploy surfaces pick coins / sessions separately).

What the builder calls universe select scopes the report / conditions preview — which coins the draft tables resolve over while you author:

Mode	Meaning	Cap
(absent)	Pool-wide — all active coins	—
Ranked	Top-N by 24h volume, optional category filter	≤ 100
Explicit	Named ticker set, validated against the active universe	≤ 50

Ranked category filter (when set): ALL · CRYPTO · L1 · MEMES · DEFI · TRADFI · STOCKS · INDICES · COMMODITIES. Crypto default applies server-side when ranked category is omitted.

Standing Orders lens is separate: an optional single ticker for marker values in the trade register — the server never invents a cohort coin for that.

Cross-sectional transforms like rank still mean “ordinal in the tracked universe” at evaluation time — not “ordinal in your last preview selection.” Preview cohort ≠ saved strategy identity.

Briefing vs Policy

Two layers, one strategy revision:

Briefing — what the agent sees

Axis	Role
Metrics	Report columns — metric × transform × timeframe; sections + benchmark subject
Conditions	Named boolean reads, verdicts, Required, optional exits
Orders	Standing Orders prose ({markers}) — guidance, not enforcement

Policy — what the platform enforces

Axis	Role
Signal rules	Scorecard weights, Required flags, three gates
Entry policy	When entries may fire — and where level orders rest
Trade levels	Floor, hard stop, Min R:R for constructed stops/targets
Exit policy	Break-even, trailing, time decay, soft stop

Materialization

Layer	Owns
Strategy	The revisioned source of truth for Briefing + Policy
Agent	A dense materialized copy at bind / propagation — the money path reads the agent copy
Open trades	Keep the snapshot from bind / last propagation mid-flight

Editing the strategy updates bound agents on the next successful apply / propagation. There is no runtime merge back from agent → strategy.

Lifecycle

Action	Meaning
Create	New PRIVATE playbook; Policy dials take platform seeds where omitted
Edit	Whole-axis updates under revision; Briefing and Policy save together
Fork	Copy at a revision (optional name; default ⟨name⟩ (fork)); lineage retained
Archive	Deactivate — revision + confirm; frees active quota
Restore	Thin path when content is still viable; otherwise REPAIR_REQUIRED → compile/apply restore flow
Compile → apply	Commander / MCP plan token flow — see below

Active PRIVATE strategies sit under a per-user quota (platform-configured). Bound-agent and open-position counts surface on the strategy for blast-radius awareness.

Authoring via Commander

Same contract as MCP and the Strategy Builder save path:

1. Compile a CREATE / UPDATE / RESTORE payload → approved plan + review (blast radius, viability, bound agents). Parks a planToken (~five minutes). Does not mutate the live strategy yet.
2. Review diffs / mismatches / open-position awareness.
3. Apply with the exact planToken + confirm. Server re-derives dense scorecard checks; mangled or stale tokens refuse.

Focused one-rule edits, fork, archive, and restore still use revision + confirm rules. Prompt patterns: Prompt formula. Deep dive: Commander overview.

Briefing axes: Metrics · Metric examples · Conditions · Orders.

How it fits deploy

Create ≠ deploy. Binding a strategy to an agent does not put capital at risk. Deploy chooses the surface: Radar (coin autopilot), Arena (session grids), or the trade terminal (you approve).

← Introduction · Next: Metrics · Metric examples · Agents