The Pillar Model
Why Nine Pillars?
The monorepo is organized into nine alphabetically-prefixed pillars, each representing a distinct operational domain:
| Code | Pillar | Domain | Owner |
|---|---|---|---|
| a | governance | Governance & standards | Platform leads |
| b | services | Application code | App teams |
| c | platform | Infrastructure as Code | Platform team |
| d | delivery | CI/CD & orchestration | Platform team |
| e | observability | Monitoring-as-code | SRE team |
| f | tooling | Developer utilities | SRE team |
| g | docs | Documentation | Platform leads |
| h | labs | R&D sandbox | All teams |
| i | aiops | Experimental AIOps workflows, isolated from the production control plane | SRE + Platform |
Coupling Rules
- Pillars should not import code from other pillars
- Cross-pillar dependencies are managed through contracts (see
a-governance/contracts/) - Services (b) consume infrastructure (c) and observability (e) through configuration, not code imports
- Delivery (d) orchestrates services (b) through metadata-driven workflows and GitOps manifests, not library calls
Current Control Planes
- Service ownership and baseline CI are generated from
d-apps/*/component.yaml - Alert naming and labels are governed centrally in naming-conventions.md and
a-governance/contracts/ - Grafana Cloud v2 promotion is environment-scoped under
f-observability/06-grafana-cloud-v2/envs/ - The observability (e) and platform (c) pillars are detailed further in Observability Overview and Platform Overview
Evolution Path
This monorepo is designed to be decomposable. Each pillar can become its own repository when team scale demands it. See ADR-001 for the rationale behind the current pillar model, and Architecture Overview for the concrete component map across pillars.
Local graph
Linked from 3 notes
Architecture Overview
The ShipSolid Platform Engineering Lab demonstrates enterprise-grade cloud-native patterns through a
Observability Overview
The observability pillar combines Alloy collector examples with a Terraform-managed Grafana Cloud
Platform Overview
The platform pillar is currently centered on Terraform workload roots under
Related notes
Signal Forge ADR-005: Separate collector configmaps per deployment mode
Keeps cloud and local Alloy collector configs in separate files rather than one conditional configmap, so each mode's exporters stay explicit and uncoupled.
Signal Forge ADR-003: Span metrics generated before tail sampling
Places the spanmetrics connector ahead of tail_sampling so RED metrics reflect all traffic instead of only the ~25% of traces that survive sampling.
Signal Forge ADR-002: SpanLink for async RabbitMQ propagation (not parent-child)
Uses a SpanLink, not a parent-child span relationship, to connect RabbitMQ consumer spans back to the producer span across async, retry-prone delivery.
Architecture Overview
Signal Forge's topology, service communication, trace propagation, and per-signal pipeline flow across local and Grafana Cloud deployment modes.