prj-state-hub-retirement/history/2026-08-09-genesis.md

Project genesis

Recorded: 2026-08-09

Starting condition

State Hub had grown from a useful repository-backed work coordination service into a broad system containing development records, messages, progress, capability workflows, service and third-party catalogs, telemetry, execution controls, and cross-domain projections. The breadth made orientation and authority boundaries increasingly difficult.

An earlier architecture proposed domain hubs around a shared framework and an Orthogonal Architecture Standard. The second-generation Inter-Hub runtime was implemented in Haskell/IHP but proved operationally too specialized. A third-generation Python/FastAPI core-hub replacement was deployed, while generic primitives were extracted into a separate hub-core library.

This successfully retired the Haskell production path, but left three problems:

• core-hub and hub-core split one conceptual framework across confusingly named repositories;
• the Orthogonal Architecture Standard remained mostly documentary rather than an executable extension and information model; and
• State Hub retained a large mixture of repository, cross-domain, and domain-specific responsibilities.

Direction established

The project begins from the following direction:

• consolidate core-hub into hub-core and make hub-core the surviving cross-domain framework and runtime;
• build domain hubs through explicit extension contracts rather than a mesh of direct service dependencies;
• keep specialized authorities such as identity, authorization, scheduling, issues, audit, and finance behind delegated ports;
• create Repo Manager as the complete repository integration boundary;
• move cross-entity communication and information flow into hub-core and its supporting components; and
• retire State Hub completely once every capability and consumer has an evidence-backed disposition.

Why a project repository

The work spans many repositories and changes their relationships. No single functional repository should own the transformation plan. This repository is therefore the first proposed prj- repository flavor: a temporary, outcome-oriented coordination and provenance surface.

It owns the project goal and gates while implementation remains local to the affected repositories. When the outcome is achieved and durable decisions have moved to their permanent homes, this repository is archived.