# 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:

1. Running production behaviour and validated runtime configuration.
2. Merged source code and automated tests on the product's documented baseline branch/commit.
3. Product wiki reference pages.
4. Repository README files and release notes.
5. 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.