# Core Hub runtime absorption inventory

**Status:** complete for `CORE-WP-0010-T01`  
**Reviewed:** 2026-08-21

This inventory defines the runtime, contract, data, consumer, and deployment
surfaces that a hub-core replacement must preserve. It is an input to the
joint absorption plan in `HUB-WP-0004`; it does not choose hub-core's packaging
or port model.

## Public and operator contract

The checked-in OpenAPI snapshot documents 22 paths:

| Area | Paths / behavior to preserve |
| --- | --- |
| Discovery | `/api/v2/hubs`, `/api/v2/hub-registry`, `/api/v2/manifests`, manifest patch and activation |
| Credentials | `/api/v2/api-consumers`, `/api/v2/api-consumers/{id}/keys`, `/api/v2/token` |
| Interaction | `/api/v2/widgets`, `/api/v2/widget-types`, `/api/v2/interaction-events` |
| Deferred resources | annotation categories/annotations, policy scopes, requirement candidates, decision records, deployment records, outcome signals |
| Operations | `/healthz`, `/readyz`, `/console` |

Compatibility discovery also serves `/api/v2/openapi.json`,
`/api/v2/openapi.yaml`, `/api/v2/docs`, and historical unprefixed aliases.
These must either remain available or have an explicit compatibility gateway.

## Durable data

The production schema contains these application tables:

- `hubs`
- `hub_capability_manifests`
- `api_consumers`
- `api_keys`
- `widgets`
- `interaction_events`
- `migration_runs`

`alembic_version` is migration metadata. Annotation, requirement, decision,
deployment, and outcome routes currently return empty collections and do not
have durable models; absorption must not claim data that does not exist.

## Contract and fixture assets

The `contracts/` tree is portable compatibility evidence and should move with
the runtime or remain versioned as historical fixtures. It includes the
OpenAPI snapshot, JSON schemas, catalogs, and consumer fixtures. Database
migrations and row-count/replay checks remain owned by the runtime migration
slice until hub-core accepts them.

## Consumers and smoke gates

- **ops-hub** depends on protected hub records and the compatibility OpenAPI
  paths. Its bootstrap reads or creates hubs, manifests, API consumers, keys,
  widgets, and interaction events.
- **activity-core** depends on health/readiness, widget types, protected hub
  resolution, and posting then reading back interaction-event evidence.

Both consumer gates must pass against hub-core during dual-run and again after
traffic cutover. Core Hub remains the rollback runtime until those checks and
data comparisons succeed.

## Extension-port mapping

| Gen3 port | Current Core Hub coverage |
| --- | --- |
| Registry | partial: hubs and manifests |
| Addressing | partial: hub identity and protected records |
| Interaction events | partial: durable event sink/readback |
| Projection | partial: operator views and compatibility reads |
| Messaging | absent / external |
| Progress and work | absent / external |
| Repository and schedule | absent / external |
| Telemetry | health/readiness only |
| Policy | names/catalog surface only; authorization remains external |

This mapping prevents a route-for-route move from being mistaken for complete
Gen3 extension absorption.

## Deployment and ownership boundary

- **core-hub** owns application code, contracts, migrations, image contents,
  and consumer compatibility evidence.
- **rapp-core-hub** owns Helm values/templates, policy and secret references,
  rollout declaration, and live smoke evidence.
- **railiance-platform / rapp-postgres** owns platform PostgreSQL, credential
  custody, backups, and restore posture.

The Kubernetes manifests checked into this repository describe the former
CoulombCore deployment and are retained as source/history evidence. They are
not current production deployment truth.

## Move constraints

1. `HUB-WP-0004-T03` must decide whether hub-core ships the primary runtime
   image or a library with a permanently owned host.
2. `HUB-WP-0004-T04` must settle the minimal extension ports before absorption
   slices are designed.
3. `HUB-WP-0004-T06` and `CORE-WP-0010-T02` must jointly define dual-run,
   traffic shift, rollback, and smoke ownership.
4. Every durable slice needs schema/row-count comparison and fixture replay.
5. Repository archive is last: only after public traffic, consumer gates,
   residual ownership, and rollback retirement are evidenced.