Glossary¶
Terms are listed with the component that owns the definition. Where the owner is upstream NautilusTrader, this site defers to upstream documentation rather than restating a definition that could drift.
Platform and process¶
- Activation set
- The set of venues a deployment is configured to run. Owned by the backend. The tracked production record and the development manifests may name different sets; only the record describes what production is meant to be running. See runtime and deployment.
- Contract pin
- A content-addressed reference from a client to the exact backend release and schema set it accepts. Enforced at build time rather than discovered at runtime. See gateway and schemas.
- Evidence anchor
- A
repository@commit:pathreference recorded in a page's metadata, identifying the exact immutable source a claim was read from. Rendered in the evidence block at the foot of every page. - Pin
- A specific immutable commit (and usually its tree) that a claim, a build or a dependency is fixed to. ONIX pins by content rather than by branch name.
- Production record
- A tracked file in the backend repository stating what production is supposed to be running. It is a record, not an observation; see the status model.
- Quarantine
- Material that exists but is deliberately not published, with the reason recorded publicly. See the documentation model.
- Status token
- One of nine values grading how much weight a page's claims carry. Defined in full on the status model.
Market data¶
- Bar
- An OHLCV aggregate over a time interval. The primitive is upstream NautilusTrader's; ONIX's catalog and aggregation behaviour around it is documented at aggregation.
- Catalog
- The backend's durable store of historical market data, and the authority for what history exists. Owned by the backend. See the catalog.
- Closed bar
- A bar whose interval has ended and which will not change. The distinction between closed and in-progress bars matters for both correctness and presentation; see aggregation.
- Coverage
- The accounting of which instruments and channels a deployment is subscribed to, and which are producing flow. Owned by the backend data plane; see ingestion and coverage.
- Derived resolution
- A bar resolution produced by aggregating a finer durable resolution rather than being stored directly. See aggregation.
- Gap
- A missing interval in a series. Reported as a gap; never interpolated away. See ingestion and coverage.
- Hydration
- The process of populating the catalog for an instrument, and the per- instrument state describing how far that has progressed. See the catalog.
- Instrument identity
- The normalisation of venue-specific symbols into a single stable identifier. Owned by the backend; see instrument identity.
- Retained ingestion
- The manifest describing which data a deployment retains, versioned by manifest version and epoch. See ingestion and coverage.
Trading¶
- Backtest
- A run of a strategy over historical data, producing a provenance-carrying result. A backtest is a measurement over recorded bytes, not a prediction. See backtesting.
- Execution runtime
- The subsystem responsible for order handling. Its permitted scope is stated precisely and conservatively at execution runtime. This documentation does not claim live real-money execution.
- Revision
- An immutable, content-addressed snapshot of a strategy's source. Two saves of identical content produce the same revision. See strategy authoring.
- Sandbox
- A live-data, non-real-money runtime used to exercise a strategy without placing real orders. See execution runtime.
- Strategy
- A unit of trading logic authored against the backend's strategy model. The retired TypeScript strategy runtime is not a strategy in this sense; see strategy authoring.
Product and clients¶
- BFF (backend for frontend)
- The gateway layer serving the web client, translating between the schema surface and client-shaped requests. See gateway and realtime.
- Datafeed
- The client-side adapter that supplies the charting surface with symbol metadata, historical bars and live updates. See charting and datafeed.
- Screener
- The surface that ranks and filters instruments by computed features. The engine is backend-owned (screener engine); the presentation is frontend-owned (screener).
- Widget
- A single pane in the modular dashboard. See dashboard and workspaces.
- Workspace
- A saved arrangement of widgets and their linkage. See dashboard and workspaces.
Agents and MCP¶
- MCP
- The Model Context Protocol, an open protocol for exposing tools and context to AI agents. ONIX has two MCP surfaces with different trust properties; see MCP overview.
- MCP host
- A process that exposes MCP tools. In ONIX, the macOS client hosts one locally; see local macOS MCP host.
- Mutating operation
- An MCP operation that changes state rather than only reading it. Mutating operations are enumerated and default-denied; see MCP safety and scope.
Upstream¶
- NautilusTrader
- The upstream open-source trading platform ONIX's backend is built on, pinned
at version
2.0.0rc3. Upstream owns runtime primitives and the backtest engine. See the NautilusTrader boundary and upstream documentation. - Upstream extension
- A deliberate ONIX modification of or addition to upstream behaviour, labelled as such wherever it appears.
Evidence and source pins for this page
Verified. Current behaviour, confirmed in source at the pinned commit.
Verified on against the following immutable sources:
backend@efa38e04:docs/handoff/contract-manifest.jsonfrontend@99f49dae:contracts/vendor/onix-engine/contract-manifest.json
Status tokens are defined on the documentation and status model page. Every pin on this site is listed under versions and source pins.