# Rules, alerts and cases

The supported rule subset and how alerts link to cases.

Contract: console-v1. Stage: private evaluation. Source snapshot: 23fdccfaa88f69e858769f1dad70f82739e2740f.

## Signals are not a new API endpoint

Signals is the product-level view of observations and rule matches. The current API exposes retained events, rules, alerts and cases; there is no /signals endpoint. A matched event becomes a durable alert with a rule/version and cited evidence; its case holds investigation state. An alert is not automatically a confirmed incident. Triage records a human disposition and immutable application audit attribution.

## Strict Sigma-like subset

Allowed top-level keys: id, title, level, tags, logsource and detection. logsource contains product and service; product is aws or google_workspace and service must be an implemented source kind. detection contains selection and condition:selection. Selection allows integer class_uid/status_id and exact string activity_name/provider/source/actor. All fields are conjunctive. Unsupported keys, modifiers, arrays, Boolean expressions, count, correlation, joins and windows fail closed. A timeframe key does not establish backend support. This is deliberately not full Sigma.

## A stateless native CloudTrail rule

Validate this YAML with POST /api/v1/rules/validate as {yaml:...}. It is a rule example, not a claim that a live source is connected. YAML is at most 64 KiB; title at most 256 UTF-8 bytes; at most six selection fields and 32 tags. Store a validated rule with POST /api/v1/rules; persistence alone does not mean enabled.

```yaml
id: 8e919275-32da-4e8c-a9b0-9d02a759b30c
title: Review access key creation
level: medium
tags:
  - attack.t1098
logsource:
  product: aws
  service: aws_cloudtrail
detection:
  selection:
    activity_name: CreateAccessKey
  condition: selection
```

## Actual pipeline state matters

Enable/disable calls coordinate Arroyo pipeline state. An enabled claim requires observed job state Running; a background observer and GET /rules reconcile state. Durable creation intent and deterministic-name reconciliation prevent blind repeated creates after ambiguity. Disable requests checkpoint-stop and remain pending/unknown until terminal. Stateful/windowed semantics remain planned until replay, deduplication and late-data behavior are separately qualified.

## Durable delivery boundary

Long-lived Arroyo pipelines use Kafka-compatible input/output. Detection offsets commit only after the PostgreSQL alert/case/narrative/local-outbox/audit transaction commits or an existing result is reconciled. An HTTP webhook alone is not the durable alert boundary. Broker, checkpoint and metadata durability are deployment responsibilities; the single-node topology does not establish production recovery or HA.

## Review, triage, then manage the case

GET /alerts/{id} includes deterministic narrative and evidence. POST /alerts/{id}/triage records disposition and note: new, investigating, true_positive, false_positive, benign, insufficient_evidence or closed. Cases use open/investigating/closed and optimistic version checks. ATT&CK views reflect declared tags with evidence context—not confirmed coverage of every technique. External ticket delivery is planned; the current outbox is local-console delivery only. AI is off; planned System One advice cannot suppress delivery or authorize response.