Blame

e23584 Dan Alexander 2026-09-14 10:46:55
Add company wiki standards and VoxelCore docs This change establishes the shared company knowledge structure, governance, engineering, security, and incident/change standards. It also adds the VoxelHorizons product tree with a complete VoxelCore documentation set covering architecture, operations, authoring, version support, resource pack compilation, runtime reloads, and testing/release workflows.
1
# Soatrix Knowledge Base
2
3
Welcome to the central technical and operational knowledge base for **Soatrix** products and services.
4
5
This wiki is designed as a long-lived source of truth rather than a collection of disconnected notes. Company-wide standards live under **Company**, product documentation lives under **Products**, and reusable documentation patterns live under **Templates**.
6
7
## Start here
8
9
- [[Company/Index]] — how the knowledge base is organised and governed.
10
- [[Products/Index]] — product catalogue and technical documentation.
11
- [[Templates/Index]] — reusable page structures for future services, decisions, incidents and releases.
12
13
## Current product documentation
14
15
### Voxel Horizons
16
17
- [[Products/Voxel-Horizons/Index]]
18
- [[Products/Voxel-Horizons/VoxelCore/Index]] — complete VoxelCore item/content MVP documentation.
19
- [[Products/Voxel-Horizons/VoxelCore/Current-Status]] — implementation snapshot pinned to `452b569` on `14 September 2026`.
20
21
## Knowledge-base principles
22
23
1. **The implementation wins.** Runtime code, tests and deployed configuration are authoritative when a prose page conflicts with reality.
24
2. **Implemented and planned behaviour are never mixed.** Roadmaps are labelled as plans; reference pages describe what exists now.
25
3. **Pages are scoped.** Company standards should not contain product-specific implementation details; product pages should link to company standards instead of duplicating them.
26
4. **Operational knowledge is actionable.** Commands, paths, validation steps and rollback behaviour should be documented where people need them.
27
5. **Changes are reviewable.** OtterWiki's Git-backed history is part of the documentation workflow, not merely a backup.
28
29
See [[Company/Wiki-Governance]] for the maintenance model.