> ## Documentation Index
> Fetch the complete documentation index at: https://sdlc-rstack.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Operations Center

> One operational-truth surface: is the data fresh, is the runtime healthy, what recovery exists, and what remediation is safe.

The Operations Center (#284) answers four questions a team otherwise has to
piece together across six telemetry pages: is the data I'm looking at fresh,
is anything actually broken, what recovery state exists if it is, and what's
safe to do about it. It is a server-owned projection — `buildOperationsProjection`
in `src/observability/dashboard/state/operations.js` — that **never invents a
competing formula or count**: every section reads from a projection that
already exists elsewhere (the Action Inbox, the Environment page, the
pipeline rollup's checkpoints/retries/context-pressure blocks, presence, the
live feed) and reshapes it into one page.

## How it works

The projection builds six sections plus a client-local transport section,
combined into one `operations` object:

```js theme={null}
// state/operations.js
{
  snapshot: { generatedAt: state.ts ?? null },
  status: worst(Object.values(sections).map(s => s.status ?? 'ok')),
  sections: {
    health,        // Action Inbox rollup
    integrations,   // environment report + integrations.json + config validation
    recovery,       // per-run checkpoints + retry budgets
    contextMemory,  // context-pressure warnings, memory-write skips, metrics drift
    agents,         // presence
    feed,           // pointer only — the raw feed stays a full page
  }
}
```

Every section carries a `status` (`'ok' | 'warn' | 'blocked' | 'unknown'`) and
an `availability` (`'available' | 'unavailable'`) field, and the page-level
`status` is the worst of all sections via a shared `worst()` reducer (`blocked`
\> `warn` > `unknown` > `ok`). This is deliberate: **a silent producer
reports `unknown`, never `ok`** — health is not green merely because nothing
reported. `availability` is tracked separately from `status` so a page can
render "no data for this scope" as its own honest state, distinct from
"healthy" or "failed".

**Section 1 — Transport.** The only section *not* server-computed. WebSocket
vs. REST-poll mode and snapshot age are the browser's own truth, so
`renderOpsTransport` in `ui/pages/operations.js` reuses the exact
`classifyFreshness` / `WS_CONNECTED` / `LAST_SNAPSHOT_AT` state the topbar
freshness chip already runs on, stamped against the server's
`operations.snapshot.generatedAt`. A `stale`/`reconnecting`/`disconnected`
verdict shows a "Showing last-known data" banner rather than silently letting
old numbers look current.

**Section 2 — Health.** Derived from the Action Inbox records
(`state.actions`), never counted alongside it: open actions are anything
whose status isn't in `{approved, rejected, resolved, consumed, waived,
closed}`; `blocking` is the subset with `blocking === true`. Status is
`blocked` if any open action blocks, `warn` if there are open-but-nonblocking
items, else `ok`. The top 5 open items are surfaced with title/severity, and a
button link jumps to [Approvals & Governance](/business-hub/approvals-and-governance).

**Section 3 — Integrations.** Reads the environment projection
(`environment.report`, `environment.integrations`) plus per-root config
validation issues. `warn` when there are unresolved `setup_needs` or config
issues; `ok` when a report or integrations config exists with none; `unknown`
when neither producer has ever reported.

**Section 4 — Recovery.** Per run, reads the pipeline rollup's disk-verified
`checkpoints.stages` block (`{id, restorable, reason}`) and the retry rollup
(`retries.scheduled/exhausted/human_required`). A stage is `restorable` when
`restorable === true`, and `corrupt` when its `reason` string starts with
`"corrupt"` — **restorable and corrupt are tracked as distinct states**, never
collapsed into a single boolean. A run is only listed if it has stages,
pending retries, or a nonzero `checkpoints.reverted` count. Status is `warn`
if any run has a corrupt checkpoint or an exhausted/human-required retry,
else `ok` once at least one rollup has been seen.

**Section 5 — Context & memory.** Sums each run's
`pipelineRollup.context_pressure` (`total` plus a `by_source` breakdown), and
scans the live feed for `episode_memory_skipped_untrusted` and
`metrics_write_failed` event counts. `warn` if any of the three is nonzero.

**Section 6 — Agents.** A thin pass-through of the presence projection
(first 12 entries) — presence is informational, so this section is always
`ok` once available; an empty team is not treated as a health problem.

**Section 7 — Feed.** Deliberately shallow: only an availability flag and a
recent-event count. The raw event stream stays its own full page (Live Feed);
Operations links to it rather than duplicating it.

<Note>
  The module's own header comment states the truth-semantics contract
  verbatim: `status` is never `'ok'` for a silent producer, `availability`
  distinguishes "no data" from "healthy or failed", and transport is
  browser-local because "a server cannot honestly report a browser's
  connection."
</Note>

## Try it

The page is served as part of the Business Hub bundle — no separate command.
Open the hub and select **Operations** from the navigation:

```bash theme={null}
npx rstack-agents hub
```

Each section renders its status pill first, then either its content or an
honest empty state (`opsUnavailable(sectionName)` — "has no producer data in
this scope. Unknown is not healthy — start or scope a run to evaluate it.")
when `availability !== 'available'`. Recovery rows show restorable/CORRUPT
checkpoint pills plus retry-budget counts per run; Health and Integrations
each carry a button back to their source page (Action Inbox, Environment)
rather than duplicating the write path.

<Info>
  Every count on this page reconciles with its source page by construction —
  the Health section's `open`/`blocking` counts are computed *from* the
  Action Inbox records, not alongside them, so the two pages can't drift.
</Info>

## Related

* [Business Hub](/business-hub/overview-and-navigation) — the hub overview, launch, and full page list
* [Approvals & Governance](/business-hub/approvals-and-governance) — the source for the Health section
* [Evidence Center](/business-hub/evidence-center) — checkpoint and evidence detail behind Recovery
* [Data Visualizations](/business-hub/data-visualizations) — quality/risk and stage-health charts alongside Operations