Pre-trade gates before broker submission · public beta, free

Gate every signal. Explain every verdict. Verify every decision.

Your trading bot should not be a black box. Titan shows what came in, what passed, what failed, and what the receipt actually proves before broker submission.

Titan diagnoses signals. Titan does not generate, route, or execute trades. Or check a past trade-history CSV ↓

Category Pre-broker signal diagnostic A hosted API gate for bots, forwarders, and REST clients.
Input Automated signal Your alert, bot, or client sends Titan the proposed order intent first.
Output Allow / deny / receipt Your forwarder handles execution. Titan records what it checked.
Fig. 1 — sample trace / decision receiptsandbox demo account
signalBUY NVDA · the fourth buy signal of the day · 2026-06-10
gatesPASS input and side checks · REJECT Max Daily Trades · downstream broker submission not reached
decisionREJECTED — Max Daily Trades: daily cap of 3 already used
reason labelDaily trade limit reached before broker submission
trace5699daa4-7e1b-49dd-a3e6-b29f8f230dae
proof boundaryProves Titan recorded this decision path. Does not prove broker execution, fill quality, or P/L.
anchorconfirmed in Bitcoin block 953175
Verify a receipt like this in your browser → Eval latency: ~116 ms p50 / ~150 ms p90, measured — /status. No SLA.
No generated signals No funds held No broker keys Titan never submits orders
First action

Run one signal through Titan.

POST /api/public/v1/eval?eval_mode=full is the front door. Send Titan the same kind of payload your bot would send toward a broker, read allow, then open the trace or decision receipt when a trace_id comes back.

minimum request
curl -X POST https://www.titandiagnostics.io/api/public/v1/eval?eval_mode=full \
  -H "X-Titan-Agent-Key: tak_..." \
  -H "Content-Type: application/json" \
  -d '{
    "symbol": "NVDA",
    "side": "BUY",
    "close": 875.50,
    "atr": 14.2,
    "strategy_hint": "breakout_v2"
  }'
what to read first
{
  "ok": true,
  "allow": true,
  "reason_label": "Signal passed Titan's decision gates",
  "trace_id": "3f1df0f05e2843708dcafeba67bcee6e",
  "decision_summary_url": "https://.../analytics/autopsy/3f1d...",
  "trace_viewer_url": "https://.../traces/3f1d...",
  "next_action_hint": "your_bot_may_proceed"
}

What do I send?

At minimum: symbol, side, price, and useful volatility context such as ATR. Do not send broker credentials. The agent key binds the request to your account.

What does Titan check?

Configured gates for duplicate or stale signals, malformed order intent, market/session issues, cooldowns, exposure, sizing, brackets, account state, and broker-rejection patterns when state is available.

What does allow mean?

allow: true means Titan did not find a Titan-side blocker for that signal. It does not mean a broker accepted it or that a trade was placed. allow: false means do not trade; read the reason and next-action hint.

Where is the receipt?

The response includes a trace_id plus trace/autopsy URLs when available. The receipt explains the input signal, gate status, reason label, proof boundary, and what Titan did not do.

§00 · The instrument

Run a signal through the gates.

Enter an order the way your bot would send it. Titan walks it through 26 pre-trade checks in order and stops at the first one that fails — then prints the slip. This one runs in your browser against a simulated flat account: nothing is sent, nothing is stored. For an API-backed simulated check with gate-by-gate output, run a sample eval →.

Side

Simulated flat account — a demo of the shape of the check, not a live evaluation and not a decision receipt. The gate names and their order match the real pre-trade pipeline for automated trading.

TITAN · PRE-TRADE SLIPSIMULATED
Awaiting signal
Fill in the order and run the check.
Client-side demo · nothing submitted, nothing stored.
cleared stopped here not reached or not applicable
How it works

How Titan handles a bot signal.

The strategy creates order intent. Titan evaluates it before broker submission, returns a decision summary with a trace id, and leaves execution to your own forwarder.

Bot signal

Your bot generates a proposed order and sends that order intent to Titan first.

Pre-trade eval

Titan evaluates the signal against configured diagnostic checks before it can reach the broker.

Decision trail

Titan returns allow or block output with a reason, trace id, and decision receipt.

Your execution path

Titan's code contains no order-submission call — a static test fails the build if one appears. Your forwarder, on your machine, is the only thing that talks to your broker.

Direct answers

Questions bots ask before routing through Titan.

Plain answers for people comparing pre-trade checks, bot diagnostics, and decision receipts. The full version is on the FAQ page.

What is Titan Fortress?

Titan Fortress is a hosted diagnostic layer for trading bots. A bot sends proposed order intent to Titan before broker submission. Titan evaluates configured checks, returns an allow or block answer, and records a decision receipt that explains what was checked. It is diagnostics and control infrastructure, not a broker or signal generator.

How does Titan help explain bot behavior?

Titan makes trading bots inspectable by putting diagnostic checks before execution. It can surface duplicate webhooks, stale signals, malformed order intent, cooldown violations, daily-loss breaches, exposure limits, margin/PDT issues, and broker-rejection patterns before your forwarder submits an order. The benefit is clarity and traceability, not a profit claim or loss-prevention guarantee.

Who is Titan for?

Titan is for people building retail trading bots, plus small desks that already have a strategy and execution path. It fits bots that send TradingView alerts, Python signals, or REST requests and need a checkpoint before broker submission. It is not for discretionary trading tips.

Does Titan place trades?

No. Hosted Titan evaluates and records signals; it does not independently place, close, or cancel broker orders. If Titan returns an allow result, your own forwarder or execution code decides what to do next. Your broker remains the system of record for orders, positions, and custody.

Is Titan compatible with my broker?

Titan's public examples are written around Alpaca because the hosted forwarder and CSV diagnostic support Alpaca workflows today. The core pre-trade eval API accepts generic order intent, but broker execution remains in your forwarder. If your broker differs, check the API shape and forwarder boundary before relying on it.

What is a pre-trade risk check?

A pre-trade risk check evaluates an order before it reaches the broker. It can inspect side, symbol, market hours, cooldowns, daily loss, exposure, sizing, bracket validity, and account state. The check answers whether the order should continue, stop, or be reviewed before execution.

What is a decision receipt?

A decision receipt is the record Titan writes for a signal evaluation. It includes the signal, outcome, reason, trace details, and verification path when proof artifacts are available. A receipt proves what Titan recorded; it does not prove broker execution, fills, profitability, or strategy quality.

Reference

How it actually works.

Inspect the request flow, decision receipt, broker boundary, API shape, and limits.

Request flow

Your strategy sends BUY or EXIT intent to Titan. Titan checks it. Your forwarder sends only allowed orders.

Your botSends order intent.
TitanChecks gates.
ForwarderSubmits allowed orders.
BrokerReceives orders from you.
Decision receipt

The receipt shows the signal, result, reason, time, and verification path. It explains why the signal passed or stopped.

Broker boundary

Public evals do not require broker credentials. Titan uses the agent key for account binding and keeps broker submission outside hosted Titan.

  • Titan: checks and records.
  • Your forwarder: submits allowed orders.
  • Your broker: holds the account and funds.
API call

Use an agent key. Titan returns allow or block. It does not trade.

request / pre-trade eval
curl -X POST https://www.titandiagnostics.io/api/public/v1/eval?eval_mode=full \
  -H "X-Titan-Agent-Key: tak_..." \
  -H "Content-Type: application/json" \
  -d '{
    "symbol": "AAPL",
    "side": "BUY",
    "close": 227.18,
    "atr": 3.4
  }'
response / eval summary
{
  "ok": true,
  "allow": true,
  "status": "SUCCESS",
  "eval_mode": "full",
  "coverage_scope": "full_pretrade",
  "limited_coverage": false,
  "reason_code": "WOULD_SUBMIT_ORDER",
  "reason_label": "Signal passed Titan's decision gates",
  "trace_id": "3f1df0f05e2843708dcafeba67bcee6e",
  "next_action_hint": "your_bot_may_proceed"
}

A blocked signal returns "allow": false with the gate name in reason_label. Fetch the full verifiable receipt from /api/public/v1/decisions/{trace_id}. Full walkthrough: the 5-minute quickstart.

Limits

A gate cannot make a bad strategy good. Titan enforces your rules and records what happened — nothing more.

No profit claim

Titan does not predict or improve profitability, market fit, or trading performance.

No signal generation

Titan does not create signals. It evaluates the signal your strategy sends.

Anchors have limits

A Bitcoin anchor proves a record was committed at a known time, not that execution happened.

No broker custody

Titan does not hold funds. Public evals do not need broker credentials, and execution remains with your forwarder.

Receipts are records

They show what Titan checked and decided — not that the decision was right or the trade made money.

Bot failure modes

What can go wrong with a retail trading bot?

Titan is built for practical automation failures, not market predictions. It helps explain what the bot actually sent before the mistake turns into a broker mystery.

TradingView webhook fired twice

TradingView can send the same alert more than once. Titan records the duplicate check before broker submission, so you can see what stopped and why.

AI-generated bot sent a malformed payload

Many operators now use AI to generate Alpaca or TradingView bot code. Those bots can miss required fields, side aliases, sizing, brackets, and stale state. Titan gives you a place to inspect the payload before it reaches a broker.

Signal was stale

A signal can arrive after the market context changed. Titan shows the signal time and whether freshness or session checks affected the decision.

Broker rejected the order

Your broker can still reject an order after Titan passes it. Titan does not guarantee broker approval; it shows Titan-side blockers and likely failure causes before submission.

Config changed and outcomes would flip

Use Deploy Gate before changing settings you rely on. It compares the change against past Titan receipts so you can see what would flip.

You cannot tell what the bot actually sent

A trace shows the submitted signal, normalized intent, gate path, and reason label. The receipt proves Titan's diagnostic decision, not execution, fills, or P/L.

Plans

Pricing while beta is open.

Beta stays free while we onboard early operators. The pricing test is intentionally simple: one active bot/operator, full evals, receipts, and trace history.

Beta is free while we onboard early operators. The likely starter tier is $29/mo for one active bot/operator, including full evals, decision receipts, and trace history. This is a pricing test, not a billing launch.

Beta

Free

Create an agent key, run full evals, inspect decision receipts, and review trace history while beta access is open.

Create account

Starter test

$29/mo

Likely starter tier after beta: one active bot/operator, full evals, decision receipts, trace history, and broker-rejection diagnostics. Final packaging may change.

Create account
Trade history diagnostic

Check an Alpaca CSV.

Upload Alpaca trade history. Titan replays the file through default gates and shows what would have stopped. No account needed.

Processed for this check. Not stored.