Mission Control

Mission Control is the operations home of the Admin UI (http://localhost:3002), with three entries in the sidebar: Inbox — the findings awaiting a decision, the continuous checks that raise them and the weekly summary; Overview — the estate as Resource Group cards, the landing page; and Analytics — the tabbed metrics drill-down. The overview answers, at a glance: what’s flowing through the gateway, what is it costing, what did governance stop, and is anything on fire?

The card dashboard

The landing page shows your AI estate as Resource Group cards — everything you run goes through a Resource Group, so the RG is the unit on the board. Organizational groups sit at the top; clicking one drills into its teams and finally into individual AI Systems, with a breadcrumb to walk back up. Search flattens the hierarchy when you’re hunting one system among hundreds.

Each card carries two kinds of information, and the distinction is deliberate:

• Measurements — spend, runs, cost per completed task and the spend trend. These follow the window selector (24h / 7d / 30d / 90d / All time).
• Judgments — health, the assurance verdict, and the Big-T workload class. These are pinned to the standard 30-day assurance window and do not move with the selector: “all-time healthy” is not a claim Brutor will make.

The coloured left edge, the Learning state and the verdict vocabulary are explained in How Brutor learns. Group cards aggregate their subtree with sums for the additive metrics and worst-of for judgments — nine healthy systems and one in violation reads Violations, never an average. The subtree’s workload class renders as contains T(n·k) so a group is never mistaken for owning the class itself.

Worst-of needs an honest denominator. A system leaves the rollup only by attestation — a reason (retired, deprecated, no_evidence_acknowledged, scheduled_offline), a note, and for the temporary reasons an expiry — set on the AI System’s general tab. Deprecated and retired lifecycle stages exclude automatically. Group cards count their excluded systems, the Assurance Report and the weekly digest list every exclusion, and a lapsed exclusion re-enters the rollup and raises an inbox finding of its own.

Two pseudo-cards keep the board honest: Unattributed runs (governed traffic that matched no AI System — a to-do list, not an error) and Bought AI — observed (imported vendor usage that is costed but never enforced).

Tokenomics on the cards

The workload class chip uses Big-T notation — Big-O for tokens, from the Tokenomics Foundation’s Big-T Notation framework: T(1) cache-dominated, T(n) about one model call per task, T(n·k) a multiplying loop, T(n·k·a) agents delegating to agents. Brutor measures the class from the run ledger rather than estimating it, and asserts no class below 20 recent runs.

The Workload classes — T(n·k·a) guide button at the top of the dashboard opens the full primer: the complexity ladder (including T(log n) and T(∞), which Brutor deliberately never asserts — the first happens inside your pipeline where the gateway can’t observe it, the second because an unbounded loop arrives as a run with a large action count and a breached envelope, which is a finding rather than a class), how the classes are meant to be used, and where a control plane fits. Each card’s ⓘ then explains just that card’s own class, assuming you’ve read the guide. All of this text is served from one server-side definition, so the dashboard and any other surface always describe a term identically.

What bounds a runaway loop

Delegation depth is hard-capped by the gateway, so the a term cannot run away. Loop iteration is bounded by the per-group call, token and spend quotas you configure — they are checked in flight on every path, but only where you set them, and spend caps block only with hard stop enabled. Idle timeouts are not a spend control: they close an abandoned run in the ledger, and a run calling flat out is never idle.

A declared cost-per-task bound from the system’s contract is shown beside the measured value and turns red when breached. A red findings badge counts open drift, contract and liveness findings; the bell in the header opens the operations drawer — usage and system alerts — with one line counting open assurance findings that links to the Inbox.

Assurance Inbox

Under Mission Control → Inbox, together with the continuous checks and the weekly summary. The sidebar item carries two badges — open critical findings in red, open warnings in yellow — and the Overview’s alerts drawer is operations-only: usage and system alerts that are not also findings, with one line pointing at the Inbox for those that are (a liveness miss is raised in both places on purpose: paged from the alert, decided in the Inbox).

The triage queue of findings awaiting human review, fed by signals the platform already produces: guardrail blocks, drift detections, contract breaches, health transitions, liveness misses, failed runs, budget hard-stops and expired approvals. Recurring signals dedupe into one item with an occurrence counter — a storm is one row, not five hundred.

Resolving an item requires a disposition (true_positive, false_positive, expected, fixed) and a note; both are recorded in an append-only trail and surface in the Assurance Report’s Human review section — the evidence that someone accountable looked. Reopening never erases a prior disposition from the trail.

Warn-mode guardrail hits and approval timeouts arrive at info severity and are filtered out of the default view, so an enforcement pilot builds disposition history without drowning the queue. An open critical item older than the review SLA (default 7 days) degrades the owning system’s health — review debt is a health fact, not a backlog metric.

Continuous checks

Ask a standing question of your run ledger and pin it as a Continuous Assurance Check — “flag any run that invoked a payment-category tool without a preceding approval”, “flag runs whose cost exceeded $5 outside production”. Two declared tiers, never blended:

• Deterministic (tier A) — a bounded CEL expression over per-run ledger facts (run.guardrail_block_count > 0 && run.system_kind == "agent"), evaluated in the gateway core the moment a run finalizes. No LLM involved, fully reproducible.
• Semantic (tier B) — an LLM-judge rubric over run content, executed in governed batches through the gateway itself (the judge call is access-checked, ledgered, and billed like any workload). Sampling is declared in the spec and disclosed in results; per-check and per-tenant daily token budgets hard-stop runaway spend — and a check that stops running raises its own check_stalled inbox finding.

Natural language is authoring assistance only: the “ask in plain language” box proposes a spec, the operator reviews the actual expression or rubric, and the Rust evaluator compile-checks it before it can be saved. Every spec is versioned and hash-pinned — edits create a new version that stays disabled until re-approved, and enabling records the approver. Before enabling, backtest the spec against the last N days of recorded runs to see exactly what it would have flagged (backtests dispatch nothing and never raise findings).

Threshold breaches land in the Assurance Inbox as check_breach items — and alert to Slack/webhooks via Settings → Notifications.

Weekly summary

The Weekly summary panel is the in-console twin of the Slack digest: per-system health (worst first), runs and spend, findings raised and resolved, review-SLA status, and the week’s top check breaches. Stored digests are exactly what was pushed to digest_weekly channel subscriptions — one immutable row per tenant per week — and “Preview current week” computes live without sending, so the digest is testable without a webhook. Schedule defaults to Monday 08:00 (tenant-local via the assurance_digest tenant setting).

Analytics (the tabbed view)

The tabbed metrics view lives under Mission Control → Analytics (and one click away from any card via its Metrics action, pre-scoped to that group). Two former tabs are deliberately gone: Overview — the card dashboard is the overview now — and Alerts, whose feeds and actions (acknowledge, resolve, the one-click KB index rebuild, counter deep-links) all live in the dashboard’s bell drawer.

Tabs

Tab	What it shows
Traffic	Consumption drilldowns: volume time-series, per-group and per-user usage, MCP/A2A operations, quota utilization
Cost	FinOps view: spend and token breakdown by provider, model and team; budget burn-down vs configured limits with run-rate projection
LLM Economics	Token unit economics per model — the tokenomics projection beside the FinOps one
Governance	Guardrail blocks, policy denials, PII detections, shadow-policy hits, shadow-AI signals — your enforcement posture over time
Caching	Response/prompt cache hit rates, tokens and cost saved, value-per-token
Agents	Per-agent runtime activity and authorization decisions (allow / block / shadow) for agent workloads
Reliability	Latency percentiles (P50/P95/P99), error-rate time-series, hourly 7×24 traffic heatmap, per-server health

Timespan selector

Every tab shares one timespan control, persisted per browser:

Selection	period_hours
24 hours	24
7 days	168
30 days	720
90 days	2160
All Time	0 (no lower time bound)

The Governed / Observed / All plane toggle

Brutor tracks two planes of AI traffic:

• Governed — requests that flowed through the gateway inline: enforced, guardrailed, metered in real time.
• Observed — telemetry Brutor learned about out of band: imported vendor usage data (Traffic Data Import) and discovered assets. Visible for cost and inventory purposes, but not enforced.

The toggle filters every chart via the plane query parameter (governed | observed | omitted = all), which maps to the source column on metrics and usage rows (gateway vs import:*).

Observed ≠ governed

Observed traffic gives you cross-vendor cost visibility, but only governed traffic gets guardrails, quotas, and policies. If a workload matters, point it at the gateway.

Reliability views

The Reliability tab’s latency and error-rate series come with configurable intervals, and the per-server status strip shows health, latency, and request rate over the last five minutes for each registered MCP server and model backend.

Per-resource-group drilldowns

Mission Control aggregates the tenant; for a single team’s picture, open the resource group’s own Usage tab (backed by GET /v1/admin/resource-groups/{id}/usage) — same KPIs scoped to that group and its subtree, next to the group’s limits and usage alerts.

The API behind the dashboard

Everything on screen is a Control Plane endpoint you can script against (all under /v1/admin/metrics, bearer-authenticated, period_hours + plane params as above):

Endpoint	Backs
GET /dashboard	Overview KPI strip + health summary
GET /performance	Aggregate performance metrics
GET /real-time?last_minutes=5	Live throughput / success rate / error spikes
GET /cost/breakdown?top_n=10	Cost tab: spend by provider/model/team
GET /cost/budgets	Budget burn-down + run-rate projection
GET /governance/posture	Governance tab counters
GET /agents/activity	Agents tab
GET /timeseries/requests · /timeseries/latency · /timeseries/error-rate	Charts (with interval_minutes)
GET /heatmap/hourly?days=7	7×24 traffic heatmap
GET /usage?group_by=day	Billing/quota usage series
GET /servers/status	Per-server health strip
GET /alerts?severity=high	Metric-threshold alerts
GET /export?format=csv	Bulk metric export

Example — this week’s cost breakdown, governed traffic only:

curl "http://localhost:5050/v1/admin/metrics/cost/breakdown?period_hours=168&plane=governed&top_n=5" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Related pages

• Logs & audit trail — drill from a chart to the underlying requests
• Metrics & Grafana — the Prometheus side, for your own dashboards and alerting
• Usage alerts — what feeds the alerts drawer