# Ops Hub Activity-Core Fallback Validation

Date: 2026-06-16

Workplan: `IHUB-WP-0022`

## Validation Result

The State Hub fallback path is implemented, locally tested in activity-core,
and now verified through a live Railiance01 activity-core manual trigger.

Direct query:

```text
GET http://127.0.0.1:8000/progress/?event_type=ops_inventory_probe&limit=20
```

Observed result on 2026-06-16:

```json
[
  {
    "id": "db408146-0310-4ac3-ac77-f73c5a41e070",
    "event_type": "ops_inventory_probe",
    "summary": "Ops inventory probe: 0 ok, 4 degraded, 0 down, 5 skipped",
    "author": "activity-core",
    "created_at": "2026-06-16T05:34:02.711888Z"
  }
]
```

Railiance also posted verifier evidence note
`60256e9a-9d1b-44db-8999-738cf03bca2e`, proving that the progress event was
matched to the exact manual activity-core trigger run:

- manual workflow:
  `activity-40d15a87-7ff6-4d8e-992c-37df15f95110:manual-d2daa0e4-2d54-430e-a957-dca0ec9f469d`
- matched activity-core run id:
  `90e3b112-d1e3-51af-8fb2-cb61f26add17`
- matched fallback progress:
  `db408146-0310-4ac3-ac77-f73c5a41e070`
- immutable runtime evidence:
  `api_image_id=sha256:5ff92a8217c450ae06075d00862b6e2a92a83ca09eea18b5a5e96b5d2d728b35`

This means Inter-Hub can cite live fallback evidence as the continuity
artifact for activity-core while the governed Inter-Hub widget/API-key path
remains explicitly deferred.

## What Is Validated

Activity-core local tests and the Railiance01 verifier now validate the
fallback sink shape:

- `state-hub-progress` posts one compact `ops_inventory_probe` progress event
  per run.
- The fallback idempotency key is stable:
  `activity_core_run_id:context_key:ops_inventory_probe`.
- The posted summary is compact, for example:
  `Ops inventory probe: 1 ok, 0 degraded, 0 down, 1 skipped`.
- The detail includes `activity_id`, `activity_core_run_id`, `scheduled_for`,
  `source_type`, `context_key`, `idempotency_key`, and a compact `probe`
  payload.
- The compact probe strips response bodies, authorization headers, credentials,
  URL query strings, and token-like values.
- Inter-Hub sink config absence is a clean skip with
  `reason = missing_inter_hub_config`.
- When config is present but submission is not implemented, the result is a
  clean skip with `reason = inter_hub_sink_deferred`.
- Railiance verifier evidence correlates the State Hub progress event to the
  exact manual activity-core trigger run id instead of accepting any fresh
  `ops_inventory_probe`.
- The verifier evidence includes immutable runtime identity through the live
  `actcore-api` container image digest.

## What Is Not Yet Validated

- No live Inter-Hub event has been submitted from activity-core.
- No production `OPS_HUB_KEY` handoff has been verified.
- No `OPS_HUB_WIDGET_MAPPING` has been deployed into the activity-core runtime.
- No per-entity widget mapping has been smoke-tested against production
  ops-hub widgets.

## Gaps Compared With Inter-Hub Submission

State Hub fallback is useful as continuity evidence, but it is not a full
replacement for Inter-Hub submission:

- It records one compact run summary, not one governed widget event per entity.
- It cannot attach annotations directly to the affected service or endpoint
  widget.
- It does not prove ops-hub manifest vocabulary enforcement.
- It does not prove API consumer, key, rate-limit, or widget mapping behavior.
- It does not populate Inter-Hub event lists for hub dashboards or downstream
  widget governance workflows.

## Closure Recommendation

`ACTIVITY-WP-0007/T06` may remain closed using fallback-deferred closure.
The live fallback path now has non-secret State Hub evidence, and the
Inter-Hub submission path is explicitly deferred until `IHUB-WP-0022-T03`,
`IHUB-WP-0022-T04`, and `IHUB-WP-0022-T07` complete.

This is not full Inter-Hub activation. The remaining full activation path is:

1. Provision `OPS_HUB_KEY`.
2. Deploy `OPS_HUB_WIDGET_MAPPING`.
3. Seed and verify the ops-hub widgets.
4. Submit one accepted Inter-Hub event per activity-core event type.

Until that path is satisfied, Inter-Hub should keep its own per-entity intake
tasks open, but it does not need to hold the activity-core closure gate open.

## Next Evidence To Capture

- Confirmation that Inter-Hub sink remains skipped cleanly while config is
  absent or deferred in the deployed runtime.
- After ops-hub activation, event ids for one accepted Inter-Hub submission per
  event type.