Case Management

Cases in AuroraSOC represent structured investigations that group related alerts, observables, evidence, analyst notes, and execution tasks. They provide the audit trail required for compliance and post-incident review.

Case Lifecycle

AuroraSOC now supports both the expanded workflow states and older compatibility states. investigating and escalated remain accepted for legacy data and earlier playbook flows, while the primary forward lifecycle is open -> in_progress -> pending_approval -> contained -> eradicated -> recovered -> resolved -> closed.

Human approvals are tracked as a parallel control plane when a case contains actions that require authorization. They do not replace the case lifecycle itself.

Status Semantics

Status	Meaning
open	Newly created case that has not started active handling yet
in_progress	Active analyst or agent investigation is underway
pending_approval	Progress is blocked on a required human decision
contained	Immediate threat spread has been limited or isolated
eradicated	Malicious artifacts or footholds have been removed
recovered	Service or device state has been restored and is being monitored
investigating	Legacy compatibility state used by older workflows
escalated	Legacy compatibility state for older escalation paths
resolved	Technical remediation is complete
closed	Post-incident closure and review are complete

Creating a Case

Cases can be created in three supported ways:

1. From a single alert — Open an alert and use Create Linked Case
2. From the SIEM workspace — Promote a searched event directly into a linked case, optionally under the control of an active detection rule
3. AI-initiated — The Orchestrator agent automatically creates cases for critical findings
4. Via API — POST /api/v1/cases, POST /api/v1/alerts/{alert_id}/promote, or POST /api/v1/siem/logs/{log_id}/promote

Case Fields

Field	Description	Required
Title	Descriptive case name	Yes
Severity	Critical / High / Medium / Low	Yes
Description	Detailed incident description	No
Assignee	Human owner or current primary analyst	No
Linked Alerts	Associated alert IDs promoted into the case	No
Confidence	Investigation confidence score (0.0–1.0)	Auto
Timeline	Chronological case activity feed	Auto
Observables	Domains, IPs, URLs, hashes, users, or hosts attached to the case	Added during investigation
Evidence	Structured artifacts with custody tracking	Added during investigation
Comments	Analyst notes and collaboration thread	Added during investigation
Tasks	Investigation work items with status and assignee	Added during investigation

Runtime Mode Truth

The Cases workspace now reads runtime truth from GET /api/v1/system/mode before operators start or continue workflow actions.

• In dummy, the queue is explicitly treated as showcase workflow data and case creation, edits, workflow updates, and agent dispatch stay preview-only.
• In dry_run, the page reads live case data when the database is available, and manual create, edit, delete, workflow, and dispatch actions still return preview results instead of committing those operator-triggered changes.
• In dry_run, AuroraSOC internal pipelines may still open cases from live detections and append autonomous analyst-style notes or simulated follow-up receipts to those cases.
• In real, those same case actions persist to the live platform.

This keeps the case queue truthful before an analyst updates status, adds evidence, or dispatches follow-up work.

Degraded Live-Read Behavior

When AuroraSOC is running in dry_run or real without a database connection, the Cases page now fails clearly as a recovery surface instead of presenting an ordinary empty queue.

In this degraded mode:

• KPI cards switch to unavailable placeholders instead of showing zero cases
• Search and queue filters become read-only until live reads return
• The New Case form is disabled and any open create form is closed
• The queue body switches to a Live case queue unavailable recovery card
• The page exposes a direct Review runtime settings shortcut back to Settings
• Deep-linked selected cases are cleared so stale investigation detail does not remain pinned while reads are offline

Restore the database connection for live case reads, or switch to dummy mode if you only need showcase workflow review while the database is offline.

Case Detail View

Summary Panel

• Case metadata, severity badge, assigned analyst
• Confidence score with explanation
• Current status with time-in-status

Workflow Summary Panel

The expanded case workspace now includes first-class counts and lists for:

• observables
• evidence artifacts
• analyst notes
• execution tasks

When AuroraSOC creates a case from network telemetry, the notes list can include machine-authored entries from Autonomous Network Defense that summarize the detection and the planned or simulated follow-up dispatch.

When the live follow-up result arrives, AuroraSOC now also writes the returned investigation summary back into the case timeline and notes, moves open cases into in_progress, and surfaces linked network-attack receipts directly in the case overview so analysts can see queue state and structured findings without pivoting first.

The linked receipt cards refresh live from the backend receipt stream, so the case workspace updates as soon as the result consumer persists the new timeline entry and note.

Selected-Case Routing

The Cases workspace now supports deep-link routing for analyst handoffs.

• Opening /cases?selectedCase=<id> automatically expands the matching case.
• If the requested case is not already in the current list payload, AuroraSOC fetches the detail record and inserts it into the view.
• Closing or collapsing the selected case clears the route parameter so the workspace URL returns to its unpinned state.

Case Controls

The expanded case workspace now supports direct lifecycle operations:

• edit title, description, severity, assignee, and case status
• enable or disable the requires_human_approval flag for analyst review gates
• delete the case and automatically detach linked alerts
• use the full backend-supported lifecycle states, including in_progress, contained, eradicated, and recovered

Timeline Panel

The timeline shows every action taken on the case chronologically, including:

• Alert associations
• Agent analysis steps
• Observable registration
• Evidence registration and custody handoffs
• Task creation and lifecycle changes
• Human approval requests and decisions
• Status changes
• Analyst comments

Evidence Panel

All artifacts collected during investigation:

• Raw log entries from SIEM
• Network flow data
• Endpoint scan results
• Forensic evidence collected
• Screenshots and file attachments
• Chain-of-custody records for each evidence item

Observable Panel

Observables are now tracked as first-class case entities instead of only appearing inside free-form text or JSON blobs.

Each observable records:

• type and value
• source and sighting count
• TLP and PAP markings
• enrichment context and analyst tags

Task Panel

Tasks give analysts a lightweight operational workflow inside the case itself.

Each task records:

• title and description
• status (todo, in_progress, blocked, done)
• priority and assignee
• due date and completion timestamp

Analysts can now transition task state directly from the case workspace instead of only marking work complete.

Evidence Custody Actions

Every evidence item includes an inline custody history and a quick handoff form.

Use it to record actions such as:

• transferred
• duplicated
• reviewed
• archived

Recommendations Panel

AI-generated recommendations based on investigation:

• Immediate response actions
• Long-term remediation steps
• Policy changes suggested
• Similar past cases reference (via episodic memory)

Human Approval Workflow

For high-impact actions, AuroraSOC creates approval records alongside the case:

1. Agent determines an action requires human authorization (e.g., isolate host, disable user)
2. Approval request created with an expiration window configured by the backend approval policy
3. Notification sent via WebSocket to authorized analysts
4. Analyst reviews context and approves/rejects
5. Case continues or alternative path taken

Approval Timeout

Approval requests expire according to the backend approval policy. Expired approvals are marked as expired, and the case should be moved back into an active investigation state for analyst re-evaluation.

Case Metrics at a Glance

The current Cases workspace header emphasizes operational workflow visibility:

• Total Cases — All cases currently loaded into the workspace
• Open — Cases in active, non-terminal workflow states
• Critical — Cases currently marked critical severity
• Resolved — Cases in terminal workflow states (resolved or closed)

API Surfaces for Case Workflow

AuroraSOC now exposes first-class case workflow routes for analyst tooling and frontend integration:

• GET /api/v1/cases/{case_id} — full case detail including timeline, observables, evidence, comments, and tasks
• PATCH /api/v1/cases/{case_id} — update case metadata, approval requirement, assignee, or lifecycle status
• DELETE /api/v1/cases/{case_id} — delete a case and detach linked alerts
• GET|POST /api/v1/cases/{case_id}/observables
• GET|POST /api/v1/cases/{case_id}/evidence
• POST /api/v1/cases/{case_id}/evidence/{evidence_id}/custody
• GET|POST /api/v1/cases/{case_id}/comments
• GET|POST /api/v1/cases/{case_id}/tasks
• PATCH /api/v1/cases/{case_id}/tasks/{task_id}