Wiki Governance

The wiki is the human-readable knowledge layer for Soatrix. It is Git-backed so documentation changes have history, authorship and reversible revisions.

Source-of-truth hierarchy

Use this order when sources disagree:

Running production behaviour and validated runtime configuration.
Merged source code and automated tests on the product's documented baseline branch/commit.
Product wiki reference pages.
Repository README files and release notes.
Planning documents, tickets, chat discussions and historical notes.

A lower source should be updated when it is proven stale; it should not be used to override a higher source silently.

Page lifecycle

Every substantive product area should be recognisable as one of four states:

Reference — describes implemented behaviour.
Runbook — executable operational procedure.
Decision — durable architectural or policy rationale.
Plan — proposed/future work that is not yet a supported contract.

Avoid wording that makes a plan sound implemented.

Verification dates

Pages that describe fast-moving software should state the baseline used for verification. For repository-backed products, record the branch and abbreviated commit SHA near the top of the product's Current Status page. Do not place a mutable word such as “latest” in a durable page without a date or commit.

Changes

When a code change alters a documented contract, update the relevant wiki page in the same release/change window. Examples include:

a new supported runtime version;
a command or permission change;
a configuration schema change;
a new content authoring field;
a different persistence or rollback guarantee;
a changed operational requirement.

Deleting and superseding pages

Prefer a short superseded page that links to the replacement when old links are likely to exist. Delete only when the page was erroneous, sensitive or has no useful historical navigation value.

Git safety

The wiki repository history may contain old text even after a page is edited. Never commit passwords, private keys, tokens, one-time secrets, database credentials or personal data that should not persist in Git history. Use a secrets manager or the relevant platform's protected configuration facility instead.