System boundaries

VerifiedOwner Documentation integratorLast verified 2026-09-02frontend@99f49dae6368414896bf2858cb848f5a7c7fcf98 backend@efa38e04e2db37a444e9f17100323c2ad4b83647 nautilus@2.0.0rc3

A boundary in ONIX is not a folder name. It is a statement about who is allowed to be right. This page names the boundaries that matter and says, for each one, what crosses it and what deliberately does not.

The four boundaries

flowchart LR
    U["Upstream<br/>NautilusTrader 2.0.0rc3"]
    B["ONIX backend"]
    C["Contract surface<br/>schema set + gateway"]
    F["Clients<br/>web · macOS · iOS"]
    A["Agents<br/>via MCP"]

    U -- "B1: upstream boundary" --> B
    B -- "B2: contract boundary" --> C
    C -- "B3: client boundary" --> F
    B -- "B4: agent boundary" --> A

B1 — the upstream boundary

Upstream NautilusTrader owns the trading runtime primitives: instruments, bars, orders, positions, portfolio accounting and the backtest engine. ONIX consumes those at a pinned version rather than reimplementing them.

What crosses this boundary into ONIX: runtime types and engine behaviour.

What does not: ONIX does not fork upstream documentation into this site, and does not present upstream behaviour as an ONIX guarantee. Where ONIX extends upstream, the extension is labelled ONIX extension and scoped explicitly.

Read the NautilusTrader boundary for the exact pin and the support consequences.

B2 — the contract boundary

The backend publishes a versioned schema set. That set, not any prose, is the definition of what a client may ask for and what it will receive.

What crosses: schema-shaped requests and responses, and the schema set itself as a content-addressed artifact.

What does not: internal backend module structure, storage layout, or runtime process topology. A client that depends on any of those is depending on something that is free to change.

Read gateway and schemas.

B3 — the client boundary

Clients render and interact. They do not compute market truth.

What crosses: schema-shaped data and user intent.

What does not: authority. If the chart and the catalog disagree about a bar, the catalog is right. A client may cache, interpolate for display, or degrade gracefully, but it may never become the source of a market fact. This is why the product documentation links to backend pages for definitions instead of restating them.

Read client state and cache.

B4 — the agent boundary

Model Context Protocol surfaces let an agent read and, within limits, act. There are two such surfaces with materially different trust properties: a backend MCP surface and a local macOS MCP host. They are not interchangeable.

What crosses: bounded, enumerated operations.

What does not: unbounded execution. The safety posture, and what each surface refuses, is documented at MCP safety and scope.

What deliberately does not exist

Naming absent things is part of describing a system honestly.

Absent	Why it matters
A TypeScript trading or data engine	Retired. An earlier generation of this platform ran strategy and data logic in TypeScript. That runtime, its compile and isolation gate and its venue-adapter prototype were removed. NautilusTrader through the ONIX backend is authoritative. See strategy authoring.
A second source of market truth	There is one catalog authority and one aggregation path. Clients do not maintain a parallel history store. One authority does not mean one storage root — see below.
A documented complete multi-user identity system	Identity and access control are not documented as complete on this site. See support and scope.
A public API	The contract surface exists, but it is not offered publicly. Schema documentation describes shape, not availability.
Published operational internals	Runbooks, monitors, alerting and incident history are quarantined. See documentation model.

One catalog authority, two storage roots

"One catalog" is true about authority and false about storage, and the difference is load-bearing rather than pedantic.

Market history reaches the catalog by two paths that are never mixed:

• EXTERNAL — venue candles fetched through the official adapter's historical request API. This is history, backfill and repair. It is never treated as live.
• INTERNAL — live one-minute closes aggregated by the upstream data engine from trade ticks as they arrive.

They live in separate catalog roots. A bar is never relabelled from one to the other and neither root is cross-filled from the other. That is what makes a question like "was this bar observed live or fetched afterwards?" answerable at all; a single blended root would destroy the answer permanently.

The two roots also have different maintenance. The rolling EXTERNAL root is consolidated by the spine's own maintenance timer; the INTERNAL sibling root has its own lifecycle, which schedules consolidation over closed periods only, enforces resource admission floors on writers, and records census, watermark and error telemetry. In every case the mechanism is the upstream catalog's own public API — ONIX supplies configuration, scheduling, observation and refusal, and implements no merge, delete, rename or compaction of its own.

Two further properties belong in an architecture summary because they are boundaries, not details:

• The demand authority is a versioned, epoch-carrying manifest, not an ad-hoc roster. Evidence rosters from earlier work are history and are never authority.
• A catalog-writing service must refuse to start when its expected storage is not mounted and writable. Failing closed on a missing mount is the design; starting and writing somewhere else would silently fork the history.

The full account, with the resource floors and the incident that motivated them, is on the catalog page.

Where the seams are weakest

Documenting boundaries is only useful if the known-soft spots are named too.

• Deployment reality. The repository contains a tracked production record, but no live host was observed during this documentation pass. Everything that rests on that record carries the Production record badge rather than Verified. See runtime and deployment.
• Native client parity. The macOS client records a frontend pin older than the frontend pin this site documents. Any claim that depends on the two being in step is marked Unverified. See the macOS client.
• iOS canonical source. There is no canonical repository reference for the iOS client; two local candidates exist. The page says so rather than choosing one. See the iOS client.

Related reading

• Authority model — the same boundaries expressed as a table of who owns which fact.
• Design principles — the rules that produced these boundaries.
• Architecture decisions — what has actually been decided, and what has not.

Evidence and source pins for this page

Verified. Current behaviour, confirmed in source at the pinned commit.

Verified on 2026-09-02 against the following immutable sources:

• frontend@99f49dae:scripts/engine-pin.mjs
• frontend@99f49dae:contracts/vendor/onix-engine/contract-manifest.json
• backend@efa38e04:docs/handoff/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.