Skip to content

How to contribute

VerifiedOwner Documentation integratorLast verified onix-docs@a2-publication

This documentation is written by people and machines with access to the ONIX source repositories. It is not open to public contribution, because every claim on the site has to be checkable against private source at a pinned commit.

If you have that access, this page is the process.

The one rule

A change to a claim requires a change to its evidence.

Everything else follows from that. If you cannot name a repository@commit:path that supports a sentence, the sentence cannot be published as Verified. It can be published as Unverified with the open question recorded — that is a legitimate and useful contribution — but it cannot be presented as fact.

The loop

  1. Pick the owning lane. Product pages are frontend-owned, backend and platform pages backend-owned, native and MCP pages native-owned, and cross-cutting pages integrator-owned. A page may define only what its owner owns; see the authority model.

  2. Read the source at a pin, not the working tree. Use immutable Git objects:

git -C <repo> ls-tree -r --name-only <commit>
git -C <repo> show <commit>:<path>
git -C <repo> grep -n '<pattern>' <commit> -- '<pathspec>'

A dirty working tree is not evidence. Neither is a README that contradicts an executable lock; see the tie-break rules in the authority model.

  1. Write the page with complete front matter. The build refuses a page without title, summary, status, owner, last_verified, source_pins and at least two evidence anchors. See documentation standards.

  2. Update the route contract if you add, move or remove a page. Navigation, the redirect map and the page census are all generated from manifest/page-route-contract.json. Editing mkdocs.yml directly will be reverted by the drift check.

python tools/gen_manifest.py
python tools/gen_mkdocs.py
  1. Build strictly and check.
python -m mkdocs build --strict
python tools/check_drift.py
python tools/census.py
python tools/safety_scan.py
  1. Let someone else try to break it. Every evidence packet records a falsifiable_check per claim — an exact command a reviewer can run to attempt disproof. Review means running some of them, not reading prose sympathetically. See evidence and testing.

What the build enforces without you

These failures stop a release automatically, so they never reach review:

Check Fails when
Front-matter validation A page lacks provenance metadata, or uses a status token outside the vocabulary.
Strict build Any internal link, anchor or nav reference does not resolve.
Route-contract closure A legacy page is left unaccounted for, or a redirect points at a route that does not exist.
Drift check mkdocs.yml or a generated reference page no longer matches the manifest and evidence packets it is derived from.
Census The published page set disagrees with the manifest.
Safety scan A forbidden legacy brand term, a credential-shaped string, or a private-topology path appears in published output.
Determinism Two consecutive production builds do not produce identical content.

What not to do

  • Do not restate a definition owned by another lane. Link to it.
  • Do not copy upstream NautilusTrader or charting-library documentation. Link to it. See upstream reference discipline.
  • Do not describe a private, internal or test-stage capability as available.
  • Do not claim real-money execution.
  • Do not publish operational runbooks, private hostnames, internal addresses, credentials, signing identities or incident detail. If a change needs one of these to make sense, the change belongs in the quarantined internal set.
  • Do not delete a retired page. Mark it retired and let the contract redirect its URL, so a reader who remembers it is told it is gone.
Evidence and source pins for this page

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

Verified on against the following immutable sources:

  • onix-docs:tools/docs_hooks.py
  • onix-docs:tools/gen_manifest.py
  • onix-docs:manifest/page-route-contract.json

Status tokens are defined on the documentation and status model page. Every pin on this site is listed under versions and source pins.