Case Workflow

This document describes the case lifecycle, status transitions, and best practices for managing cases in nano.

Case Lifecycle

1. Case Creation

Cases are created through two mechanisms:

Automatic Creation (Recommended)

When a detection rule fires, nano automatically:

Extracts entities (users, hosts, IPs, etc.) from the matched events
Computes a grouping key based on active grouping rules
Either adds the alert to an existing case or creates a new one

Detection Fires → Extract Entities → Check Grouping Rules → Add to Case
                                                            ↳ or Create New Case

Manual Creation

Analysts can also create cases manually:

Click New Case button
Press C keyboard shortcut
Use the command palette (Cmd+K)

Once a case exists, analysts investigate using the case detail view. Every case with an assigned analyst automatically gets an investigation notebook — a unified timeline of all investigation activity including searches, manual notes, AI analysis, and case lifecycle events.

AI Summary: AI-generated overview of the case (includes case metadata — title, severity, status, disposition)
Entities Panel: Grouped list of extracted entities (users, hosts, IPs, domains, hashes)
Entity Graph: Interactive visualization of entity relationships

Main Content Area

Four tabs provide different views:

Tab	Purpose
Alerts	All alerts associated with the case
Investigation	Unified notebook timeline — searches, notes, case events, AI analysis
Entities	Detailed entity view with enrichment data
AI Triage	AI analysis from individual alert triage

The Investigation tab is the primary investigation surface. When a notebook exists, it shows notebook entries as the single source of truth — including case lifecycle events that are automatically mirrored into the notebook (see Case Event Mirroring below).

Quick Actions: Change status, assign, close
Related Cases: Cases sharing entities
Case Stats: Created time, alert count, etc.

3. Assignment

Cases can be assigned to analysts for investigation:

# API endpoint
POST /api/cases/:id/assign
{
  "assigned_to": "user-uuid"
}

Best Practices:

Assign cases based on analyst expertise and workload
Use the "My Cases" dashboard widget to track assigned cases
Set up auto-assignment rules for specific detection types

4. Status Transitions

Valid Transitions

Open ──────────────┬──────────────────────────────────────────────┐
                   │                                               │
                   ▼                                               │
In Progress ───────┼──────────────────────────────────────────────┤
                   │                                               │
                   ▼                                               │
Pending ───────────┼──────────────────────────────────────────────┤
                   │                                               │
                   ▼                                               │
Resolved ──────────┼──────────────────────────────────────────────┤
                   │                                               │
                   ▼                                               │
Closed ────────────┴──────────────(Reopen to Open)─────────────────

Changing Status

# API endpoint
POST /api/cases/:id/status
{
  "status": "resolved",
  "disposition": "true_positive"
}

Status Descriptions:

Status	When to Use
Open	Initial state, awaiting triage
In Progress	Analyst actively investigating
Pending	Waiting for external input (e.g., user response, vendor ticket)
Resolved	Investigation complete, needs review before closing
Closed	Case fully addressed, no further action needed

5. Resolution & Closure

When closing a case, assign a disposition:

Disposition	Description	Example
True Positive	Confirmed security incident	Actual malware execution detected
False Positive	Detection incorrectly fired	Legitimate admin tool flagged
Benign	Real activity, not malicious	Scheduled security scan
Inconclusive	Cannot determine with certainty	Logs insufficient for analysis

Case Views

Table View (Default)

The table view shows cases in a sortable, filterable list:

Column	Description
Case #	Human-readable identifier (CASE-1234)
Title	Case title (often derived from detection rule)
Severity	Critical, High, Medium, Low, Informational
Status	Current case status
Alerts	Number of alerts in the case
Entities	Number of unique entities
Assignee	Assigned analyst
Last Activity	Time since last update

Features:

Sort by any column
Filter by status, severity, assignee
Full-text search across case titles
Bulk selection for batch operations

Kanban View

Toggle to Kanban view (V key) for visual workflow management:

┌────────────┬────────────┬────────────┬────────────┬────────────┐
│    Open    │In Progress │  Pending   │  Resolved  │   Closed   │
├────────────┼────────────┼────────────┼────────────┼────────────┤
│ CASE-1234  │ CASE-1230  │ CASE-1225  │ CASE-1220  │ CASE-1215  │
│ Brute Forc │ PowerShell │ Awaiting   │ Phishing   │ False pos  │
│ [Critical] │ [High]     │ [Medium]   │ [High]     │ [Low]      │
│ 5 alerts   │ 3 alerts   │ 2 alerts   │ 4 alerts   │ 1 alert    │
├────────────┼────────────┼────────────┼────────────┼────────────┤
│ CASE-1233  │ CASE-1229  │            │ CASE-1219  │            │
│ Suspicious │ Lateral    │            │ Data exfil │            │
│ [High]     │ [Critical] │            │ [Critical] │            │
│ 3 alerts   │ 7 alerts   │            │ 12 alerts  │            │
└────────────┴────────────┴────────────┴────────────┴────────────┘

Features:

Drag-and-drop to change status
Visual density shows workload
Click card to open case detail

Investigation Notebooks (Unified Timeline)

Every case with an assigned analyst has an investigation notebook — a unified timeline that replaces the legacy case wall as the primary investigation surface. See the Investigation Notebooks guide for full details.

How It Works

When a case is assigned to an analyst (or created with an assignee), nano automatically creates a notebook linked to the case. This notebook captures:

Search activities — queries executed, results, and time ranges
Manual notes — analyst observations and hypotheses
Entity references — IOCs, hosts, users, and IPs tagged during investigation
AI analysis — AI-generated queries, pivot suggestions, and summaries
Case lifecycle events — status changes, assignments, and merges (see below)

Case Event Mirroring

Case lifecycle events are automatically mirrored into the notebook so that the Investigation tab shows a complete, unified timeline without needing to consult the legacy case wall separately.

Event	Mirrored As	Example
Status Change	`case_event` (status_change)	"Case status changed from Open to In Progress"
Assignment Change	`case_event` (assignment_change)	"Case assigned to user alice"
Case Merge	`case_event` (case_merged)	"Merged 2 case(s): 5 alerts, 3 entities moved"

These events appear in the notebook timeline with an amber Activity icon and are included in AI summary generation — so summaries reflect the full case lifecycle, not just search/note activity.

AI Summary Enrichment

When generating investigation summaries (via @summarize or on case close), the AI receives full case metadata:

Case title, number, and severity
Current status and disposition
Case description

This context produces more relevant, actionable summaries that reference the case outcome rather than just listing queries.

Legacy Case Wall

For backward compatibility, cases created before notebook integration still display the legacy case wall in the Investigation tab. Once a notebook is linked to a case, the wall entries are hidden in favor of the unified notebook timeline. The case wall data is preserved but no longer the primary view.

Best Practices

Use notebook @ commands for structured entries (entities, IOCs, timeline markers)
Add manual notes to document reasoning and hypotheses
Use @summarize periodically during long investigations
All case events appear automatically — no need to manually document status changes

nano automatically detects related cases based on shared entities:

Detection Logic

Cases sharing 2+ entities are considered related
Confidence score based on number of shared entities
Updates dynamically as new entities are added

Use Cases

Attack campaigns: Multiple cases targeting the same infrastructure
Compromised accounts: Cases involving the same user
Lateral movement: Cases linked by host-to-host connections

API Reference

List Cases

GET /api/cases?status=open&severity=high&assigned_to=<user-id>&limit=50

Get Case Details

GET /api/cases/:id

Create Case

POST /api/cases
{
  "title": "Suspicious PowerShell Activity",
  "description": "Multiple encoded PowerShell commands detected",
  "severity": "high"
}

Update Case

PUT /api/cases/:id
{
  "title": "Updated title",
  "description": "Updated description"
}

Add Alert to Case

POST /api/cases/:id/alerts
{
  "alert_id": "alert-uuid"
}

Get Case Wall

GET /api/cases/:id/wall

GET /api/cases/:id/related

Case Workflow

Case Workflow

Case Lifecycle

1. Case Creation

Automatic Creation (Recommended)

Manual Creation

2. Investigation

Left Sidebar

Main Content Area

Right Sidebar

3. Assignment

4. Status Transitions

Valid Transitions

Changing Status

5. Resolution & Closure

Case Views

Table View (Default)

Kanban View

Investigation Notebooks (Unified Timeline)

How It Works

Case Event Mirroring

AI Summary Enrichment

Legacy Case Wall

Best Practices

Detection Logic

Use Cases

API Reference

List Cases

Get Case Details

Create Case

Update Case

Add Alert to Case

Get Case Wall

On this page