Architecture decisions¶
This page is a register of cross-repository decisions. It carries the
Unverified badge deliberately, and the reason is worth stating plainly: at the
pinned commits there is no neutral cross-repository decision registry. Each
repository records its own decisions in its own way. What follows is a
reconstruction from executable evidence, not a transcription of an accepted
register.
Nothing here should be treated as ratified until both the backend and frontend owners have re-accepted it in a shared register.
Decisions evidenced by executable state¶
These are settled in the strong sense: something in the source enforces them, so they cannot silently lapse.
D1 — NautilusTrader is the trading runtime¶
The backend depends on NautilusTrader at a pinned version rather than implementing a trading runtime. The dependency lock is the enforcement.
Status: settled, enforced by dependency locks. Consequence: upstream release pace and semantics are inherited. See NautilusTrader boundary.
D2 — The frontend pins the backend contract by content¶
The frontend carries an executable pin naming the backend release it accepts, plus the schema set and its hash. A mismatch fails the build.
Status: settled, enforced at build time. Consequence: releases must be coordinated; skew becomes a local build error. See gateway and schemas.
D3 — The TypeScript trading and data engine is retired¶
An earlier generation ran strategy and data logic in TypeScript. That runtime, its compile and isolation gate, and its venue-adapter prototype were removed rather than migrated.
Status: settled by removal. Consequence: no ONIX component may reintroduce a second execution or data engine. Documentation for the retired material redirects to its replacement. See strategy authoring.
D4 — Production composition is recorded in the repository¶
What production is supposed to be running is written down as a tracked record in the backend repository, rather than living only in an operator's memory or in deployment tooling.
Status: settled as a practice.
Caveat: the record was never checked against a live host during this
documentation pass, which is exactly why this site distinguishes Production
record from Verified. See runtime and deployment.
D5 — Documentation is a separate presentation repository¶
Cross-product documentation lives in its own repository rather than inside the frontend or backend, so neither application repository becomes the factual authority for the other.
Status: settled by the existence of this site. Consequence: documentation imports pins from application repositories; it never becomes their source of truth. See the documentation platform.
Open decisions¶
These are genuinely unresolved. Recording them is more useful than pretending otherwise.
| Open question | Why it is open | Blocked on |
|---|---|---|
| Where the neutral cross-repository decision register lives | No such register exists at the pins; each repository records decisions locally | Backend and frontend owners agreeing a location and format |
| Canonical source of the iOS client | The iOS repository has no canonical remote reference; two local candidates exist | Owner direction. See the iOS client |
| Native-client contract parity | The macOS client records an older frontend pin than the one documented here | Revalidation at the current pin. See the macOS client |
| Which venue activation set is authoritative for a reader | The tracked production record and the development manifests disagree, by design | Live-host observation. See venue matrix |
| Whether security and administration material can be published | Withheld pending implementation and disclosure review | Review. See documentation model |
Rules this register will follow once it is ratified¶
Recording the rules now avoids relitigating them later.
- One decision per entry, with a status of
proposed,accepted,supersededorrejected. - Every accepted decision names its enforcement — a lock, a test, a schema or a build check. A decision with no enforcement is a preference, not a decision, and belongs on the design principles page.
- Superseded decisions stay visible, with a link to what replaced them. Deleting a decision destroys the reasoning that led to the current state.
- Cross-repository decisions require both owners. A decision accepted in one repository alone is a local decision and does not belong here.
- Consequences are recorded, including costs. A decision entry that lists only benefits has not been thought through.
Related reading¶
Evidence and source pins for this page
Unverified. Could not be confirmed against the pinned sources. Treat as an open question.
Verified on against the following immutable sources:
backend@efa38e04:feature-state/rc3-data-plane-frozen-current-production.yamlfrontend@99f49dae:scripts/engine-pin.mjsonix-docs:manifest/a1-61-page-disposition-matrix.json
Status tokens are defined on the documentation and status model page. Every pin on this site is listed under versions and source pins.