Prove it works — with AI-generated data.

ingest  →  normalize (attrs.ecs_*)  →  detect  →  incident  →  alert
                                                      ↓
                                        (optional) AI analyst → verdict → webhook / case

AI generates the test data — you paste a prompt into any chat model and it writes the synthetic events. The platform's AI analyst investigates the resulting incidents (optional track). You verify every outcome in the dashboard and API against the grading rubric at the end. Base URLs (hosted): the API is https://api.24observe.com, the dashboard is https://login.24observe.com. Self-hosting? Swap your own host — everything else is identical. And note: these synthetic events are real ingest — they open real incidents and count against usage. Section 9 cleans up; prefer a test org if you have one.

Give a model the field contract and let it produce realistic batches. Reuse these prompts everywhere.

Benign app logs (batch): "Produce a JSON array of 40 log events for a fictional e-commerce backend. Each has ts (ISO-8601, last 10 min), level (mostly info, some warn/error), service (checkout/payments/catalog/auth/search), message, and attrs (request_id, user_id, latency_ms, status_code). Make ~5 the SAME recurring error so pattern-grouping has something to collapse. Output only the JSON array."

An attack scenario: "Produce a JSON array of native {VENDOR} events representing {SCENARIO}. Use real field names, realistic timestamps in the last 5 min, plausible usernames and IPs. Output only the JSON array." (e.g. VENDOR = AWS CloudTrail, SCENARIO = disabling logging after creating an IAM key.)

A tiny sender you can reuse

Define this once and every recipe is a one-liner:

send() {  # usage: send '<json>'
  curl -s -X POST "$API/api/v1/logs/ingest" \
    -H "Authorization: Bearer $OBS" -H "Content-Type: application/json" -d "$1"
}

Don't want to memorize field names? Paste the ECS field list into the model and ask it to write "a single JSON log object representing {SCENARIO}, filling those fields with realistic values." Swap {SCENARIO} for any recipe below. Always eyeball what it generates — you are the human verifier.

Enable the packs (needs siem:write), then run recipes that each open a specific, MITRE-tagged incident:

curl -s -X POST "$API/api/v1/log-alerts/seed" \
  -H "Authorization: Bearer $OBS" -H "Content-Type: application/json" \
  -d '{"packs":["access","cloud","identity","edr","threatintel"],"enable":true}'

See every rule's exact match condition any time with GET /api/v1/log-alerts/catalog. All recipes below are threshold rules; single-event ones (threshold 1) open an incident from one event, burst rules need the count.

AWS CloudTrail logging disabled — critical, T1562.008

Matches attrs.ecs_event_action:"StopLogging" OR "DeleteTrail" OR "UpdateTrail":

send '{
  "message":"StopLogging","level":"warn","service":"aws-cloudtrail",
  "attrs":{"ecs_event_provider":"aws","ecs_event_action":"StopLogging",
           "ecs_user_name":"mallory","ecs_source_ip":"203.0.113.66"}
}'

Within ~60s a critical incident opens. Grab its id — you'll reuse it for deliveries, blast radius, and the verdict:

[{
  "id": 5210,
  "title": "AWS — CloudTrail logging disabled [T1562.008]",
  "severity": "critical",
  "status": "investigating",
  "startedAt": "2026-07-06T12:00:31.402Z",
  "resolvedAt": null
}]

More cloud & identity recipes

Same shape, different attrs. Each opens the named incident:

• AWS — root account used (high, T1078.004): ecs_event_provider:aws + ecs_user_name:root
• AWS — IAM access key or user created (high, T1098.001): ecs_event_action:CreateAccessKey (or CreateUser / CreateLoginProfile)
• Okta — admin privilege granted (high, T1098): ecs_event_action:user.account.privilege.grant
• Azure — privileged role assignment (T1098): ecs_event_provider:azure + ecs_event_action:"Microsoft.Authorization/roleAssignments/write"
• GCP — IAM policy modified (T1098): ecs_event_provider:gcp + ecs_event_action:"*SetIamPolicy"
• Okta — MFA push fatigue (T1621, 3 in 600s), Okta — API token created (T1098), AWS — console sign-in failures (T1110, 10 in 600s)
• Secret leaked into logs (T1552): a message containing AKIA…, sk_live_…, or -----BEGIN RSA PRIVATE KEY-----

Okta MFA factor deactivated — high, T1556

send '{"message":"MFA factor removed","service":"okta",
  "attrs":{"ecs_event_provider":"okta","ecs_event_action":"user.mfa.factor.deactivate",
           "ecs_user_name":"[email protected]","ecs_source_ip":"203.0.113.20"}}'

Okta failed sign-in burst — high, T1110 (multi-event)

Threshold 15 in 300s — send a burst; you still get exactly one incident (the latch collapses the storm):

for i in $(seq 1 18); do
  send '{"message":"Okta authentication failed","level":"warn","service":"okta",
    "attrs":{"ecs_event_provider":"okta","ecs_event_category":"authentication",
             "ecs_event_outcome":"failure","ecs_user_name":"[email protected]",
             "ecs_source_ip":"203.0.113.99"}}' >/dev/null
done

The realistic path — a vendor preset

Prove the normalization layer: send native CloudTrail JSON through a preset. Create the source once, then send:

curl -s -X POST "$API/api/v1/ingest/sources" \
  -H "Authorization: Bearer $OBS" -H "Content-Type: application/json" \
  -d '{"sourceKey":"test-cloudtrail","name":"Test CloudTrail","preset":"aws-cloudtrail"}'

curl -s -X POST "$API/api/v1/ingest/test-cloudtrail" \
  -H "Authorization: Bearer $OBS" -H "Content-Type: application/json" \
  -d '{"eventTime":"2026-07-06T12:00:00Z","eventName":"StopLogging",
       "eventSource":"cloudtrail.amazonaws.com","sourceIPAddress":"203.0.113.66",
       "userIdentity":{"userName":"mallory","type":"IAMUser"},
       "awsRegion":"us-east-1","recipientAccountId":"111122223333"}'

The preset maps eventName → attrs.ecs_event_action, so the same critical CloudTrail incident opens. Any of the 30+ connectors work this way.

Multi-event correlation — brute-force then success

Single rules catch a spike; correlation catches a story. Seed the correlation rules, then reproduce the Account takeover — brute force then success sequence (same attrs.user_id, failures then a success):

curl -s -X POST "$API/api/v1/correlation-rules/seed" \
  -H "Authorization: Bearer $OBS" -H "Content-Type: application/json" -d '{"enable":true}'

for i in $(seq 1 6); do
  send '{"message":"authentication failed","service":"auth","attrs":{"user_id":"alice"}}' >/dev/null
done
send '{"message":"login success","service":"auth","attrs":{"user_id":"alice"}}'

A high correlation incident opens (T1110). Change the success event's user_id to bob and nothing fires — the join key didn't match. That's correlation working.

A full attack chain in one scenario

The best demo: ask AI for an 8-event kill-chain (Okta brute-force → success → MFA deactivate → API token → AWS IAM key → CloudTrail stop), send it as one array, and get a cluster of correlated, MITRE-tagged incidents sharing one identity in /siem-context.

Check whether it's enabled with GET /api/v1/analyst/config (owner/admin). If so, open a true-positive (the CloudTrail recipe is ideal), wait a few minutes, then read the verdict:

curl -s "$API/api/v1/incidents/<id>/analysis" -H "Authorization: Bearer $OBS"

The evidence array is the point — the analyst shows its work before deciding. You read the summary, glance at the evidence, and sign off. That is the human half.

{
  "disposition": "true_positive",
  "confidence": 0.91,
  "severity": "critical",
  "summary": "CloudTrail was stopped by user 'mallory' from 203.0.113.66, an IP with no prior activity. No change ticket. Consistent with defense evasion.",
  "evidence": [
    { "type": "log_search", "key": "attrs.ecs_user_name:mallory", "reasoning": "first-seen actor" },
    { "type": "entity", "key": "ip:203.0.113.66", "reasoning": "no baseline; not allow-listed" }
  ],
  "recommendedActions": ["Re-enable CloudTrail", "Disable mallory's access keys"],
  "model": "openai/gpt-5.4-nano"
}

Subscribe a webhook receiver (POST /api/v1/webhook-subscriptions with event types incident.opened, analyst.verdict, analyst.escalation) and, on a confident true-positive, you'll receive the escalation and see a SOC case appear at /cases linking the incident. Full loop: detection → incident → investigation → escalation → case.

Synthetic tests create real incidents and a real source. When you're done: resolve the synthetic incidents from /incidents; delete the test source from the Integrations page; and revoke the scratch token:

curl -s "$API/api/v1/me/tokens" -H "Authorization: Bearer $OBS"          # find the id
curl -s -X DELETE "$API/api/v1/me/tokens/<id>" -H "Authorization: Bearer $OBS"