Master Document Control
This document defines how the architecture baseline is controlled, versioned, promoted, and reviewed across the workspace. It is document control for architecture knowledge, not Git workflow guidance.Current Controlled Baseline
| Field | Value |
|---|---|
| Baseline ID | TREMOR-WORKSPACE-ARCH-2026-04-17A |
| Version | 3.0 |
| Effective date | 2026-04-17 |
| Governance model | whole-workspace |
| Workspace root | repository root |
| Primary platform root | local-pc/ |
| Register of record | Architecture Artefact Register |
Revision History
| Version | Date | Change | Outcome |
|---|---|---|---|
3.0 | 2026-04-17 | Externalized Ghost OS from the workspace and reduced the controlled architecture set to in-repo streams only | Current baseline |
2.1 | 2026-04-17 | Added a controlled canonical observation architecture page to the platform baseline | Superseded |
2.0 | 2026-04-17 | Converted the baseline from a canonical-with-adjacent model into a whole-workspace architecture map | Superseded |
1.0 | 2026-04-17 | Established a unified workspace architecture map, artefact register, and controlled document baseline | Superseded |
Controlled Set
These documents make up the current controlled architecture set.| Document | Role | Change trigger |
|---|---|---|
| Architecture | Uber architecture map and workspace boundary summary | Any material change to system topology, subsystem boundary, or workspace classification |
| Data Model | Canonical entity ownership and storage boundary | New table families, ownership shifts, or first-party versus vendor boundary changes |
| Observation Architecture | Canonical observation and signal-flow model | Changes to telemetry, traces, provenance, warehouse mirroring, or operator health boundaries |
| API Overview | Runtime and heartbeat API contract | Route semantics, execution contract, or auth boundary changes |
| Schema Map | Route and service ownership appendix | Service ownership or entity-route mapping changes |
| Deployment Operations | Ingress and deployment topology | Mode, ingress, or runtime hosting changes |
| Runtime Services | Intelligence overlay topology | Observability, warehouse, or supporting runtime-service changes |
| Adapters Overview | Adapter execution boundary | New adapters, packaging changes, or execution lifecycle changes |
| Architecture Artefact Register | Workspace artefact classification register | Promotion, demotion, addition, or retirement of artefact families |
| Master Document Control | Baseline version control and governance rules | Any baseline or control-model change |
tremor-native/docs/runtime-architecture.md | Native runtime canonical stream doc | Native runtime transport, state-sync, or boundary changes |
| Architecture & Schema | Live Tremor operating overlay | Tenant-specific operating, schema, or governance updates |
Versioning Rules
Update the baseline version when the controlled architecture set changes.- Major: use when the primary platform root, governance model, repo boundary, or authority model changes.
- Minor: use when a new controlled doc is added, a family is promoted or demoted in the register, or a subsystem map changes materially.
- Patch: use for clarifications, cross-link fixes, tighter wording, or non-structural register maintenance.
Change Control Order
When the architecture changes, update the document set in this order:- Update the code-grounded controlled document for the changed subsystem or stream.
- Update the relevant companion docs such as data model, API, deploy, or adapters.
- Update the Architecture Artefact Register if authority or scope classification changed.
- Update this document if the baseline version or control rules changed.
- Update ADRs when the change represents a durable decision rather than a descriptive refresh.
- Update the Tremor operating wiki only after the canonical platform shape is settled.
- Verify navigation, cross-links, and doc discoverability.
Promotion And Demotion Rules
Promote to canonical or stronger authority only when:
- the document is grounded in the current repo and runtime behavior
- its scope is clear and non-overlapping with existing canonical pages
- it is needed often enough to justify controlled maintenance
- it is linked from the controlled docs set or a governing ADR
Demote to reference or prototype when:
- a newer code-grounded page supersedes it
- it documents exploratory target state that no longer matches implementation
- it remains useful for history but should not drive current design decisions
Review Triggers
Review the controlled set whenever any of the following happen:- repo boundaries or monorepo strategy change
- a new first-party storage system or vendor boundary is introduced
- heartbeat, adapter, or runtime-auth behavior changes materially
- the native runtime becomes more tightly coupled to the control plane
- a sibling project needs to be promoted back into the shared architecture baseline
- schema authority order changes or new contract packages are added
Stewardship Matrix
| Surface | Stewardship focus |
|---|---|
start/architecture.md | Platform architecture and workspace boundary owners |
start/data-model.md | Schema and persistence owners |
start/observation-architecture.md | Observability, provenance, and operator-signal owners |
api/overview.md and api/schema-map.md | API and orchestration owners |
deploy/overview.md and deploy/runtime-services.md | Platform operations and observability owners |
adapters/overview.md | Adapter and runtime-bridge owners |
architecture-records/* | Architecture governance owners |
tremor-native/docs/runtime-architecture.md | Native runtime owners |
companies/tremor/wiki/* | Tremor operating and tenant owners |
Verification Checklist
Before calling a baseline update complete:- confirm the changed subsystem is reflected in its canonical page
- confirm the artefact register still classifies the affected family correctly
- confirm this document’s version still matches the scope of the change
- confirm docs navigation and cross-links expose the new source of truth
- run
git diff --checkin the relevant repo