psyc/docs/archive/cockpit.md

Blue48 Operations Cockpit — GUI / UI-UX Concept

Document type: Project record / technical concept
Scope: GUI, operator workflow, worker observability, evidence handling, routing review, and IntelMiner dataset operations
Status: Draft v1

---

1. Purpose

The Blue48 Operations Cockpit is the human-facing command center for the worker mesh.

The GUI must let operators see, review, approve, seal, route, audit, and publish cyber-intelligence cases without losing control of sensitive evidence or outbound submissions.

The core principle is:

The system may automate collection, enrichment, packaging, and routing, but humans must clearly see the chain of reasoning, evidence status, risk level, and outbound submissions before anything sensitive leaves the platform.

The GUI should not be a decorative dashboard first. It should be an operational cockpit.

---

2. Core Control Surfaces

The product should be designed around six main control surfaces:

Control Surface	Primary Question Answered
Cases	What is happening?
Evidence	What is protected?
Routing	Where will it go?
Workers	What produced this result?
Ledger	What can we prove happened?
Trainline	What can become safe training data?

These six areas should drive navigation, permissions, and MVP scope.

---

3. Main Navigation

Recommended sidebar navigation:

OPERATIONS
- Mission Control
- Case Queue
- Worker Mesh
- Routing Review
- Receipts

EVIDENCE
- Evidence Vault
- Sealed Packages
- Retention

INTELLIGENCE
- Reports
- MISP / STIX Events
- Public Advisories

TRAINING
- IntelMiner
- Training Candidates
- Dataset Builder

SYSTEM
- Integrations
- Policy Engine
- Ledger
- Admin

Minimal route structure:

/dashboard
/cases
/cases/:id
/cases/:id/evidence
/cases/:id/routing
/receipts
/workers
/trainline/candidates

---

4. Mission Control

Mission Control is the landing dashboard.

Its purpose is to show what is happening right now.

Key Widgets

Widget	Shows
Active Signals	New unreviewed leads from Scoutline
Critical Queue	Imminent harm / critical infrastructure cases
Pending Human Review	Cases waiting for analyst approval
Sealed Evidence Packages	Evidence encrypted and ready for authority handoff
Outbound Reports	Reports waiting to be sent
Receipts / Acknowledgements	CERT, MISP, abuse API, and provider responses
Worker Health	Workers running, degraded, failed, paused, or stopped
Rate Limits	API quota usage per destination
Legal / TLP Warnings	Items blocked by policy guard

Suggested Layout

┌──────────────────────────────────────────────────────────────┐
│ Blue48 Operations Cockpit                                    │
├──────────────┬──────────────┬──────────────┬────────────────┤
│ Critical     │ Pending      │ Sealed       │ Submitted      │
│ Cases        │ Review       │ Packages     │ Reports        │
├──────────────┴──────────────┴──────────────┴────────────────┤
│ Live Worker Mesh Timeline                                    │
├──────────────────────────────┬───────────────────────────────┤
│ Priority Case Queue          │ Destination / API Health       │
├──────────────────────────────┴───────────────────────────────┤
│ Recent Receipts and Outcomes                                  │
└──────────────────────────────────────────────────────────────┘

---

5. Case Queue

The Case Queue is the main daily-use screen.

Each row represents one signal or incident candidate.

Recommended Columns

Column	Meaning
Case ID	Unique internal case identifier
Class	A/B/C/D/E or Critical/High/Medium/Low
TLP	RED / AMBER / GREEN / CLEAR
Confidence	Low / Medium / High or Admiralty Code
Victim	Organization, domain, or unknown
Country	Used for CERT routing
Sector	Healthcare, finance, energy, government, etc.
Incident Type	Access sale, ransomware, phishing, credential leak, botnet, exploit, data leak
Actor	Known group / suspected actor / unknown
Current Worker	Worker currently responsible for the case
Next Action	Review, seal, route, submit, wait, archive
Deadline	SLA based on severity
Owner	Assigned analyst

Example row:

[CRITICAL] [TLP:AMBER] DE energy provider | access sale | high confidence | Sealer ready | Review required

Filters

The queue should support filters for:

• severity
• class
• TLP
• country
• sector
• actor
• source type
• confidence
• pending approval
• failed submission
• critical infrastructure only
• worker state

---

6. Case Detail View

The Case Detail View is where analysts work on a single case.

Recommended tabs:

Overview | Evidence | Timeline | Worker Output | Routing | Reports | Receipts | Audit

Overview Tab

The Overview tab should show:

• case summary
• severity
• class
• confidence
• affected entity
• actor
• jurisdiction
• recommended route
• current state
• required approval

Example:

Case: B48-2026-000184
Type: Initial Access Sale
Severity: Critical
TLP: AMBER
Confidence: High
Victim Country: Germany
Sector: Energy
Recommended Route:
1. CERT-Bund
2. Victim Security Team
3. Sector ISAC
4. MISP Trusted Community

---

7. Evidence View

The Evidence View is where the Sealer concept appears in the GUI.

Raw sensitive evidence should not casually render by default.

The UI should show evidence status instead of exposing raw contents.

Evidence Status Labels

Status	Meaning
Unsealed	Evidence exists internally but has not been authority-sealed
Sealed	Evidence has been encrypted for selected authorized recipients
Plaintext Destroyed	Local plaintext copy has been removed
Local Key Destroyed	Local unwrapped evidence key has been removed
Recipient Decryptable	Selected authority or victim can decrypt the package
Public-Safe Extract Available	Redacted/minimized metadata is available for public or semi-public destinations

Evidence Display Model

Evidence Package
├── Metadata preview: visible
├── Sensitive content: locked by default
├── Hashes: visible
├── Recipient keys: visible
├── Local decryption access: unavailable after key destruction
└── Chain of custody: visible

Evidence Actions

Recommended actions:

• Seal Evidence
• Add Recipient Key
• Verify Package Hash
• Destroy Local Plaintext
• Destroy Local Unwrapped Key
• Generate Public-Safe Extract
• Request Human Approval

The UI should make the trust state obvious:

Raw evidence: locked
Sealed package: ready
Local plaintext: destroyed
Local key: destroyed
Recipient: CERT-Bund can decrypt
Public extract: available

---

8. Worker Mesh View

The Worker Mesh View is the observability screen for the processing pipeline.

It should show the worker topology and the health of each worker.

Worker Lines

Scoutline
 SourcePlanner → Crawler → Fetcher → Parser → Deduper → SourceRanker

Proofline
 Signalizer → Correlator → IOCChecker → ClaimChecker → ConfidenceScorer

Mapline
 EntityResolver → GeoResolver → SectorMapper → ActorMapper → CVEResolver

Sealine
 EvidencePackager → Sealer → KeyBurner → RetentionGuard

Routeline
 RoutePlanner → PayloadBuilder → Courier → ReceiptCollector

Trainline
 IntelMiner → LicenseChecker → Chunker → Labeler → QualityGate → DatasetWriter

Worker Tile Fields

Each worker tile should show:

Field	Meaning
Status	Healthy, degraded, failed, paused, or stopped
Queue Depth	Number of waiting jobs
Last Run	Most recent execution timestamp
Error Count	Recent failures
Average Processing Time	Performance indicator
Model / API Used	Which model, API, or rule engine was used
Cost Estimate	Optional model/API cost estimate
Last Output Sample	Small safe preview of output
Controls	Retry, pause, resume, open logs

The goal is to prevent the system from becoming a black box.

---

9. Routing Review Screen

The Routing Review Screen is where humans approve outbound reports.

It should show recommended destinations, payload types, policy decisions, and blocks.

Example:

Recommended destinations:
✓ CERT-Bund — sealed evidence package
✓ Victim Security Team — sealed evidence package
✓ MISP Trusted Community — TLP:AMBER STIX indicators
✓ Cloudflare Abuse — minimized abuse report
✕ VirusTotal — blocked: contains sensitive sample / TLP too high

Destination Fields

Field	Purpose
Destination	CERT, MISP, provider, abuse API, registrar, law enforcement, victim
Payload Type	Sealed package, STIX bundle, minimized abuse report, advisory draft
Max TLP Allowed	Prevents over-sharing
Required Auth	API key, PGP, portal, structured email, OIDC
Rate-Limit Budget	Whether submission can happen now
Policy Status	Allowed, blocked, or needs approval
Legal Status	Safe, review required, or blocked
Expected Receipt	Case ID, acknowledgement, or status URL

Actions

Recommended actions:

• Approve Selected Routes
• Block Route
• Require Legal Review
• Send to Sealer
• Send to Redactor
• Submit Now

The interface should never provide one broad dangerous action such as Send Everything.

---

10. Report Builder

The Report Builder creates destination-specific outputs.

Report Templates

Template	Used For
Victim Notification	Direct affected organization
CERT Notification	National CERT / CSIRT
Law Enforcement Referral	Criminal activity
Provider Abuse Report	Hosting, CDN, registrar, cloud, email provider
MISP Event	CTI sharing
Public Advisory	Sanitized public report
Training Example	LoRA dataset candidate

Recommended Layout

Left pane: structured case data
Right pane: generated report preview

Warning Flags

The builder should warn when a draft:

• contains PII
• contains raw credentials
• contains TLP:RED material
• contains victim name
• contains exploit detail
• contains unsealed evidence
• exceeds destination TLP allowance
• targets a public or semi-public platform with sensitive content

---

11. IntelMiner / Trainline UI

The IntelMiner and Trainline UI should be separate from active operations.

This prevents analysts from confusing live cases with training candidates.

Dataset Sources Screen

Shows:

Field	Meaning
Source Name	Human-readable source name
URL / API	Collection endpoint
License Status	Approved, restricted, unknown, rejected
Allowed for Training	Yes / no / review required
Last Collected	Most recent collection timestamp
Document Count	Number of collected documents
Failure Rate	Recent collection reliability

Training Candidate Queue

Each candidate should show:

Field	Meaning
Task	IOC extraction, routing, classification, report writing, actor normalization
Source	Advisory, blog, report, synthetic, internal
License	Approved, restricted, unknown
Quality Score	Estimated usefulness
Safety Flag	Safe, needs review, reject
Reviewer Status	Pending, approved, rejected, edited

Example Review Screen

The reviewer should see:

Instruction
Input
Expected Output
Metadata
Source License
Safety Flags

Actions:

• Approve
• Reject
• Edit
• Send Back to Labeler
• Mark as Unsafe
• Export to JSONL

Dataset Builder

The Dataset Builder should show:

• examples by task
• token counts
• train/validation split
• duplicates
• class imbalance
• rejected examples
• export version

Example dataset versions:

dataset-router-v0.1
dataset-ioc-extractor-v0.3
dataset-report-writer-v0.2

---

12. Roles and Permissions

The GUI requires strict role-based access control.

Role	Can Do
Viewer	Read dashboards and public-safe summaries
Analyst	Review signals, enrich cases, draft reports
Sealer Officer	Seal evidence and manage recipient keys
Router Officer	Approve destinations and routing decisions
Legal Reviewer	Approve sensitive or cross-border submissions
Admin	Manage users, integrations, policies, and configuration
Dataset Curator	Approve training examples and exports
Auditor	Read ledger and export compliance logs

Two-Person Control

Critical actions should require two-person approval:

• send sealed evidence
• submit to law enforcement
• publish a public advisory
• destroy plaintext
• destroy local unwrapped evidence keys
• export a training dataset
• modify routing policy
• modify recipient keys

---

13. Case State Machine

Every case should follow a clear state machine.

Normal States

NEW_SIGNAL
→ PARSED
→ VERIFIED
→ MAPPED
→ CLASSIFIED
→ REVIEW_REQUIRED
→ EVIDENCE_PACKAGED
→ SEALED
→ ROUTE_PROPOSED
→ APPROVED_FOR_SUBMISSION
→ SUBMITTED
→ ACKNOWLEDGED
→ ACTIONED
→ ARCHIVED

Error / Block States

BLOCKED_BY_TLP
BLOCKED_BY_POLICY
NEEDS_LEGAL_REVIEW
DESTINATION_RATE_LIMITED
SUBMISSION_FAILED
INSUFFICIENT_CONFIDENCE
DUPLICATE_CASE

The state machine should be visible in the Case Detail View.

---

14. UI / UX Principles

Make Risk Visible

Every screen should answer:

• What is the severity?
• What is the confidence?
• Who is affected?
• What data is sensitive?
• Who can decrypt it?
• What will be sent?
• Where will it be sent?
• What policy allows or blocks this?

Make Automation Interruptible

Analysts must be able to:

• pause a worker
• block a route
• downgrade confidence
• require legal review
• mark as duplicate
• prevent publication
• reopen a case

Make Evidence Status Obvious

Use labels such as:

Raw evidence: locked
Sealed package: ready
Local plaintext: destroyed
Local key: destroyed
Recipient: CERT-Bund can decrypt
Public extract: available

Avoid Dangerous UX Patterns

Avoid:

• one-click “send all” actions
• hidden payloads
• unclear TLP labels
• buried warnings
• irreversible actions without confirmation
• publishing controls mixed with private reporting controls
• exposing raw evidence by default

---

15. Minimal MVP GUI

Do not build everything first.

The first useful MVP should include:

1. Mission Control
2. Case Queue
3. Case Detail
4. Evidence Sealing View
5. Routing Review
6. Courier Receipts
7. Worker Health
8. IntelMiner Dataset Queue

MVP Routes

/dashboard
/cases
/cases/:id
/cases/:id/evidence
/cases/:id/routing
/receipts
/workers
/trainline/candidates

This MVP is enough to operate safely while keeping the scope manageable.

---

16. Recommended Technical Stack

Layer	Recommendation
Frontend	React / Next.js
UI Components	shadcn/ui + Tailwind
Charts	Recharts
Workflow Graph	React Flow
Tables	TanStack Table
Backend API	FastAPI
Worker Orchestration	Celery, Temporal, or Prefect
Database	PostgreSQL
Search	OpenSearch or Meilisearch
Graph Intelligence	OpenCTI / Neo4j optional
Object Storage	S3-compatible encrypted storage
Audit Log	Append-only PostgreSQL table or immutability layer
Auth	OIDC / Keycloak
Realtime Updates	WebSockets or Server-Sent Events

React Flow is especially useful for the Worker Mesh screen.

---

17. Visual Identity

The design should feel:

• calm
• operational
• serious
• high-trust
• defensive
• readable under pressure

Avoid:

• cyberpunk styling
• hacker neon
• gamification
• aggressive animation
• cluttered dashboards

Recommended style:

Dark mode by default
High-contrast severity labels
Muted blue/gray base
Red only for critical
Amber for warnings
Green for completed/safe
Clear TLP badges
Large readable tables
Minimal animations

Recommended UI language:

Evidence protected.
Route blocked by policy.
Human approval required.
Recipient can decrypt.
Local key destroyed.
Submission acknowledged.

---

18. Final Operating Model

The GUI should support this operational chain:

Detect
→ Validate
→ Classify
→ Seal Evidence
→ Review Routes
→ Submit Reports
→ Track Receipts
→ Archive Safely
→ Publish Sanitized Intelligence
→ Build Reviewed Training Data

The core cockpit should keep humans in control of five things:

1. Cases — what is happening?
2. Evidence — what is protected?
3. Routing — where will it go?
4. Workers — what produced this result?
5. Ledger — what can we prove happened?

The training workspace adds the sixth:

6. Trainline — what can become safe training data?

---

19. Summary

The Blue48 GUI should be an operations cockpit, not a passive dashboard.

It must provide:

• live case visibility
• worker observability
• authority-sealed evidence control
• human routing approval
• TLP and policy enforcement
• receipt and outcome tracking
• immutable audit visibility
• safe IntelMiner training-data review

The first MVP should focus on daily operational safety and decision control before advanced analytics or public-reporting features are added.