Metrics
Metrics build the strategy report — the per-coin tables the model reads. Every cell is a column: a closed pairing of metric × transform × timeframe (plus optional window, offset, bars, and transform-specific knobs). There is no free-form formula language.
Authored on the strategy. Bound agents get the materialized report. Conditions and Orders may only reference headers that exist on this report’s post-state.
Column = metric × transform × timeframe
[× window | offset | bars | side | inputs | ordering]
Headers are system-generated from that composition (including _ltf / _htf, _dev, _oN tokens). Illegal (metric, transform) pairings fail at compile.
Metric families
Family is authoring guidance — legality and formatting key off the metric’s typed output, not the family label.
| Family | What it describes |
|---|---|
| Price | Bar OHLC, last/mark/oracle, spot closes, bar forming/closed |
| Momentum | Impulse and pace — RSI, MACD, stoch, MFI, multi-horizon changes, … |
| Trend | Direction and persistence — ADX, SMAs/EMAs, alignment, crosses |
| Volatility | Magnitude — ATR, ATR %, Bollinger width, squeeze, … |
| Volume flow | Participation — volume, RVOL, CVD, buy pressure, … |
| Derivatives | Perp positioning — funding, OI, leverage demand |
| Structure | Location and levels — %B, channels, VWAP-style structure, zones |
| Regime | Platform-classified trend / vol / momentum environment |
| Crowd | Aggregate player positioning and related crowd facts |
| Derived | Cross-family classifications and convergence facts |
The live catalog (builder / MCP) is the authority for codes, glosses, and units. Worked metric × transform sketches by family: Metric examples.
Timeframe
Every column addresses a timeframe reference relative to the strategy’s anchor candle (the strategy timeframe).
| Reference | Meaning | Header token |
|---|---|---|
| Anchor | The strategy’s own timeframe | (none) |
| Lower | One rung down the served ladder | _ltf |
| Regime | The strategy’s regime timeframe (HTF read) | _htf |
| Absolute | A pinned timeframe literal from the enabled set | concrete TF in the header |
Relative refs slide when the strategy anchor changes — the same column keeps meaning (“one rung below”) rather than a frozen interval. Absolute pins a concrete TF.
Rung vs anchor:
| Rung | Relation to strategy TF |
|---|---|
| Above | Longer interval than the anchor (e.g. regime / higher absolute) |
| At | Same as the strategy timeframe |
| Below | Shorter interval (lower rung or faster absolute) |
The concrete mapping for lower / regime is server-resolved per enabled anchor so the picker hint and the money path cannot disagree.
Read: Confirmed vs Developing (bars)
Candle-series transforms carry an optional bars selector:
| Stored value | Label | Meaning |
|---|---|---|
closed | Confirmed | Newest bar that had completed at the strategy’s close — cannot move afterwards |
all | Developing | Admit the higher-TF bar still in progress at the strategy’s close — repaints until that bar completes |
| (unset) | Default rule | See below |
Default rule (effectiveColumnBars)
If you do not store bars:
- Column timeframe above the anchor → Confirmed (
closed)
(A higher-TF bar is still forming at the anchor’s close; admitting it would decide on a bar that repaints.) - Column timeframe at or below the anchor → Developing (
all)
(Series as the frame carries it — forming bar on a live/display frame; at decision close of the anchor itself, nothing is in progress.)
An explicit Confirmed or Developing stands at every rung.
What Developing costs
A Developing read above the anchor is provisional and single-frame:
- It holds for one close frame only
- It cannot carry a condition verdict
- It cannot take the exit role
At or below the anchor, Choosing Developing mostly changes what the live report shows (admits the forming bar and can repaint); at the strategy’s own close there is no forming bar to admit.
Confirmed at or below the anchor: on the live report it drops the bar in progress (value can differ from the “as carried” series); at strategy close it matches what the column would read anyway.
Served report phrasing: Confirmed → “completed bars only”; Developing → “includes the bar still forming”. Developing columns also get a _dev header token.
Window and offset
| Param | Used by | Meaning | Defaults |
|---|---|---|---|
| Offset | value | Bars before the latest; 0 = current resolved value | 0 |
| Window | trajectory, aggregate, efficiency, maxShare | How many non-null observations the transform spans | see each transform |
Offset indexes newest-first: 0 is the newest slot; N is N bars back. Absent or short series → null for that slot. Offset > 0 adds _oN to the header.
Window counts observations / points (after dropping nulls), not “calendar minutes”. Efficiency is special: window is points, and N moves need window = N+1 (default 21 = classic period-20 Kaufman ER).
Transforms (closed set of 17)
Only registered transforms may build a column. Each accepts specific output kinds (and sometimes units / non-negative range). The builder and MCP discovery only offer legal pairs.
Core series / scalar
| Transform | What it does | Authorable params | Notes / defaults |
|---|---|---|---|
| value | One reading at an offset | offset, bars | output = base[t − offset]; default offset 0 |
| trajectory | Recent build-up + rising / falling / flat | window, bars | Default window 4; emits slots + *_trend |
| aggregate | Mean over a window | window, bars | Default window 24; authorable mode is mean only |
| efficiency | Kaufman Efficiency Ratio — net move ÷ path length | window, bars | Default window 21; needs ≥2 points; flat path → null; header *_er |
| maxShare | Max ÷ sum over the window — “one spike or even?” | window, bars | Default window 24; non-negative metrics only; header *_maxShare |
Classification / events / location
| Transform | What it does | Params |
|---|---|---|
| classifyZone | Thresholded zone (overbought / oversold / neutral) | bars → *_zone |
| classifyState | Discrete state classification | bars → *_state |
| crossDetect | Crossover event (Bullish / Bearish) | bars → *_cross |
| bandTouch | Price proximity to canonical upper/lower bands | bars → *_touch |
| distance | % from current price to the base level | bars → dist_* |
| spread | Signed % gap between base and one operand metric | inputs (required, one candle-backed metric at the same TF), bars → *_…_spread |
Universe and structure zones
| Transform | What it does | Params |
|---|---|---|
| rank | Ordinal of this coin in the tracked (active) universe for the metric — not the builder’s preview cohort (Overview · Universe) | ordering (optional) — see below. No historical offset — current values only |
| count | Cardinality of an entity set (e.g. active structure zones) | (none) → *_count |
| nearestZoneType | Type of nearest zone on a side | side required — support | resistance |
| nearestZoneRange | Low–high price range of that zone | side |
| nearestZoneDist | Signed % from price to zone midpoint | side |
| nearestZoneAge | Whole hours since that zone was detected | side |
Rank ordering
| Ordering | Label | Meaning |
|---|---|---|
hi | Highest | Most positive / top of the signed scale |
lo | Lowest | Most negative / bottom |
far | Furthest from zero | Largest magnitude |
near | Closest to zero | Smallest magnitude |
Magnitude pair (far / near) is offered only where the metric can be negative. On a proven non-negative metric it would duplicate Highest/Lowest, so it is dropped.
Chains
Some columns are a chain: an inner relational transform (distance or spread) whose per-bar series is consumed by an outer series transform (trajectory, aggregate, efficiency, maxShare) — or by rank as a cross-sectional outer.
One shared params object covers the union of both transforms’ knobs (e.g. distance × trajectory takes window / bars from the outer even though distance alone has no window).
What the report is
The report is the strategy’s perception table — the ordered briefing the model (and Conditions / Orders markers) read for a coin. It is not the Signal rules scorecard: report membership shapes perception (inReport); allocation / Required on the scorecard stay a separate Policy axis and are not auto-rewritten when sections change.
One report = an ordered list of sections. Section order = prompt order. Each section is a titled panel of columns. Headers stay system-generated from metric × transform × params — there is no user alias on a column. When the same header appears in more than one section, Conditions and Standing Orders markers use section-qualified addressing ({sectionKey, header}).
Confirmed vs Developing is a column bars choice (above), not a report-level dial.
Section anatomy
| Kind | Key | Authorable content | Subject |
|---|---|---|---|
| Platform | Canonical include… key (e.g. includeRsi) | Selectable + orderable only — title, notes, columns, and subject are locked to the code-resident template | Always the evaluated coin |
| Custom | Server-minted custom:<uuid> (stable across edits; fork remints) | Title, optional notes, ordered columns | Evaluated coin (default) or one benchmark roster ticker |
Custom fields
| Field | Wire / shape | Meaning |
|---|---|---|
| Title | title | Display label — trimmed, single-line, 1–60 chars |
| Notes | notes (string | null, required-nullable) | Author’s prose read of the panel (why it exists). Reaches the prompt beside provenance. Cap 400 chars per section; whole-report note budget is operator-config (live default 3200 chars). Omitting the key on save is rejected — send null to clear |
| Columns | columns[] | Ordered metric × transform × timeframe (+ knobs). Blank-authored; no platform-template lineage field |
| Subject | Authoring wire: benchmarkTicker: string | null. Runtime / materialized: SectionSubject = evaluated-coin | { kind: 'benchmark', ticker } | Which instrument the section’s columns resolve against. null / evaluated-coin = the coin under evaluation |
Platform rows carry no title, notes, columns, or subject binding at rest (schema + validation). Some platform modules are opt-in only (not backfilled onto existing strategies) — e.g. perp/spot flow, market breadth, reference pairs. Live catalog / builder is authoritative if the set grows.
Canonical platform order (abbreviated): Price action · Sub-timeframe · RSI · MACD · Volume · Volatility · Bollinger · Moving averages · Stochastic · Funding · Open interest · Relative strength · Support/resistance · Trend strength · MFI · CVD · Higher timeframe · MTF confluence · Regime · Crowd · CVD–crowd convergence · Structure zones · Perp/spot flow · Market breadth · Reference pairs.
Gallery templates → custom
Gallery entries (operator-synced) copy title + columns into a plain custom section — no live link back. Template edits never fan out to existing copies.
| Key | Title | Columns (value @ anchor) |
|---|---|---|
momentum-composite | Momentum Composite | RSI14 · MACD · STOCH_K |
volatility-trend | Volatility & Trend | ATR · ADX · BB_WIDTH |
get_strategy_section_template / the builder gallery list the live set.
Create seeds
A new private draft seeds four platform sections in canonical order: Price action · RSI · MACD · Moving averages. Removable afterward — presence, not a hidden always-on path.
Report functionality
| Behavior | Rule |
|---|---|
| Prompt order | Array position of sections = briefing order |
| Header identity | System-generated; benchmark binding does not affix the ticker into the header — the section names the instrument |
| Ambiguity | Same header in two sections → Conditions / Standing Orders markers require section qualification |
| Conditions / Orders | May only reference headers on this report’s post-state; markers resolve to the section subject’s cell (evaluated coin or benchmark) |
| Signal scorecard | Separate; inReport is perception status only — not allocation |
| Materialization | Bind / rebind / propagation write a dense agent copy of the full report (sections + columns + subject + notes). Money path reads the agent copy. Strategy edits replace bound agents’ report as a unit |
| Fork | Deep-copies the report; custom keys are freshly minted |
| Preview | Builder / MCP preview resolves the draft report over a universe cohort (Overview · Universe). Preview cohort ≠ runtime tracked universe for rank. Benchmark rows stay locked to their instrument when the preview coin changes |
| Fetch | Report-driven: each subject (evaluated cohort vs each distinct benchmark ticker) fetches what its own sections declare |
Budgets (authoring)
Enforced on every report create/update from platform config (live discovery returns the same numbers). Violations reject the write — no silent truncation. Live defaults from vocabulary:
| Budget | Live default | What it counts |
|---|---|---|
| Sections | 32 | Platform + custom rows in the report |
| Columns / section | 32 | Columns inside one section |
| Column lookback | 32 | window + offset (candle-fetch depth) |
| Distinct timeframes | 8 | Resolved concrete TFs across the report (strategy TF ∪ derived rungs ∪ absolutes) |
| Estimated tokens | 32000 | Preview render estimate |
| Report note chars | 3200 | Σ authored section notes |
There is no separate total-columns budget beyond per-section × section caps.
Benchmark / subject
Benchmark is a per-custom-section subject, not a strategy-wide setting. Multiple benchmarks = multiple custom sections (each bindable independently from Conditions).
Modes
| Subject | Meaning |
|---|---|
Evaluated coin (benchmarkTicker: null) | Every column resolves against the coin under evaluation — byte-identical to unbound custom / all platform sections |
Benchmark (benchmarkTicker: "<TICKER>") | Every column in that section resolves against one active roster instrument (crypto or TRADFI). The section renders one row — the benchmark’s — never the cohort’s rows |
Self-benchmark (binding BTC while evaluating BTC) is legal and un-special: values coincide; no alternate path.
What it is not
| Term | Role |
|---|---|
| Benchmark section | Author-bound subject — addressable by Conditions and Standing Orders markers; can gate a trade |
| Majors | Platform-fixed BTC/ETH comparison rows in some prompts — advisory only, not rule-addressable; never called “benchmark” in product copy |
| Universe preview coin | Scopes own-coin preview tables only — does not move benchmark readings |
Resolution and legality
- Binding validated at authoring against the active coin universe — unknown / inactive ticker fails fast with a typed error (nothing persists).
- Rejected on a benchmark-bound section (save + discovery agree):
- Enrichment-stage metrics (crowd / session-relative and related enrichment homes — no meaning off-subject)
- Rank (cross-sectional), including chained rank — ordinal resolution is cohort-entangled
- Headers stay the same tokens as own-coin; address via
{sectionKey, header}when needed. - Operand ≡ rendered cell: a condition or Standing Orders
{section.header}marker over a benchmark column reads the benchmark’s value, never the evaluated coin’s, and never silently substitutes. - Absent benchmark data (e.g. closed TRADFI market, stale level after a read): operand null, clause FALSE (can hold a Required gate). Unread / broken feed (no read attempted): UNRESOLVED — not a decided FALSE under
NOT. A later-delisted roster ticker is a non-blocking viability finding on audit; saves / propagation still succeed. - Platform sections cannot carry a benchmark binding.
- Subject survives ordinary edits, MCP compile/apply, revision snapshot, and agent materialization — it is never silently cleared.
When to use
Pin a reference instrument the thesis depends on (e.g. “only act when BTC’s change / RSI panel agrees”) while own-coin sections still describe the evaluated name. Prefer spread / distance on the evaluated coin for relative maths inside one subject; use a benchmark section when the second instrument must be read as its own panel and gated independently.
How Metrics relate to the rest
| Axis | Relationship |
|---|---|
| Conditions | Boolean trees over these headers; Developing-above cannot carry verdict / exit |
| Orders | Standing Orders {markers} resolve to these headers (and named conditions) |
| Signal rules | Separate scorecard (seeds Off; report ≠ allocation) — not auto-rewritten when report membership changes |
← Strategies overview · Metric examples · Conditions · Orders