Customer Help Center Real data workflows Written by C

C Written by C Dome Terminal field notes

The Dome Terminal Field Manual

Clear, practical documentation for traders who want a calmer workflow: read the market state, verify the data, challenge the idea, control the risk and review the result without turning the terminal into noise.

Download Terminal Start the guide

// field manual · written by C

DOME.DOCS / CLIENT EDITION

Trade from process, not pressure.

A customer guide for setting up the terminal, reading real context, using ORACLE responsibly and building a repeatable review habit.

AuthorC

EditionCustomer Guide

FocusWorkflow

01 / Quick start

First session: set it up, then slow down

The fastest way to get value from Dome Terminal is not to open every panel at once. Start with a clean chart, verify data quality, then add AI and risk checks only after the market context is visible.

Install and open the terminal

Download the app, launch it, and keep the default local-first setup. Your workspace is designed to run on your device, with providers and model options configured inside the app.

Pick one market

Choose a symbol, exchange and timeframe you actually trade. Let the chart load candles before judging any tool. If a feed is offline, Dome should show cached or unavailable status clearly.

Read market state before opinion

Use Quant Brain, order flow, structure, volatility and volume context to understand conditions. The goal is to describe the state, not force a prediction.

Run a pre-trade check

Before placing or simulating a trade, check exposure, session limits, journal patterns and current risk gates. A blocked or insufficient-data state is a useful warning, not a bug.

Journal the decision

Record the setup, reason, emotion, risk and outcome. Over time, your journal becomes the best source for finding repeated mistakes and real base rates.

02 / Daily workflows

Use the terminal around decisions, not noise

Each workflow below is built to reduce guessing: inspect the market, verify risk, ask for grounded explanation, then record what happened.

Analyze a market

Open Superchart, confirm candle source, then inspect structure, volatility, volume zones and order-flow reads before asking for an opinion.

Start with higher timeframe context.
Mark swing levels and invalidation zones.
Check source: live, cached or unavailable.
Use order flow as context, not as a blind entry trigger.

Terminal habit

Do not start from ORACLE. Start from the chart, then let ORACLE summarize what the terminal can actually see.

Ask ORACLE

Ask for a market summary, contradiction check, risk review, journal reflection or explanation of what changed since the last read.

Ask "what data is missing?"
Ask for counterarguments and weak points.
Ask it to separate facts from interpretation.
Never ask it to invent entries or certainty.

Best prompt

"Use only available terminal context. Cite missing data. Explain the risk and the counterargument."

Approve risk

Use position sizing, portfolio exposure, Committee checks and session limits to stop impulse decisions before they reach live risk.

Respect hard blocks and unavailable states.
Paper mode before live risk.
Reduce size in volatile regimes.
Check open exposure before adding correlation risk.

Decision rule

If data quality, live equity or policy gates are not available, the correct result is caution or block.

Review the journal

After trades, tag what actually happened: setup, plan quality, emotion, mistake type, outcome and whether the rule was followed.

Tag setup and mistake type.
Record followed vs ignored plan.
Review weekly behavior patterns.
Look for repeat mistakes, not excuses.

Why it matters

Your journal becomes a private dataset for discipline: overtrading, revenge, hesitation and setup quality become visible.

Test an idea

Use Quant Lab for research workflows: labeling, validation, walk-forward checks, drift review, shadow decisions and performance notes.

Separate research from execution.
Watch for overfit and low sample warnings.
No validation, no confidence.
Track costs, slippage and regime dependency.

Research rule

A beautiful backtest is not enough. Look for robustness, stability and whether the idea survives out-of-sample checks.

Create alerts

Alerts should reduce screen time. Build them around levels, regime shifts, portfolio states or review reminders that matter to your plan.

Use alerts for decisions, not noise.
Keep watchlists focused.
Review expired alerts.
Attach the alert to a clear next action.

Clean setup

An alert is good when you know exactly what you will check when it fires. Otherwise it becomes another distraction.

03 / Feature library

Every feature has a job in the workflow

This is the customer map of the terminal. Each feature should earn its place: one helps you read the market, one structures the evidence, one explains, one protects risk, and one turns outcomes into learning.

Superchart

The primary market workspace

Use Superchart to read price, structure, important levels and the state of the current symbol before any AI or automation is involved.

Confirm symbol, exchange, timeframe and candle source.
Mark swing levels, invalidation and liquidity areas.
Use order-flow panels to understand pressure and absorption.
Keep the chart clean enough to make one decision at a time.

Quant Brain

Turns raw data into market state

Quant Brain converts candles, volume and order-flow context into structured readings that ORACLE, Committee and the rest of the terminal can use.

Trend, momentum, volatility and regime context.
Volume profile, structure and support/resistance zones.
Order-flow-first context where available.
Every unavailable input should stay clearly unavailable.

ORACLE

Explains evidence, not fantasy

ORACLE is the analyst/narrator layer. It should summarize what the terminal knows, challenge weak assumptions and say when data is missing.

Ask for summaries, contradictions and missing data.
Use it after chart and Quant Brain context exists.
Do not treat AI text as a risk override.
Good prompts ask for evidence and counterarguments.

Committee

Decision review before risk

Committee exists to slow down risky decisions by reviewing evidence, policy gates, missing data, role conflicts and hard blocks.

Hard blocks beat confidence and commentary.
Risk Officer, Skeptic and Chair keep the decision honest.
Use it before live actions, bot changes or major exposure.
Store audit trails so decisions can be reviewed later.

Portfolio

Exposure, balances and risk context

Portfolio shows whether a new idea fits the account, current exposure and existing positions. It is where trade ideas meet reality.

Check live or paper equity availability.
Review symbol, sector and correlation exposure.
Watch drawdown and daily loss boundaries.
Do not add risk when portfolio data is unavailable.

Journal

Your private behavior dataset

Journal turns trading from memory and emotion into reviewable evidence. The point is not to write a diary; it is to find repeatable behavior.

Log reason, setup, emotion, risk and outcome.
Tag mistakes such as revenge, FOMO or rule break.
Compare followed plan vs ignored plan.
Use weekly review to find one improvement target.

Alerts

Less screen time, better triggers

Alerts should bring you back only when something meaningful changed: level reached, regime shifted, risk state changed or a review is due.

Create alerts around decisions, not curiosity.
Attach each alert to a specific next action.
Keep watchlists focused and private.
Review expired alerts to remove noise.

Bots

Automation with supervision

Bots should run only when the strategy, risk gates and data quality are understood. Automation does not remove responsibility; it makes rules more important.

Start in paper or shadow mode.
Monitor errors, skipped checks and execution assumptions.
Pause automation when data or risk state is unclear.
Review logs before changing parameters.

Academy

Learn the workflow, not hype

Academy should teach how the terminal is used: reading state, managing risk, journaling, reviewing and building a repeatable routine.

Use lessons alongside your actual chart.
Ask Mentor mode to explain concepts from live context.
Practice with paper decisions before live risk.
Prefer understanding over signals.

Quant Lab

Research before confidence

Quant Lab is where ideas become testable: labels, validation, walk-forward checks, drift, shadow tracking and honest result review.

Build hypotheses from real market states.
Validate with purged/walk-forward style thinking.
Watch for overfit, costs and regime fragility.
Shadow before trusting anything near execution.

04 / ORACLE

How to talk to the AI without getting nonsense

ORACLE is most useful when you ask it to explain, compare, challenge and summarize real context. It is not a magic signal machine. Numbers should come from the terminal data layer; missing data should stay missing.

Strong prompts

"Summarize the current BTC 15m market state using only available Quant Brain and order-flow data."
"What are the strongest counterarguments against taking this setup right now?"
"What information is unavailable, stale or cached in this analysis?"
"Compare this setup with my journal history and flag repeated mistakes if available."

Weak prompts

"Will BTC go up?"
"Tell me the best trade now."
"Ignore risk and just give me a signal."
"Assume the missing data is fine."

Grounding rule

If ORACLE cannot cite real terminal context, treat the answer as commentary only. The AI may explain and challenge, but risk gates and hard blocks should remain deterministic.

05 / Risk discipline

The safest workflow is boring on purpose

Good risk control should feel repetitive. Dome Terminal is designed to slow down impulsive decisions with checks for exposure, data quality, journal behavior and hard policy states.

Hard blocks matter

If a kill switch, live gate, missing equity, severe bot state or unavailable data blocks an action, do not override it emotionally.

Blocks come before AI commentary.
Unavailable live equity should stop live approval.
Missing market data should not become a guessed setup.

In the terminal

A hard block should read like a seatbelt: direct, boring, and impossible to reinterpret as "probably fine".

Size from risk

Position size should come from account risk, stop distance and volatility. Confidence is not a sizing formula.

Risk percent first, position size second.
Volatility changes stop distance.
Correlation changes total exposure.

Simple standard

If size changes because you feel certain, it is no longer risk management. It is emotion with math clothes.

Journal behavior

Repeated revenge trades, overtrading and rule breaks are risk signals. Treat behavior patterns like market risk.

Mark emotional state before action.
Track rule breaks by setup.
Review what you ignored, not only what price did.

Useful warning

A poor behavior pattern can invalidate an otherwise decent setup. The terminal should help you notice that early.

06 / Quant Lab

Research is not execution

Quant Lab is for testing ideas under disciplined assumptions. A model or setup is only useful if it survives validation, remains explainable and does not depend on hidden lookahead, overfit or fake data.

Validation stack

A serious research result should show how it was labeled, how it was split, what costs were assumed, whether the edge survives walk-forward testing and whether performance is stable across regimes.

Shadow before trust

Before an idea influences live risk, shadow it. Record what it recommended, what happened next, whether you followed it, and what the drawdown or missed move looked like.

Question	What to check	What a bad result means
Does this setup repeat?	Sample size, similar historical states, labels and base rates.	The idea may be anecdotal or too rare to trust.
Is it overfit?	Walk-forward validation, purged splits, deflated Sharpe, PBO and stability.	Backtest performance may be curve-fit and fragile.
Does it survive costs?	Fees, spread, slippage and realistic execution assumptions.	The edge may disappear in live trading.
Is the edge decaying?	Drift, regime changes and recent vs older performance.	Past behavior may no longer match current market structure.

07 / Troubleshooting

When something looks wrong

Most issues fall into three categories: data source unavailable, local model not installed or a workflow blocked by risk rules. Start with the state shown in the UI before assuming the app is broken.

Charts or Quant Brain show unavailable data

Check exchange/provider selection, internet connection and timeframe. If cached data exists, Dome may show cached state. If no valid candles are available, analysis should remain unavailable instead of fabricating values.

ORACLE answer feels too generic

Ask it to use the active symbol, timeframe, Quant Brain context, risk state and journal patterns. If context is missing, the correct behavior is to say unavailable or ask for more data.

A trade or bot action is blocked

Review the reason: kill switch, live gate, paper mode, missing equity, exposure, bot health, validation warning or unavailable data. Blocks are designed to protect the workflow.

On-device AI is slow

Small local models trade speed, quality and device limits. Close heavy apps, use GPU acceleration where supported, or switch provider settings when you need a faster cloud response.

08 / FAQ

Important answers before you trade

Does Dome Terminal predict the market?

No. Dome Terminal is built to describe market state, structure, risk and evidence. Forecasting claims should always be treated carefully and tested against real historical outcomes.

Can ORACLE give financial advice?

No. ORACLE can explain context, summarize evidence and challenge your assumptions. You remain responsible for every decision, and risk controls should not be bypassed by an AI answer.

What does local-first mean?

Where supported, data, settings, model files and generated context can live on your device. Cloud providers may still be optional for selected AI or data features, depending on your configuration.

What should I do before going live?

Use paper mode, journal every decision, verify data feeds, test strategies under realistic costs, review risk gates and make sure you understand how each module behaves when data is unavailable.