# 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:

```text
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:

```text
/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

```text
┌──────────────────────────────────────────────────────────────┐
│ 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:

```text
[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:

```text
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:

```text
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

```text
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:

```text
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

```text
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:

```text
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

```text
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:

```text
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:

```text
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

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

### Error / Block States

```text
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:

```text
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

```text
/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:

```text
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:

```text
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:

```text
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:

```text
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:

```text
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.