Admin Operations Center

Overview

The Admin Operations Center is the master control plane for every autonomous system running inside ThreatOps. As the platform evolves toward a self-operating SOC, individual services run as long-lived background loops — integrity scans, ML retraining, autonomous SOC cycles, self-healing checks, advisory refreshes, and the frontend factory engine. Without a unified control surface, operators have no visibility into whether these systems are healthy, and no mechanism to intervene when something stalls.

This module aggregates the real-time status of all seven autonomous engines into a single dashboard, surfaces live process metrics (CPU, memory, WebSocket connections, database pool), and provides per-system action controls — trigger, stop, and restart — as well as platform-wide kill-switch and restart-all operations. A time-ordered activity feed consolidates events from every engine into one scrollable log. A sub-page at /admin-ops/factory extends this with a full lifecycle manager for the Frontend Factory Engine, covering requirement submission, TSX code generation, preview, and deployment.

What Was Proposed

• A centralized operator console for monitoring all autonomous and scheduled platform services in one view
• Per-system health cards showing running state, last execution timestamp, error count, and success rate
• Manual trigger capability for every system without requiring direct shell access to any pod
• An emergency stop mechanism able to halt any individual system or all systems simultaneously
• Restart controls to bring stopped systems back online without a full platform redeploy
• A unified, time-sorted activity log aggregating events from integrity scans, deploys, SOC decisions, healing actions, and ML retrains
• System-wide runtime metrics: uptime, memory, CPU, active WebSocket connections, DB pool stats
• Frontend Factory sub-page for managing dynamically generated Next.js page requirements through a submit-generate-preview-deploy workflow

What's Built

Architecture

Admin Router

File: platform/api/app/routers/admin_ops.py — Prefix: /api/v1/admin

The router uses lazy import functions for all seven engine singletons to avoid circular-import issues at startup. Each engine is accessed through a private getter (e.g., _get_integrity_monitor()). The SYSTEM_REGISTRY dict maps slug keys to their display label, getter function reference, and schedule description string. A private _background_tasks dict tracks the asyncio.Task handle for each engine, enabling the router to cancel and recreate tasks during stop/restart operations without requiring the services module to expose task management.

The core helper _system_status(name: str) branches on the system name, introspects engine-specific state attributes, and returns a normalized dict containing running, last_run, error_count, success_rate, and any engine-specific extras (e.g., pending_deploy, buffer_size, total_deploys). Success rate is computed as (total - errors) / total * 100.

Frontend Factory Router

File: platform/api/app/routers/frontend_factory.py — Prefix: /api/v1/factory

Manages the full lifecycle of page requirements from submission through code generation, preview, and file deployment. The FrontendFactoryEngine singleton (app/services/frontend_factory.py) compiles Next.js TSX from template generators, validates requirements, writes output files to the frontend source tree, and signals the auto-deploy pipeline. A COMPONENT_REGISTRY dict (app/services/component_registry.py) catalogues available UI building blocks accessible through the component library endpoint.

Autonomous Systems Registry

Seven systems are registered in SYSTEM_REGISTRY at module load time. Each entry carries a slug key (used verbatim in API paths), a human-readable label, a lazy getter returning the engine singleton, and a schedule description. The _system_status helper branches on the slug to extract engine-specific fields.

API Endpoints

Admin Router — /api/v1/admin

Frontend Factory Router — /api/v1/factory

Frontend Routes

Both pages are Next.js App Router client components ("use client"). The main dashboard calls GET /api/v1/admin/dashboard and GET /api/v1/admin/metrics in parallel, followed by a separate call to GET /api/v1/admin/activity-log that fails gracefully if unavailable. API calls are made via the shared api client from @/lib/api-client.

Frontend Factory Sub-page

The factory sub-page at /admin-ops/factory provides a full lifecycle UI for the Frontend Factory Engine. It can be navigated to directly or linked from the frontend-factory system card on the main dashboard.

Data Models

The admin ops router does not use SQLAlchemy database models. It introspects in-memory state of engine singletons at request time. The structures below document the API response shapes.

Dashboard Response

{
  "timestamp": "2026-03-01T12:00:00",
  "emergency_mode": false,                 // true if any system.running == false
  "systems": {
    "integrity-scan": {
      "name": "integrity-scan",
      "label": "Platform Integrity Monitor",
      "running": true,
      "schedule": "Every 30 min",
      "last_run": "2026-03-01T11:30:00",
      "error_count": 0,
      "success_rate": 100.0,
      "total_scans": 12,
      "pages_generated": 5,
      "pending_deploy": false
    },
    "soc-cycle": {
      "name": "soc-cycle",
      "label": "Autonomous SOC Engine",
      "running": true,
      "schedule": "4 concurrent loops (30min / 10s / 1hr / 5min)",
      "last_run": "2026-03-01T11:59:50",
      "error_count": 0,                    // escalated_to_human count
      "success_rate": 100.0,
      "alerts_processed": 847,
      "auto_resolved": 720
    }
    // ... 5 more systems
  }
}

Metrics Response

{
  "timestamp": "2026-03-01T12:00:00",
  "uptime_seconds": 3621.4,
  "memory_mb": 184.2,
  "memory_percent": 2.3,
  "cpu_percent": 1.8,
  "threads": 14,
  "active_ws_connections": 3,
  "db_pool": {
    "size": 5,
    "checked_in": 4,
    "checked_out": 1,
    "overflow": 0
  },
  "autonomous_systems_total": 7,
  "autonomous_systems_running": 7,
  "note": "psutil not installed — install for detailed metrics"  // when psutil absent
}

Activity Log Event

{
  "timestamp": "2026-03-01T11:45:00",
  "system": "integrity-scan",
  "action": "integrity_scan",
  "detail": "Scanned 47 routes, 32 pages, generated 2 pages",
  "result": "success"                      // success | failed | auto_resolved | rule_generated
}

Factory RequirementSubmission (POST body)

{
  "title": "Vulnerability Risk Matrix",
  "description": "Table of open CVEs grouped by CVSS score and affected asset",
  "page_type": "data_table",
  "route": "/vulnerabilities/risk",
  "api_endpoints": [
    { "method": "GET", "path": "/api/v1/vulnerabilities", "description": "List CVEs" }
  ],
  "data_fields": [
    { "name": "cve_id", "label": "CVE ID", "type": "string", "required": true },
    { "name": "cvss_score", "label": "CVSS", "type": "number" },
    { "name": "status", "label": "Status", "type": "enum",
      "values": ["open", "mitigated", "accepted"] }
  ],
  "features": ["search", "filter", "export", "pagination"],
  "refresh_interval": 30,
  "sidebar_section": "main",
  "sidebar_icon": "ShieldAlert",
  "priority": "high",
  "requested_by": "admin"
}

Prerequisites

• Platform Integrity Monitor — app/services/platform_integrity.py — singleton integrity_monitor
• Auto-Deploy Pipeline — app/services/auto_deploy.py — singleton auto_deploy
• Autonomous SOC Engine — app/services/autonomous_soc.py — singleton autonomous_soc
• Self-Healing Engine — app/services/self_healing.py — singleton self_healing_engine
• ML Training Pipeline — app/ml/training_pipeline.py — singleton ml_pipeline
• Threat Advisory Engine — app/services/threat_advisory_service.py — singleton advisory_engine
• Frontend Factory Engine — app/services/frontend_factory.py — singleton frontend_factory; requires TEMPLATE_SCHEMAS dict and GENERATORS map
• Component Registry — app/services/component_registry.py — dict COMPONENT_REGISTRY used by the component library endpoint
• WebSocket Manager — app/routers/websocket.py — manager.active_connections for WS connection count in metrics
• Database Engine — app/core/database.py — async_engine.pool for DB pool stats
• psutil (optional) — Python package; if absent, memory and CPU fields return null and a note is included in the metrics response
• FastAPI & asyncio — All trigger, stop, and restart handlers are async def; restart creates asyncio.create_task handles

UI Layout