Glossary

The system's vocabulary in plain words

This page defines the atlas's trading terms in plain language and cites where each term lives. Type in the filter to narrow the list. Shared software terms match the maintainer glossary at docs/internals/glossary.md.

terms defined, every one with a lives-in citation

families: lifecycle, safety, exchange, plumbing, clients

constitution section numbers decoded, §11.1 through §18.2

atlas pages a term card can send you to by reader-facing title

Three reading notes before you filter

First, the section numbers (§11.1, §12.3, §14.7, §16.2, §16.3, §16.4, §17.5, §18.2) refer to the settled trading plan in docs/internals/trading-final-form.md. The numbered rules also appear verbatim in docs/architecture/trading-execution.md:190-268. Each card cites the service that enforces its rule. Second, the maintainer glossary is at docs/internals/glossary.md. Overlapping terms such as command, event, decider, projector, read model, reactor, receipt, projection, and provider use the same meanings here. The receipt card repeats its warning that RuntimeReceiptBus receipts are test-only. Third: plain words first. The definition is the sentence you would say out loud; the citation is the sentence the repository says.

The terms

Start typing to filter the entries. The filter matches term names, aliases, and definition text, so budget, cloid, and 16.4 all work. Related terms link inside this page; a card's home link sends you to the atlas page that tells the term's whole story.

47 of 47 terms

Lifecycle

9 terms

How delegated trading exists in time: created, bound, woken, suspended, ended, and remembered.

mission

The durable unit of delegated trading authority: an instruction, allocated capital, an authority envelope, a bound harness thread, and its markets. One authority per market: a market belongs either to a mission or to the user's manual trading, never both. Creation is an explicit user act, and revoked and completed are the only permanent exits. Lives in apps/server/src/trading/TradingMissionService.ts and apps/server/src/trading/TradingAuthorityBinding.ts:1-13.

Relatedharness, authority envelope, watch, §11.1HomeMissions watches wakes

watch

A typed, deterministic predicate bound to a mission: candle_close, price_cross, scheduled_reassessment, pnl-based, stop-proximity, or a prediction horizon or invalidation level. The evaluator checks them on websocket candles plus a slow sweep. A watch fires exactly once, guarded twice: an atomic flip from active to triggered, and a per-watch dedup key in the mission inbox. Lives in apps/server/src/trading/WatchEvaluator.ts:16-25 and apps/server/src/trading/TradingWatchService.ts:1-9.

Relatedwake, follow set, missionHomeMissions watches wakes

wake

Resuming the harness with a reason. A fired watch becomes a run request; after the §12.3 pre-run checks and the decision lease, the wakeup composer builds the bounded snapshot of everything the model missed and the turn starts. A mission holding a position is never deaf: a coverage floor guarantees reassessment, clamped between 2 and 15 minutes. Lives in apps/server/src/trading/TradingWakeupComposer.ts:1-19 and packages/trading-contracts/src/watch.ts:1288.

Relatedwatch, harness, decision lease, §12.3HomeMissions watches wakes

harness

The provider session a mission's thread is bound to: the thing that actually thinks. It reaches trading only through MCP tools (trading_enter, trading_watch, trading_plan, and the rest), and its intents carry expectedAuthorityVersion, so a model acting on a stale mandate refuses at preview. The provider binding freezes for the mission's life. Lives in apps/server/src/trading/TradingAuthorityBinding.ts:306-323 and apps/server/src/mcp/toolkits/trading/tools.ts:152-372.

Relatedprovider, mission, wakeHomeMissions watches wakes

TRADE.md

The trading plan as a workspace file the agent writes with its native file tools. Activation pins the exact revision the agent read, via expectedContentHash; a file that changed since refuses stale_hash and writes nothing. While an activation stands, new exposure on a drifted, missing, or unreadable file refuses plan_document_drifted; exits, cancels, and protective actions always pass. Lives in apps/server/src/trading/TradingPlanDocument.ts, with the pin and audit tables in migrations 089 to 091 (docs/internals/trading-final-form.md, section 7).

Relatedharness, wake, missionHomeMissions watches wakes

follow set

The registry of markets the system is actually paying attention to: held positions, armed watches, the watchlist, chatted-about and recently charted markets. Following starts websocket candle collection and deep recording. It reaches the archiver through a JSON file instead of the database, because the archive database has exactly one writer and a table would have made it two. Lives in apps/server/src/trading/FollowSetRegistry.ts:1-15.

Relatedarchive, watchHomeResearch mode

§11.1

The mission status machine: ten statuses and their published transition table. revoked and completed are permanent terminals with no outgoing edges; paused, agent_unavailable, and blocked are suspended states that can return to the loop. The table is encoded as data, and a test asserts it matches the published spec edge for edge. Lives in apps/server/src/trading/MissionTransitions.ts:10-55.

Relatedmission, §16.4HomeMissions watches wakes

§12.3

The pre-run checks the turn coordinator runs before a wake may start a harness run, plus acquisition of the decision lease. A fired watch that arrives behind an active run queues and retries for 5 seconds at a time, 60 times, rather than starting a second run. Lives in apps/server/src/trading/TradingTurnCoordinator.ts:1-26 and apps/server/src/trading/TradingMissionReactor.ts:126-133.

Relatedwake, decision leaseHomeMissions watches wakes

Safety

12 terms

The guarantees that outrank convenience: budgets, protection, authority, and the constitution sections that name them.

protection (exchange-native stop)

A stop that lives on the exchange as a real reduce-only trigger order, not a promise the server makes to itself. No acknowledged position increase may remain without confirmed protection; coverage is read back from the exchange's own open orders, and a window that closes uncovered escalates to the emergency close. Take-profit is deliberately not exchange-native anymore: the target is a wake, not an order. Lives in apps/server/src/trading/TradingProtectionService.ts:4-9 and apps/server/src/trading/TradingMissionReactor.ts:2542-2563.

RelatednormalTpsl, reduce-only order, §17.5HomeRisk control

normalTpsl

The Hyperliquid order type that links a take-profit and stop-loss child to a parent order. Position-increasing entries map a linked normalTpsl child so the stop travels with the fill; an independently re-placed stop uses na grouping so it outlives its parent order. Lives in apps/server/src/trading/HyperliquidExecutionService.ts:140-153 and apps/server/src/trading/HyperliquidExecutionService.ts:637-666.

Relatedprotection, cloidHomeExecution

reduce-only order

An order the exchange itself will not let open or extend a position. This is what makes the user controls safe without the harness checklist: the buttons that get you out skip the preview on purpose, because a reduce-only order physically cannot add exposure. What they never skip is the signer, the nonce lane, canonical reconciliation, and protection reconciliation. Lives in apps/server/src/trading/TradingControlService.ts:10-24.

RelatedIOC, §14.7, protectionHomeRisk control

loss budget

The mission's cumulative loss allowance in dollars, computed by six equations: realized result is closed PnL plus funding minus fees; losses count toward it, profits clamp to zero and never raise the ceiling; open positions reserve loss-to-stop; pending entries reserve planned loss plus fees. When the remainder reaches zero the mission blocks, and only an explicit user resume clears it. Lives in packages/trading-contracts/src/lossAccounting.ts:106-138 and apps/server/src/trading/TradingBudgetReader.ts:60-74.

Related§16.2, §16.4, authority envelopeHomeRisk control

authority envelope

What a mission is actually allowed to do: ceilings on leverage, gross notional, cumulative loss, and planned risk per position, booleans like scale-in and direction reversal, and a wake budget. It is versioned; harness intents carry expectedAuthorityVersion and a mismatch refuses at preview. The type itself forbids profit-funded expansion: positivePnlExpandsLossBudget is the literal false, not a boolean. Lives in packages/trading-contracts/src/authority.ts:41 and packages/trading-contracts/src/authority.ts:59-96.

Relatedloss budget, mission, harnessHomeSigner & authority

signer

The local key that signs exchange actions. It resolves from T3_TRADES_INTERIM_SIGNER_KEY or the machine-canonical file ~/.t3trade/secrets/hyperliquid-interim-signer-key.bin, fails closed when absent, and refuses a key file readable by group or other. Under vitest the file source is disabled, so no test can ambiently arm live execution with the developer's real key. Lives in apps/server/src/trading/InterimSignerConfig.ts:19-44, apps/server/src/trading/InterimSignerConfig.ts:213-220, apps/server/src/trading/InterimSignerConfig.ts:248-259.

Relatednonce lane, research modeHomeSigner & authority

research mode

The product mode when no signer is armed. Market data, charts, alerts, backtests, validations, missions, and wakes all work; only signing-dependent actions refuse, with one honest line on the trade home: research mode means no trading key is configured, observation and backtests and validations work, and orders will be refused. The boundary is enforced by dependency wiring: research services get SQL and Crypto only, and the code asserts nothing there can reach an order. Lives in apps/server/src/trading/runtimeLayer.ts:224-245 and docs/user/research-mode.md.

Relatedsigner, archiveHomeResearch mode

§14.7

The seven deterministic user controls: pause, resume, cancelEntries, reducePosition, closePosition, revoke, and closeAndRevokeMission. They must work while the provider process is dead, the session is unreachable, or the model is mid-thought. A submitted but unconfirmed close must report its outcome as unknown, never a number. Lives in apps/server/src/trading/TradingControlService.ts:1-31 and apps/server/src/trading/TradingControlService.ts:78-84.

Relatedreduce-only order, §17.5HomeRisk control

§16.2

The loss-budget equations, six of them, from realized result through remaining allowance. The inputs are reconciled exchange facts: closedPnl is Hyperliquid's attribution, never computed by T3. A position without a stop reserves zero directional risk rather than full notional, because booking entry as risk for an unstopped long would exhaust the budget instantly. Lives in packages/trading-contracts/src/lossAccounting.ts:33-138 and docs/architecture/trading-execution.md:192-224.

Relatedloss budget, §16.4, replay fixturesHomeRisk control

§16.3

The position-increase checklist: fourteen items plus two exit-only, each with its own named rejection. Leverage, gross notional, planned loss per position, reservations within budget, no conflicting pending execution, a valid stop, freshness windows, an approved wallet. The stop gate runs a second time inside the execution service, against the price actually going on the wire. Lives in apps/server/src/trading/TradingPreviewService.ts:31-66 and apps/server/src/trading/HyperliquidExecutionService.ts:605-624.

Relatedloss budget, protectionHomeRisk control

§16.4

Loss-exhaustion enforcement. When the budget is exhausted: cancel resting position-increasing orders, refuse new increases, keep reduce-only protection working, transition the mission to blocked. Cancel, reduce, close, and modify_stop stay permitted, because §16.4 blocks taking on risk, not managing the risk already open. The harness cannot resume itself from the block; only a user resume clears it. Lives in apps/server/src/trading/TradingExecutionGuard.ts:1-19, apps/server/src/trading/TradingExecutionGuard.ts:90-154, apps/server/src/trading/TradingExecutionGuard.ts:259-271.

Relatedloss budget, §11.1, §14.7HomeRisk control

§17.5

The bounded emergency close: a deterministic safety action that runs without the harness. Block increases, cancel non-reduce-only orders, read fresh canonical state, submit a reduce-only IOC, reconcile, retry with fresh reads; at most three attempts, then an honest three-way report: flat, open with size, or unknown. Lives in apps/server/src/trading/TradingEmergencyCloseService.ts:10-51 and apps/server/src/trading/TradingEmergencyCloseService.ts:75-117.

Relatedprotection, reduce-only order, §14.7HomeRisk control

Exchange

9 terms

The words of the venue itself: orders, ids, nonces, and what counts as truth.

cloid

The client order id Hyperliquid uses to correlate orders, cancels, and fills. It is explicitly NOT an idempotency key: the exchange dedupes cloids only among resting orders, and an IOC never rests, so a resubmitted IOC fills twice, verified live. T3 derives it deterministically from mission, sequence, and action type so retries reuse it, and the 0x prefix matters, because a bare hex cloid is silently stored as null. Lives in packages/hyperliquid/src/Cloid.ts:1-28 and packages/trading-contracts/src/execution.ts:49-88.

Relatedidempotency key, IOCHomeExecution

IOC (immediate-or-cancel)

An immediate-or-cancel order: crosses the spread and cancels whatever does not fill instantly. There is no market order on Hyperliquid, so every market fill is a limit priced to cross. Entries get a 50 bps crossing allowance, exits 100 bps, deliberately wider because an exit that misses leaves the exposure it was placed to escape. Lives in apps/server/src/trading/IocSlippageConfig.ts:1-27.

Relatedcloid, reduce-only orderHomeExecution

idempotency key

The local record that makes retries safe: idem_ plus mission, sequence, and action type, persisted with the execution record BEFORE anything is signed. A retry reads the record back and refuses unless its status is still previewed, reserved, or signed. submitted is deliberately excluded, because an unresolved submission is exactly the case that duplicates a position. Lives in apps/server/src/trading/HyperliquidExecutionService.ts:291-305 and apps/server/src/trading/HyperliquidExecutionService.ts:668-676.

Relatedcloid, event-sourced commandHomeExecution

nonce lane

The one serialized lane every signature passes through, a semaphore of one. Nonces are strictly monotonic and fast-forward to current Unix milliseconds, so a restart needs no persisted nonce state: real time has always moved past anything signed before it. signInNonceLane is the single place a signature is taken; a second copy of that block would be a second chance to sign outside the lane. Lives in packages/hyperliquid/src/NonceCoordinator.ts:1-16 and apps/server/src/trading/HyperliquidExecutionService.ts:527-552.

RelatedsignerHomeSigner & authority

canonical (exchange truth)

Hyperliquid's own record of positions, orders, and fills: the only one that counts. Local tables are caches to be corrected, never rivals: local state never outranks Hyperliquid. Reconciliation reads the full canonical open-order set, not just orders T3 chose, because a linked TP/SL child has a cloid T3 never picked and still protects. Lives in apps/server/src/trading/HyperliquidReconciler.ts:214-221 and apps/server/src/trading/HyperliquidReconciler.ts:1117-1152.

Relatedreconciliation, driftHomeReconciliation

drift

Local state that no longer matches the exchange. External position changes (size moved with no attributed fill), external transfers (account value moved more than $1 while flat), and protection gaps are all classified drift, each with a repair path. A 60 second attribution grace window exists because the reconciler once reported a mission's own entry, 347 ms after it filled, as someone acting on the exchange directly. Lives in apps/server/src/trading/HyperliquidReconciler.ts:820-826 and apps/server/src/trading/HyperliquidReconciler.ts:985-1024.

Relatedreconciliation, canonicalHomeReconciliation

reconciliation

The convergence pass that overwrites local tables with canonical exchange truth. Eight triggers force it, from server startup to a periodic backstop every 5 seconds while a position is open; the live three ride the userFills websocket subscription. Each pass also settles abandoned executions and writes the closing self-review the first time it sees a held position gone. Lives in apps/server/src/trading/HyperliquidReconciler.ts:66-76 and apps/server/src/trading/HyperliquidReconciler.ts:1100-1181.

Relatedcanonical, drift, §18.2HomeReconciliation

§18.2

The list of eight moments that force a reconciliation pass: server startup, websocket reconnect, before execution, after submission, after fill, after position update, before resuming a paused mission, and periodic while a position is open. Lives in apps/server/src/trading/HyperliquidReconciler.ts:66-76.

Relatedreconciliation, canonicalHomeReconciliation

replay fixtures

One specific real testnet morning, 2026-08-13, checked in byte-for-byte so policy changes replay over identical data. The trading policy constants are versioned artifacts (V1, V2, V3; V3 retired the ema_cross strategy after a frequency audit), and comparePolicyReplays shows what a new policy would have done on the same tape. Lives in apps/server/src/trading/TradingReplayWindow20260813.ts:1-13, apps/server/src/trading/replay-fixtures/, and packages/trading-contracts/src/replay.ts:438-502.

Relatedarchive, §16.2HomeResearch mode

Plumbing

11 terms

The event spine everything rides: commands, events, projections, reactors, receipts, and the leases that keep one writer.

event

A persisted fact that something already happened, stamped with a global sequence number and its aggregate. Commands are requests; events are facts. The trading events that matter most are the requested family, and the reactor's own doc calls them a question, not an answer: nothing has happened yet, and the UI never sees a status the domain refused. Lives in packages/contracts/src/orchestration.ts:1541-1551 and apps/server/src/trading/TradingMissionReactor.ts:1-18.

Relateddecider, reactor, event-sourced commandHomeEvent spine

decider (pure)

The pure function that turns a command plus the current read model into events: no IO, no clock reads, no exchange calls. Same inputs, same events, every time, and property tests pin the equations. Attribution, who dispatched this, is stamped by the engine, deliberately not by the decider. Lives in apps/server/src/orchestration/decider.ts:218-228.

Relatedevent, projector, read modelHomeEvent spine

projector

The logic that folds events into state. One projector builds the in-memory read model the decider consults; the durable pipeline writes the SQLite projection tables. Trading projections are disposable by construction: they re-read the domain tables, so the projection can always be dropped and rebuilt. Lives in apps/server/src/orchestration/projector.ts:193-212 and apps/server/src/trading/TradingMissionProjection.ts:1-14.

Relatedprojection, read modelHomeEvent spine

projection

A read-optimized table derived from events rather than written directly. If it disagrees with the domain tables it is wrong and rebuildable, never authoritative. The account view goes further and keeps no projection table at all: it is derived on read, because there is no table behind it to go stale. Lives in apps/server/src/orchestration/Layers/ProjectionPipeline.ts:66-83 and packages/contracts/src/trading.ts:876-901.

Relatedprojector, read model, doorbellHomeEvent spine

read model

The materialized current state clients actually read: projects, threads, messages, activities, and sessions, with a snapshotSequence. The decider consults it, the projector is its only writer, and clients render it instead of keeping a copy that could go stale. Lives in apps/server/src/orchestration/projector.ts:193-200 and apps/server/src/orchestration/Layers/ProjectionSnapshotQuery.ts.

Relatedprojection, doorbell, atomHomeEvent spine

reactor

A queue-backed service that reacts to committed events and performs the side effects the decider is forbidden to do: exchange calls, provider dispatch, control execution. The trading reactor answers every requested event, runs the 5 second watchdog family (protection, take-profit, working-order, manual reconcile), and settles the execution latch only after the durable writes. Lives in apps/server/src/trading/TradingMissionReactor.ts:115-124, apps/server/src/trading/TradingMissionReactor.ts:2186-2248, apps/server/src/trading/TradingMissionReactor.ts:2886-2920.

Relatedevent, receipt, deciderHomeEvent spine

receipt

Proof that something completed. Three kinds live in the spine: the durable command receipt keyed by commandId (a duplicate returns the original sequence, a rejection is sticky), the in-process execution latch the trading_enter tool blocks on, and the UI-facing control result on the mission row. The maintainer glossary's RuntimeReceiptBus receipts are a separate, test-only mechanism; do not build production behavior on them. Lives in apps/server/src/persistence/Services/OrchestrationCommandReceipts.ts:24-32, apps/server/src/trading/TradingExecutionReceipts.ts:1-23, and docs/internals/glossary.md.

Relatedevent-sourced command, reactorHomeEvent spine

doorbell (invalidation)

A push event that carries no data, only a revision number: your cached view is stale, fetch again. The account stream works this way on purpose, because the view is derived on read and a payload in the event would be a second source of truth that can go stale. The fetch is the truth and the event is only the doorbell. Lives in packages/contracts/src/trading.ts:903-915 and apps/server/src/trading/TradingAccountProjection.ts:250-260.

Relatedread model, atomHomeEvent spine

event-sourced command vs direct RPC command

The two deliberate classes of client writes. Event-sourced commands (mission create, order place, the §14.7 controls) ride the command spine, so the write has a receipt, a replayable log, and idempotency. Direct RPC commands (arm watch, preview order, revise plan) answer immediately, so the refusal reason lands on screen with no ceremony. The split is by failure UX, not habit: preview is an RPC so the refusal lands on screen, place is a command so the write is event-sourced. Lives in packages/client-runtime/src/state/orchestration.ts:124-186 and packages/contracts/src/trading.ts:1320-1327.

Relatedevent, receiptHomeEvent spine

runtime lease

The single-writer file lock that gives one process the trading runtime against a database: the lock file beside the database, holding pid, host, and heartbeat. Mission reactor, watch evaluator, follow registry, and archive supervisor start only when it is held, and watchdog loops stand down when it is lost. Its own header documents one corner where two processes can both believe they hold it for at most one heartbeat interval, bounded to dual belief, never dual writing. Lives in apps/server/src/trading/TradingRuntimeLease.ts:12-30 and apps/server/src/trading/TradingRuntimeLease.ts:51-71.

Relateddecision lease, reactorHomeEvent spine

decision lease

The guarantee that one harness run at a time owns a mission's decisions. A unique partial index turns a concurrent second run into queued_behind_active_run instead of two models trading one authority. A forked watcher releases the lease when the session leaves running. Lives in apps/server/src/trading/TradingTurnCoordinator.ts:1-26.

Relatedruntime lease, wake, §12.3HomeMissions watches wakes

Clients

6 terms

What the human touches and travels through: atoms, providers, relays, tokens, environments.

atom (client state)

A unit of client state in the web app, consumed through atom families over the typed RPC calls. Each atom is a cache with a per-read TTL: universe 60 seconds, workflow scripts 5 minutes, research scenes never held. Atoms hold projector output, never client-side mission state that could go stale. Lives in packages/client-runtime/src/state/orchestration.ts:31-210 and apps/web/src/lib/tradingMissionsState.ts:41-47.

Relatedread model, doorbellHomeWeb & desktop

provider

The backend agent runtime that performs the work of a thread. Five ship built in, Codex, Claude, Cursor, Grok, and OpenCode, each behind an adapter that translates its protocol; the orchestration layer never knows which one is behind a thread. Adding one is a driver plus an adapter, with no orchestration, contract, or client change. Lives in apps/server/src/provider/builtInDrivers.ts:49-56 and docs/internals/providers.md:9-31.

RelatedharnessHomeProviders

relay

T3 Connect's hosted control plane: account and environment linking, managed endpoint discovery, and short-lived credentials. It is deliberately not in the hot path: after connect, traffic goes directly between client and environment. Its Postgres sits behind Cloudflare Access and a tunnel, with Hyperdrive caching disabled, because a stale read of credentials or DPoP proofs is an auth bug. Lives in infra/relay/README.md:15-29 and infra/relay/src/db.ts:71-75.

Relatedenvironment, DPoP, pairingHomeRelay & environments

DPoP

Demonstrating proof of possession: a bearer token bound to a key that must sign a fresh proof with every request, so a leaked token cannot be replayed without the key. Relay client access tokens are DPoP-bound with a 30 minute TTL; brokered environment exchanges get 1 hour. Lives in infra/relay/src/auth/RelayTokens.ts:26-28 and docs/internals/environment-auth.md:71-93.

Relatedrelay, pairingHomeRelay & environments

pairing

Linking a client to an environment with a one-time code. The hosted pairing URL carries its token in the fragment, so it never reaches a server log or browser history. Ordinary pairing grants four client scopes plus relay:read; bootstrap credentials add access and relay write scopes. Lives in docs/internals/environment-auth.md:25-29 and docs/internals/remote.md:9-70.

Relatedenvironment, relay, DPoPHomeRelay & environments

environment

A place a T3 server runs that a client can connect to: the local desktop backend, a manually paired endpoint, a relay-managed tunnel, or SSH. Remoteness lives entirely at the connection layer; the same contracts and runtime ride every target. The web trading gate latches exactly one destination per session, and a vanished destination renders unavailable rather than silently falling back. Lives in docs/internals/remote.md:9-70 and apps/web/src/components/trading/tradingEnvironmentSelection.ts:1-100.

Relatedrelay, pairing, atomHomeWeb & desktop

Plain words first, paths second

Each entry defines the term the way you would explain it to a smart friend, then cites where it lives. The rule is the repository's own working rule: if you did not verify it, do not print it. Where this page and the maintainer glossary share a term (command, event, decider, projector, read model, reactor, receipt, projection, provider), the meanings agree; the maintainer glossary keeps the coding side, threads, turns, and checkpoints, and this page keeps the trading side.

The safety family has the most entries because many trading terms describe execution limits and failure handling. If a word you meet in the code is missing here, the fastest fallback is the maintainer glossary itself at docs/internals/glossary.md, then the module doc at the top of the file you were reading.

Reading rules

Shortcuts from the maintainer glossary, plus one trading-side addition

If you see requested, think intent recorded.
If you see completed, think result applied.
If you see receipt, think async milestone signal, for tests.
If you see checkpoint, think workspace snapshot for diff and restore.
If you see quiesced, think all relevant follow-up work has gone idle.
Trading side: if you see blocked, think §16.4 stopped it and only a user resume clears it.

The first five lines are the maintainer glossary's own shortcuts, quoted from docs/internals/glossary.md:147-153. The receipt card above explains how trading receipts differ from the test-only kind that rule refers to.

How each card was built

The glossary was assembled from repository evidence, using the same method as the rest of the atlas.

Step 1 · harvest

Terms were collected from module docs, contract files, the maintainer glossary, and the four explorer maps of the repository, not from a template.

Step 2 · verify

Every definition was checked against the cited file and lines in the checkout. If a line could not be cited, the claim was cut.

Step 3 · define

Written in plain words first, at most one analogy per concept, and every surprise stated as the incident that caused it, because that is how the repository itself explains its rules.

Step 4 · cite

Each card ends with the source path so you can compare the definition with the implementation.

Go deeper

The constitution and its numbers

docs/internals/trading-final-form.md the settled constitution
docs/architecture/trading-execution.md:190-268 §16 and §18.2 verbatim
apps/server/src/trading/MissionTransitions.ts:10-55 the §11.1 table
apps/server/src/trading/TradingControlService.ts:1-31 the §14.7 controls
apps/server/src/trading/TradingExecutionGuard.ts:1-19 §16.4 enforcement
apps/server/src/trading/HyperliquidReconciler.ts:66-76 the §18.2 triggers

The maintainer glossary

docs/internals/glossary.md the living glossary, whole file
apps/server/src/orchestration/decider.ts:218 the decider entry
apps/server/src/orchestration/projector.ts:202 the fold
apps/server/src/orchestration/Layers/OrchestrationEngine.ts:101-102 queue and fan-out
apps/server/src/orchestration/Services/RuntimeReceiptBus.ts test-only receipts
docs/internals/providers.md:9-31 provider vocabulary

Exchange vocabulary

packages/hyperliquid/src/Cloid.ts:1-28 cloid semantics
packages/hyperliquid/src/NonceCoordinator.ts:1-16 the lane
packages/hyperliquid/src/Signing.ts:1-30 phantom-agent EIP-712
apps/server/src/trading/IocSlippageConfig.ts:1-27 crossing allowances
packages/trading-contracts/src/execution.ts:49-88 the deterministic cloid
apps/server/src/trading/InterimSignerConfig.ts:19-44 signer resolution

Connection vocabulary

docs/internals/remote.md:9-70 connection targets
docs/internals/environment-auth.md:14-29 capability scopes
infra/relay/README.md:15-29 what the relay does
infra/relay/src/auth/RelayTokens.ts:26-28 the DPoP TTL
apps/web/src/components/trading/tradingEnvironmentSelection.ts:1-100 the latch
packages/client-runtime/src/state/orchestration.ts:31-210 atom families