The operator console

In L14 we named the admin-panel as the real human-facing read surface but didn't open it. It's the operator console — a multi-feature internal web UI over everything you've built: explore the graph, investigate an address, manage focus tokens and IAM, edit rules. Because it gives privileged humans direct access to a risk system, its defining features aren't the views — they're the access control and the audit trail wrapped around them.

1 · Every request runs an auth gauntlet (RBAC)

This is the heart of it. The panel uses auth0 for identity (who are you?) and a permission guard for authorization (are you allowed this?). Each route declares the permission it needs (cmd/admin-panel/auth.go):

// cmd/admin-panel/auth.go — permissions are fine-grained strings
permGraphRead        = "risk_graph:graph:read"
permFocusTokensRead  = "risk_graph:focus_tokens:read"
permFocusTokensWrite = "risk_graph:focus_tokens:write"   // write ≠ read — separate perm

// routes → required permission (by prefix + HTTP method)
{prefix: "/api/admin/focus-tokens", methodPerm: {"GET": permFocusTokensRead, "POST": permFocusTokensWrite}}
{prefix: "/api/token/",           methodPerm: {"": permGraphRead}}

A middleware enforces it on every request:

// permGate wraps every handler; requiredPermission(method, path) → the needed perm
func permGate(g *authz.Guard) func(http.Handler) http.Handler { /* 403 if missing */ }

2 · Every privileged action is audited

Identity + permission isn't enough for a tool that can change a live risk system — you also need to know who did what. The panel writes an audit log of operator actions to a per-operator Redis stream (cmd/admin-panel/auth0/xpapi_audit.go):

// xpapi:audit:{operatorEmail} — a Redis stream, one per operator
func (a *RedisAuditor) Record(ctx, operatorEmail string, evt AuditEvent)   // append on each action
func (a *RedisAuditor) Recent(ctx, operatorEmail string, limit int) ([]AuditEvent, error) // read back for display

Privileged routes (the audited "xpapi" — extended API — surface, xpapi_routes.go) record an AuditEvent per action, and Recent surfaces a history in the UI. Auth says you can; audit records that you did.

3 · The views: server-rendered, Cypher-backed reads

Behind the auth gauntlet, a feature is a controller that runs an anchored Cypher read and renders HTML. It obeys the L2 rules you know: graph_id-scoped, anchored at a known id, bounded — never a full scan (this is a 1.8M-node graph, L14). The graph-viz feature is the most graph-shaped: it pulls a node's neighbourhood as edges to draw, deliberately excluding super-node and analytical edges so the picture stays legible.

4 · Where it sits in the whole system

The admin-panel is a pure consumer: it reads the graph (and its pre-computed risk fields, L13) and lets operators perform bounded privileged writes — which, like all bulk writes, still flow through the graph-writer (L9); the panel doesn't bypass the single-writer discipline. It adds no new data-plane mechanism — it's the human control plane over the machine you've spent sixteen lessons understanding.

Check yourself

What you can now do

• Describe the admin-panel as the operator console — the human control plane, not a data-plane binary.
• Explain the auth gauntlet: bypassAuth → auth0 identity → permGate authorization (per-route permission, read/write split).
• Explain audit logging of privileged actions and why a tool with this power needs it.
• Recognise its views as anchored, Cypher-backed, L2-compliant reads, with writes still going through the graph-writer.
• See that it's built entirely from the system's existing toolbox — the mark that your model is complete.