The Anatomy of a Raptor-Grade Trading Signal — Decoded

By Sebastian Smith Published custom Updated custom

Open the RaptorBit AI workspace and you’ll see signal cards that look almost deceptively simple — one direction tag, one probability band, a sentence or two of reasoning. Behind that card, though, lives a 23-field data structure, a four-layer validation gauntlet and a decision scaffold that reads more like an aircraft checklist than a classic “AI trade idea”. This article dissects the full anatomy of a raptor-grade signal, field by field.

Why we document this at all

Most trading platforms treat their signal format as a trade secret. We think the opposite: the only way a trader can judge, overrule or trust a signal is if they understand its anatomy. If you cannot explain the signal in your own words after reading this article, we haven’t done our job.

The five layers of a signal card

Every signal lives inside a card. The card itself is organised into five layers, top to bottom.

Layer 1 — The identity row

The identity row is the “who, what, when” of the signal. It contains:

Signal ID — a globally unique ID (format r7k2m9-YYYYMMDD-NNNNNN). You can quote this ID in any support conversation or dispute.
Instrument — the symbol and venue. Example: EURUSD @ HawkMarkets.
Timestamp — printed in your local timezone and in UTC. Milliseconds are kept in the audit trail even if the UI rounds to seconds.
Signal class — one of Breakout, Mean-reversion, Trend continuation or Event-driven. The class decides which internal checklist runs.

Layer 2 — The verdict row

This is the row most people read first. It is intentionally short.

Direction — Long, Short, or Wait.
Probability band — High, Mid, Low. Not a false-precise number like 72.4%.
Horizon — the window the signal is valid for (seconds, minutes or hours).
Recommended size — expressed as a percentage of the deposited capital pool. Never a raw monetary number, so your eyes and your psychology aren’t tricked.

Layer 3 — The reasoning strip

A single plain-English paragraph. Example:

“Price just rejected the overnight high on strongly asymmetric order flow, with volatility compressed below the 20-day average and no scheduled macro print in the next 90 minutes. Structure supports a short back to the overnight VWAP.”

The reasoning strip is produced by a dedicated explanation model whose only job is to turn the raw signal state into a human-readable sentence. It never invents facts: every claim in the strip maps to a field in the underlying signal object. If you want to see those raw fields, open the Debug drawer on the card.

Layer 4 — The pre-mortem

A one-sentence note on what would invalidate the signal if it happened. Example:

“Invalidated if price prints above the overnight high with volume > 1.5× the 10-day average, or if a high-impact macro headline hits before the horizon closes.”

The pre-mortem is written before the trade, by the same model that generates the signal. It is logged in the audit trail even if you dismiss the signal. If the market later invalidates it, the audit shows whether the invalidation condition matched exactly. This is where trust is actually built.

Layer 5 — The action row

Activate — send the order to your broker, with the recommended size.
Resize & activate — adjust the size before sending.
Paper-trade — run the signal through the simulator, no live order sent.
Dismiss — log the dismissal with your reason. Reasons are limited to a short list to keep the audit clean.

The hidden fields (available in the Debug drawer)

The debug drawer surfaces the full 23-field signal object. The ones most worth knowing:

order_flow_imbalance — a normalised score between -1 and +1.
structural_anchor — which level the signal is pinned to (previous day high, weekly VWAP, 50 EMA, etc.).
regime_tag — the current volatility regime at the moment of signal creation.
news_veto_check — pass, soft-caution or veto, with the headline(s) that influenced the check.
consensus_depth — how many of the four observation layers agree.
backtest_handle — a pointer to the signal class’s rolling 36-month backtest ID, so you can inspect how similar signals have historically performed.

How a signal is built in order

Observation layers emit raw features.
Feature store normalises and timestamps everything.
Candidate signal is drafted by the signal engine.
Risk-governor pre-flight checks the candidate against the current pool thresholds and open-position state.
Explanation model writes the reasoning strip and pre-mortem.
Signal object is sealed with a cryptographic hash (hash is written to the audit trail; this is how we prove the card you saw matches what we served).
Card is rendered to your workspace.

Steps 1–6 complete in under 40 ms for most signal classes. Step 7 is bounded by your network and browser.

What makes a signal “raptor-grade” instead of just “a signal”

A signal only earns the raptor-grade tag when all of the following are true:

Consensus depth is 3 or 4 out of 4 layers.
Risk-governor pre-flight returned no amber warnings.
Backtest handle shows a positive expectancy over the trailing 36 months in similar regimes.
News veto check returned pass.
No signal of the same class and direction fired within the past 10 minutes (to avoid serial over-exposure).

Signals that don’t meet all five never show the raptor-grade badge; they still fire, but with a visibly reduced probability band and a note on which bar they failed.

How to use this knowledge

Three habits we recommend:

Read the pre-mortem before the reasoning strip. It forces you to think about failure first.
Open the Debug drawer on any signal you want to override. Nine times out of ten, the number that would change your mind is already in there.
When you dismiss, use the predefined reason list. Over months, your dismissal patterns become a mirror of your biases.