For the technically curious

Enough of the shape to judge the engineering — the philosophy, the order pipeline, and the operational posture. The detailed blueprints stay with the product, but a good architect will recognise what's underneath. The parts list lives on the stack page.

Shape

A deliberate monolith on one machine

Atlas is a small set of cooperating services on a single private server — a data service that owns market capture, a trading service that owns decisions and orders, and an interface service that owns the operator's screen. They share one time-series database as the single source of truth, with an in-memory layer for live fan-out. There is no microservice sprawl, no message-broker archipelago, no orchestration cluster: the whole system can be read, audited, and rebuilt by one engineer in a sitting — which is the point. It runs comfortably on a 2-vCPU / 4 GB box.

Isolation is intentional where it matters: market data capture can never be interrupted by anything the operator does in the UI, and the interface layer has no direct path to the broker — boundaries that are enforced by automated architecture checks in CI, not by convention or code review vigilance.

Orders

One pipeline, no exceptions

• Manual clicks, automated strategies, and even position-closing all flow through the same checkpoint — there is structurally no way to place an order around it.
• Position size is derived from the stop-loss distance and your per-trade risk budget; an entry without a protective exit cannot be sized, so it cannot exist. Manual orders are capped at what you asked for — never inflated.
• The practice lane and the real lane execute identical code; the only difference is where the fills come from. Promotion from practice to real is explicit, per strategy, and reversible.
• Every decision — approved or refused — is persisted with its reason and streamed to the operator's screen in real time.

Data

Distrust as a design principle

• Live capture: streaming prices with full order-book depth over the broker's official feed, with per-instrument staleness monitoring. Stale data halts trading automatically.
• Self-repair: reconnects trigger automatic gap-repair of the candle history; a database hiccup makes the capture layer buffer to disk and replay, rather than drop ticks.
• Verified classification: the tradeable universe is checked against the exchanges' own published masters — not inferred from naming conventions — so scans run over actual equities, with per-source failure isolation and tamper guards on refresh.
• Provenance & convergence: every candle carries its origin — exchange-official, tick-built, or repaired — and a nightly sweep audits recent history against the exchange's official record, repairing what it can and permanently recording what the exchange itself never published. Research runs on exchange-truth by default; anything else is an explicit, labelled choice.
• Reproducibility: the system is event-sourced enough to replay: backtests on recorded history produce identical results run after run, and a CI gate fails any change that breaks that determinism.
• Time discipline: every stored timestamp is timezone-aware; exchange-calendar facts (sessions, expiries, lot sizes) are data refreshed from source, never constants in code.

Strategy machinery

One evaluator, honest verdicts

• One implementation: the same condition evaluator scores nightly scans, live rule firings, and historical backtests — a strategy cannot mean one thing in research and another in production, because there is only one meaning.
• Backtests that count everything: next-bar fills, brokerage, exchange fees, taxes and slippage, with sensitivity runs at doubled costs. Reports carry an anti-self-deception block — trial counts, a coin-flip p-value on the win rate, locked hold-out windows — because the easiest person to fool is the operator.
• Supervised graduation: a rule that survives research can propose trades as tickets awaiting a human click, and only then graduate to automation — every rung still passing the same risk checkpoint.

Options maths

Estimates labelled, bounds proven

• Multi-leg structures are priced with model estimates clearly labelled as such — and, separately, with no-arbitrage hard bounds on the worst case where the mathematics permits one.
• The execution rule is absolute: a structure whose maximum loss cannot be bounded cannot be placed. Risk is sized on the proven bound, never on a model's opinion.
• Structure exits monitor the combined position's live P&L — stop and target on the whole trade, not per leg — and unwind through the same guarded pipeline.

Security

Small surface, layered locks

• Exactly one thing faces the internet: an edge proxy with automatic TLS and two independent authentication layers in front of the application. The databases are never network-exposed.
• Broker credentials are yours, stored encrypted at rest on your server; secrets never appear in logs, and the broker session is re-authorised by a human every trading morning — deliberately.
• The public site you're reading is a separate static host with no route into the platform.
• Dependencies are audited and version-pinned; the money-path modules carry the strictest test coverage in the codebase, including failure-injection tests.

Operations

Built to be boring

• Nightly encrypted off-site backups with tiered retention — and a weekly automated restore drill that rebuilds the database from backup, verifies it, and reports the result either way.
• Health checks every minute during market hours (services, disk, restarts) with rate-limited alerts to the operator's phone.
• Watchdogs convert "alive but broken" states into clean automatic restarts; the platform prefers a one-minute reboot to an hour of silent degradation.
• A live latency readout in the terminal — feed-to-screen and order round-trip percentiles — because performance claims should be measured, not asserted.
• The entire installation is reproducible from three artifacts: the code repository, the backup store, and one configuration file.

Broker layer

An adapter, not a dependency

The broker integration is a thin, well-defined adapter behind an internal interface: market data in, orders out, statements for reconciliation. Zerodha's Kite Connect is the adapter shipped today; the interface was designed so that any Indian broker with a serious API can be wired in without touching the trading engine, the risk checkpoint, or the UI. If your broker publishes an API, it's a candidate.