feat: expose institutional architecture and runtime state

README.md

@@ -13,9 +13,15 @@ This repository owns:
 
 - backend module manifest `ops`
 - operator-facing status APIs
+- runtime-node registration, heartbeat, composition, stale-node, and expected
+  replica projection
+- audited API and worker drain/cancel controls
+- recovery-operation status and evidence-chain summaries
 - governance inventory for module-declared permissions, roles, capabilities,
   policies, documentation, access-control hooks, search providers, and
   migration ownership
+- sanitized runtime health, freshness, conflict, and recovery state for
+  configured external-provider bindings
 - deployment profile and sizing assumption summaries
 - WebUI route contribution `@govoplan/ops-webui`
 - future operational runbooks that describe the configured platform rather than
@@ -28,7 +34,19 @@ Core exposes the registry contract but does not own an operations dashboard.
 Ops projects the provider-neutral registry metadata and runtime checks into the
 operator-facing governance surface.
 
+Provider declarations describe supported behavior; module-owned runtime-state
+providers describe the currently configured bindings. An optional provider
+failure is isolated and reported as an attention state without suppressing the
+rest of the governance inventory. Secrets, endpoints, and raw provider errors
+are not part of this projection.
+
 ## Runbooks
 
 - `docs/SCALABILITY_PROFILES.md` explains how to use the Ops page with the
   canonical sizing matrix, readiness model, and profile-selection worksheet.
+
+The Runtime cluster panel is backed by Core's shared PostgreSQL coordination
+tables. A drain request is durable and is observed on the node heartbeat: API
+readiness closes and workers stop taking new queue work. The Recovery panel
+shows operations requiring forward recovery or manual intervention; it does not
+claim that a production database backup exists.