Ideas: Should ASI:BUILD expose a CognitiveCycle health dashboard via MCP or REST?

[web3guru888]

Context

With the three-layer fault tolerance system (#137, #139) in place, the CognitiveCycle generates rich health data every tick:

• Per-module circuit breaker state (CLOSED / OPEN / HALF_OPEN)
• Per-module retry counts and budget consumption
• Degraded Blackboard keys (modules serving last-good data)
• Tick wall-clock time and per-tier timing
• Emergency mode flag

This data is currently only accessible by consuming cycle.fault_summary events from the EventBus. For operators running ASI:BUILD in production, that's not enough — they need a real-time health view.

The question

How should operators observe the health of a running CognitiveCycle?

Option A: MCP tool endpoint

Expose health as a read-only MCP tool alongside the existing Kenny Graph server:

@mcp_tool
async def get_cycle_health() -> dict:
    """Returns current CognitiveCycle health snapshot."""
    return {
        "tick_count": cycle.tick_count,
        "open_circuits": [n for n, b in cycle.breakers.items() if b.state == "OPEN"],
        "half_open_circuits": [n for n, b in cycle.breakers.items() if b.state == "HALF_OPEN"],
        "degraded_keys": cycle.last_fault_summary.degraded_keys,
        "emergency_mode": cycle.last_fault_summary.emergency_mode,
        "last_tick_ms": cycle.last_fault_summary.wall_ms,
    }

Pro: Composable with existing MCP client tooling; works with Claude Desktop
Con: Polling-based (MCP doesn't push events); latency depends on poll interval

Option B: SSE stream on the FastAPI server

Add a /cycle/health/stream Server-Sent Events endpoint that pushes a health delta after each tick:

GET /cycle/health/stream
Content-Type: text/event-stream

data: {"tick":147,"open":[],"degraded":[],"emergency":false,"wall_ms":54.2}
data: {"tick":148,"open":["reasoning"],"degraded":["reasoning.result"],"emergency":false,"wall_ms":48.7}
data: {"tick":149,"open":["reasoning"],"degraded":["reasoning.result"],"emergency":false,"wall_ms":47.1}

Pro: Real-time push; easy to consume with curl or a browser dashboard
Con: Adds another server dependency; SSE doesn't work well behind some proxies

Option C: Prometheus metrics

Expose health as Prometheus metrics, readable by Grafana:

# HELP cycle_circuit_state Module circuit breaker state (0=CLOSED, 1=HALF_OPEN, 2=OPEN)
# TYPE cycle_circuit_state gauge
cycle_circuit_state{module="reasoning"} 2
cycle_circuit_state{module="safety"} 0

# HELP cycle_tick_duration_ms Tick wall-clock duration in milliseconds
# TYPE cycle_tick_duration_ms histogram
cycle_tick_duration_ms_bucket{le="50"} 127
cycle_tick_duration_ms_bucket{le="100"} 184

Pro: Industry standard; works with any Grafana/AlertManager setup; handles history
Con: Requires running a Prometheus scrape target; more infra to set up

Option D: Blackboard-native — query the Blackboard directly

The CycleFaultSummary is already written to the Blackboard every tick. An operator could just read it:

client = BlackboardClient("ws://localhost:8080")
summary = client.subscribe("cycle.fault_summary")
async for event in summary:
    print(event)

Pro: Zero additional infra; uses the existing Blackboard subscription model
Con: Requires understanding the Blackboard API; not accessible from outside the process

---

My current thinking

Option B (SSE) makes the most sense for the first iteration because:

1. It fits the existing FastAPI server we already have for Kenny Graph
2. SSE is simple to add (5–10 lines) and requires no client library
3. It's immediately useful for debugging via curl
4. Option C (Prometheus) is the natural evolution once you need alerting

Questions for the community

1. What format would be most useful to you when debugging a slow/broken CognitiveCycle?
2. Does anyone have a Grafana setup they'd want to point at ASI:BUILD metrics?
3. Should the health endpoint include per-tier timing breakdown, or just circuit/degradation state?
4. How often should health data be sampled — every tick (up to 10Hz), or on a longer interval (1s)?

Tagging this as part of the Phase 4 production deployment story (Discussion #123, Phase 4.4).