Radar
Radar keeps one or more agents on duty for a single coin and fires real trades from each agent's bound strategy when the market qualifies.
Create an agent first. Deploy is separate: Radar is continuous coverage for that coin; Arena is timed prediction games; the trade terminal is you taking the wheel.
← Agents · Strategies
What a deployment is
A Radar deployment policy is scoped to (you, coin):
| Field | Role |
|---|---|
| Coin | The anchor. Regime, qualification, and fires are always about this coin. |
| Deployment timeframe | Where the platform reads the coin's confirmed regime for slot selection |
| Enabled | Pause without deleting slots (false skips the policy at sweep) |
| Slots | Ordered agent rules (plus optional default catch-all) — at most 10 total |
| Revision | Optimistic concurrency token — echo it on the next replace, pause, or delete |
Deploying does not spend another agent slot. The same agent can sit on several coins (subject to the platform coin cap) and still appear in Arena or on the terminal.
Standing Radar authority is what fires trades on confirmed-regime / qualification edges. Preview resolution is a dry-run against the same resolver; it writes nothing.
Slots
Each slot binds an agent and an optional min conviction trade bar.
Rule vs default
| Kind | Priority | Conditions | Role |
|---|---|---|---|
| Rule | Unique positive integer; lowest wins | At least one; at most one hours and one regime | Match only when every attached condition is true |
| Default | null | Empty | Catch-all when no rule matches — optional, at most one |
Resolution picks exactly one on-duty agent: first matching rule by priority, else the default, else idle (no agent).
Agents that are not eligible (for example not active) are filtered before selection. If every candidate is filtered and nothing remains, the policy is idle with reason all slots filtered.
Min conviction
Per-slot min conviction is Radar's participation dial for that agent on this coin (0–1 fraction, shown as a percent on the dial).
- A number sets a floor: capital only deploys when the live trade reading clears that bar.
nullmeans no Radar-side conviction floor on the slot — the agent's own rails still apply.- The resolved bar (and which layer decided it) is server-computed. You read it; you do not re-derive it.
Conditions
A rule slot may carry hours, regime, or both. With both, both must match (AND). Radar owns this vocabulary; Arena session conditions are not accepted here.
Hours (UTC membership)
Wall-clock gate as two sets, not a from/to range:
- Hours — UTC hours
0–23(non-empty, unique) - Days — UTC weekdays
0(Sunday) –6(non-empty, unique)
Membership is the whole predicate. A gapped schedule is natural (hours: [7, 13]). Overnight is a list across midnight ([23, 0, 1]), not a special wrap form.
Regime
Match against the coin's confirmed regime at the policy's deployment timeframe:
| Regime | Typical shape |
|---|---|
bull_expansion / bear_expansion | Directional expansion |
bull_ranging / bear_ranging | Directional range |
contraction | Compressed / quiet |
volatile | High-volatility regime |
fallback | Classifier fallback |
Optionally set a regime min conviction floor on the condition (uncertain → low → medium → high → maximum). Reachable conviction tiers differ by regime (for example contraction only reaches medium; fallback reaches uncertain/low) — the platform gates options accordingly.
If no confirmed regime is cached for that timeframe, every regime condition is false and the live read reports cold regime.
Deployment timeframe
This is not the strategy's signal timeframe. It is the TF used to read confirmed regime for who is on duty.
Allowed pins: 1m, 3m, 5m, 15m, 30m, 1h, 2h, 4h, 8h, 12h, 1d, 3d, 1w.
Relative strategy timeframes (_ltf / _htf) still live on the playbook. Radar selection freezes the regime anchor to the coin at this deployment TF.
Live resolution (resolves now)
Every read of a policy carries a server-computed resolves-now projection: what the sweep would do right now. The client renders these fields; it does not recompute selection.
Card sections
Dashboard grouping priority — an open position outranks idle sub-states (live money wins, even under a paused policy):
| Section | Meaning |
|---|---|
| In position | A live trading position is open on the coin |
| Blocked | An agent is on duty but its account admission is blocked — nothing is being scanned |
| Scanning | An agent is on duty, the coin is flat, watching for a qualified edge |
| Idle | No agent trading; the sub-state is in reason |
Rotating means a position is open and its owner is not the current on-duty agent — the next selection has already moved while the incumbent still holds the coin. Manual / pre-fill positions have no owning agent and are never rotating.
Idle and blocked reasons
| Reason | Meaning |
|---|---|
| Cold regime | No confirmed regime at the deployment TF — every regime condition is false |
| No rule match | Regime/time known; no rule matched and there is no default |
| All slots filtered | Every candidate agent was ineligible before resolution |
| Policy disabled | enabled is false — slots retained, sweep skips the policy |
| On duty but position blocked | On-duty and qualified, but a (user, coin) open-position mutex blocks a new fire |
| On duty but edge spent | On-duty and flat, live reading would qualify, but the edge baseline is already advanced — waiting to re-arm |
| Account blocked | On-duty agent's account admission episode suppresses triggers on every coin it covers |
| Platform paused | Platform Radar kill-switch is off — maintenance; not something you fix on the policy |
Qualification and fire markers
When an agent is on duty and the coin is flat:
- Qualified — last known flip-baseline verdict for the on-duty agent (
nullif never evaluated or idle) - Qualification block — which gate is failing when not qualified (aggregate, required-count, ATR floor, required condition false, verdict opposes direction, candidate levels unavailable, …). Copy is server-projected.
- Cooldown until — fire-cooldown expiry when cooling down
- Last flip / last fire — timestamps for the not-qualified→qualified edge and the last enqueued Radar fire
Held condition verdict and verdict dwell (how many consecutive resolutions the side has been held) surface debounce when the strategy carries a verdict — display-only.
Close decision (when the strategy decides on close)
If the on-duty agent's trigger decides on strategy bar close, the live per-minute qualification rail does not decide entry. Resolves-now then carries a close decision object for that pair:
| Outcome | Meaning |
|---|---|
| Fired | Close qualified over an unconsumed baseline; fire enqueued |
| Not qualified | Close did not fire — either a failing gate, or a consumed edge (qualified but baseline already advanced) |
| Missed | Decision window passed before a sweep reached the bar — no measurement |
State relative to the next decision is waiting (last close decided) or deferred (a closed bar still owes a sweep).
Activity (why it has not fired)
The activity summary answers "why has this agent not been firing?" in one read:
- Cause groups — recurring
(event, cause)rollups inside a reported window (gate crossed/blocking, idle reason, fire disposition, evaluation outcome) - Curve digest — recent evaluation ring for the on-duty agent (how far scores sit from the minimum) — the ring window is separate from the cause window
- Recent events — last key transitions (not bounded by the cause window)
The journal is a transition log: a gate that blocks continuously without crossing again may have no group in the window. What is true right now is always resolves now on the deployment.
Pause vs withdraw
| Action | Effect |
|---|---|
Pause (enabled: false) | Sweep skips the policy; slots and revision stay |
Resume (enabled: true) | Policy returns to discovery |
| Delete / withdraw | Removes the whole coin policy — standing autonomous authority for that coin is gone |
Replacing a policy is a full slot-tree rewrite. Always pass the revision you last read (null only on first deploy); a stale revision is a conflict and writes nothing.
Cap and fleet
Fleet roll-up reports coins deployed (paused included — that is the cap-meter denominator), section counts, how many agents are on duty, and your live per-user coin cap (platform-configured). Stay under the cap when adding coins.
How this fits the stack
| Layer | Owns |
|---|---|
| Strategy | Metrics, conditions, orders, signal rules, entry, levels, exit |
| Agent | Brain, bound strategy, risk rails, one account slot |
| Radar | Who is on duty for this coin, when, at which regime TF, and at what conviction floor |
Commander and MCP use the same concepts: list / get / preview / upsert / delete Radar deployments and read activity.