Documentation and status model¶

VerifiedOwner Documentation integratorLast verified 2026-09-02onix-docs@a2-publication

Documentation about a live trading system fails in a specific way: a sentence written when something was true survives long after it stops being true, and a reader has no way to tell the difference. This site is built so that failure mode is visible rather than silent.

Four mechanisms do that work: a status vocabulary that grades how well a claim is known, a separate availability vocabulary that grades whether anyone can use the thing, a provenance surface generated from page metadata, and a route contract that makes it impossible to quietly drop a page.

The status vocabulary¶

Every published page carries exactly one status token. The build refuses to publish a page without one, and refuses any token outside this list.

Token	What it promises	What it does not promise
Verified	The behaviour is present in source at the pinned commit and was read there.	That it is deployed, that it is enabled for you, or that it still holds at a later commit.
Production record	A tracked production manifest in the repository attests to this.	That a live host was observed. It was not. The record is the only evidence.
Private / test stage	It exists and runs, in a private, internal or test-distribution context.	General availability, a public listing, an SLA, or stability of interface.
Target contract	A shape has been declared and written down as the intended contract.	That it is implemented. Treat it as design, not behaviour.
Upstream	The behaviour belongs to upstream NautilusTrader at the pinned version.	That ONIX owns, guarantees or can change it. Upstream documentation governs.
ONIX extension	ONIX deliberately extends or adapts upstream behaviour here.	That upstream will accept, keep or support the extension.
Retired	The thing existed, was removed on purpose, and is documented so it is not mistaken for current.	Anything at all about present behaviour.
Quarantined	Material exists but is withheld pending implementation or disclosure review.	That it will ever be published.
Unverified	Nothing. This is an open question recorded honestly rather than guessed at.	Everything. Do not build on an unverified claim.

The availability vocabulary¶

Status answers how well do we know this? It does not answer can anyone use it? Those are different questions, and merging them is not a simplification — it is how a deferred capability gets documented as a working one.

So every claim in the capability register carries a second, independent token.

Availability	What it means
Implemented	Present and working at the reviewed pin on at least one node or profile.
Preview	Present but behind a flag, profile or preview gate. Not general.
Paper only	Reachable only in paper or simulated execution.
Planned	A declared target contract. Not current behaviour.
Unavailable	Deferred, refused or removed at the reviewed pin.
Private	Exists, but restricted to a private, internal or operator-only deployment.

The combination that matters most is Verified + Unavailable. It is not a contradiction and it is not rare: it means the code was read at the pin, and the code refuses. Several backend operations are exactly that today — they exist, they are understood, and this release deliberately does not serve them.

Availability also carries a scope: the node, profile or environment it applies to. Availability in this system is genuinely per node, so a single global answer would be wrong even when it is convenient. A capability can be unavailable on one node and ready on another in the same deployment.

Both tokens are recorded per claim and neither is derived from the other. The machine-readable mapping is at manifest/availability-overlay.json.

What this site publishes, and what it withholds¶

The capability register is a filtered view, and it says so on its own face.

Behind it sits a private evidence packet per lane. Those packets legitimately hold implementation detail — guard names, authentication mechanics, storage locations, scope semantics — because their purpose is to let a reviewer with source access re-run a check. None of that becomes publishable copy just because the page it supports was not on a withheld list.

So publication is an explicit, per-claim decision that fails closed:

a claim marked public renders verbatim;
a claim marked internal renders only a separately reviewed, bounded rewording, if one was written;
a claim marked internal with no rewording does not render at all, and is counted as withheld so the register cannot pretend to be complete;
a claim carrying no decision fails the build. It is never published by default and never dropped silently.

Every sentence that survives that filter is then re-checked against the subjects this site withholds, so a quarantined subject cannot reappear under a different route. The per-claim decisions are recorded at manifest/disclosure-review.json.

Read absence from the register as not published, never as does not exist.

Two status tokens deserving particular attention¶

Production record exists because the repository contains a tracked record of what production is supposed to be running, but this documentation pass never connected to a live host. Presenting that record as observed reality would be a lie of exactly the kind this vocabulary is meant to prevent. See runtime and deployment for what the record actually pins and what it leaves open.

Unverified is used deliberately and often. The most common cause is that a statement was inherited from older documentation and could not be confirmed against source at the pins. An unverified claim is left visible rather than deleted, because a reader benefits from knowing the question exists.

The provenance surface¶

Each page declares its own metadata in front matter:

---
title: Catalog
summary: One sentence.
status: verified
owner: backend
last_verified: 2026-09-02
source_pins:
  - backend@efa38e04e2db37a444e9f17100323c2ad4b83647
evidence:
  - "backend@efa38e04:docs/handoff/contract-manifest.json"
  - "backend@f80bc316:src/some/module.py"
---

A build hook validates that block and then renders it. The status strip below the page title and the evidence block at the foot of the page are both generated. An author cannot write a status strip by hand, so a page's visible provenance is always the metadata a machine can also read.

The hook fails the build if any of the following is true:

a required field is missing or empty;
the status token is not in the vocabulary above;
last_verified is not an ISO YYYY-MM-DD date;
fewer than two evidence anchors are given;
the page body does not open with a single level-1 heading.

Because the hook takes no input from the clock, the environment or filesystem ordering, two builds of the same sources produce byte-identical output. That determinism is checked on every release; see the documentation platform.

The route contract¶

This site replaces an earlier 61-page documentation set. Every one of those 61 pages was classified before any rewriting began, and the classification is vendored into this repository as an immutable input.

A generated route contract closes all 61 rows. Each legacy page resolves to exactly one outcome:

Outcome	Meaning	Count
`published`	A rewritten page exists at a live route.	34
`merged`	Its content was folded into another published page, and its old URL redirects there.	9
`retired`	Deliberately removed; its old URL redirects to the page explaining why.	3
`split`	The A1 classification required two owned destinations; both are published and the old URL redirects to an index linking them.	1
`quarantine`	Withheld from publication, with a recorded reason.	14

There is no sixth outcome and no silent drop. The generator fails if any row is unaccounted for, if a destination is not a real published route, if a redirect points nowhere, or — for a split — if either half is missing. Substituting one page for a two-page split is a build failure, not a rounding. The same contract generates the navigation and the redirect map, so navigation, census and redirects cannot disagree with each other.

Accounted for is not the same as closed¶

All 61 rows are accounted for. 45 are fully closed. Two are published but still carry an open blocker, and the contract records which and why rather than rounding them up:

one row required an unambiguous iOS repository reference. None exists: two candidate commits were found and neither is canonical.
one row required observed live stream evidence before any present-tense claim. This pass read Git objects and started no process, so that evidence does not exist.

A1 additionally asked, on most rows, for a named repository owner's sign-off. There were no separate repository owners here. What was produced instead — evidence packets bound to Git blob ids, plus an independent verification and disclosure challenge — is recorded once in the contract with obtained: false. No page on this site claims an owner approved it.

The quarantined set is published as a register — the list of what is withheld and why is itself public, even though the content is not. See the documentation model.

What a reader should do with all this¶

Check the badge before you rely on a sentence.
Check last verified before you rely on a badge.
Open the evidence block if you need to know exactly what a claim rests on.
Read the availability token as well as the status badge; a verified capability can still be unavailable to you.
Treat Target contract and Unverified as invitations to ask, not as facts.

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:

onix-docs:tools/docs_hooks.py
onix-docs:manifest/page-route-contract.json
onix-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.