40 lines
1.6 KiB
Markdown
40 lines
1.6 KiB
Markdown
---
|
|
repo: ops-hub
|
|
updated: "2026-06-06"
|
|
---
|
|
|
|
# INTENT
|
|
|
|
## Why it exists
|
|
|
|
`ops-hub` is the Operations / System 1 extension for the interaction framework.
|
|
It turns operational reality into governed, queryable, and evidence-backed hub
|
|
records: environments, hosts, clusters, services, endpoints, releases, backups,
|
|
incidents, risks, runbooks, readiness gates, and migration waves.
|
|
|
|
It exists because Railiance and HelixForge operations need a durable
|
|
operational truth surface while the fleet transitions toward railiance01
|
|
production. State Hub continues to own workplans and decisions; **Core Hub**
|
|
owns the production framework API (`hub.coulomb.social` since 2026-07-03).
|
|
Historical Haskell Inter-Hub lives in `inter-hub-haskell` (retired). `ops-hub`
|
|
owns the operations extension behavior and posts evidence to Core Hub.
|
|
|
|
## Governing principle
|
|
|
|
This repository should stay focused on the purpose above. Work that changes its
|
|
authority, ownership boundaries, or operational promises should be captured in a
|
|
workplan before implementation.
|
|
|
|
The first implementation rule is: domain-specific runtime code belongs here,
|
|
while generic hub framework behavior belongs in Core Hub.
|
|
|
|
## What it enables
|
|
|
|
- Operators can see what runs where, how it is reached, and what evidence proves
|
|
it is healthy.
|
|
- Collectors, adapters, and scheduled probes can report operational facts into
|
|
Inter-Hub using the ops vocabulary.
|
|
- Readiness and migration gates can be represented as explicit, auditable
|
|
operational records.
|
|
- Future VSM hubs can reuse the extension pattern without turning Inter-Hub
|
|
itself into a domain-specific operations product.
|