A source-based documentation set#
These guides are authored from five read-only documentation mounts: Matrix Core, Portal, Messages, Workflow and Infrastructure. The public articles explain architecture, implementation decisions and integration contracts. The source index preserves a short summary of each engineering document used.
Every guide has a stable URL, a summary, a review date, a status label and source references. This makes it possible to trace a technical statement back to its owning component without exposing private installation inputs or treating historical notes as current acceptance.
Interpret the status labels#
| Label | Meaning |
|---|---|
| Documented | An architecture, ownership or integration contract is described in the reviewed source. This is not a blanket production-readiness claim. |
| Release-dependent | The capability depends on the selected package, candidate, template or integration baseline. Verify the installed bytes and relevant acceptance. |
| Planned | The source describes an intended direction. Do not use it as evidence of an implemented product capability. |
A guide can discuss several related features with different maturity. Its body retains more specific boundaries than the page-level label. When a newer capability index qualifies an older architecture paragraph, the guide records that distinction rather than treating both as one uniform release.
Updating the documentation#
The site is built from editable Markdown, small metadata files and source-controlled diagram definitions. A build generates the navigation, article pages, contents panels, search index, source catalog and sitemap together.
The maintenance process is:
- Detect source changes. Compare hashes of the referenced documents with the recorded review baseline. A local inventory also identifies newly added or removed source documentation.
- Review affected guides. The change report maps changed source files to the public pages that depend on them. Read the changed source and update the summary, contract details, examples and maturity labels as needed.
- Update diagrams with the text. Check ownership, message direction, success/error paths and compatibility boundaries. Diagram labels are part of the technical content.
- Record the reviewed baseline. Source hashes and the review date are updated after the editorial review. Rebuilding alone does not mean upstream changes have been reviewed.
- Build and verify. Check local navigation and anchors, source references, generated assets, search behavior, code examples and responsive layouts before publication.
The source repository contains the build commands and update instructions. The published site has no dependency on a developer's filesystem or a live connection to the documentation mounts.
What source references mean#
References such as /matrix/core/consumer/capabilities.md identify a document within the engineering workspace. They are provenance labels, not public server routes. Follow a reference to its source-index summary and the guides that use it.
The source index covers the documents used for this public documentation set. It is not a raw mirror of every historical implementation prompt, release artifact, private deployment input or acceptance log in the repositories.
Report a correction#
Include the guide URL, the affected heading, the package or service version and the observed discrepancy. A useful correction distinguishes a documentation error from a feature present only in a newer candidate or a differently configured installation.
Contact the Shared Kernel engineering team for documentation and integration questions. The technical reference and the selected application's own acceptance evidence should be reviewed together when making implementation or operating decisions.