triagedy

# triagedy

> Because alert triage shouldn't be a tragedy.






**Alert triage as a UNIX filter: JSONL security alerts in, typed decisions out.**

Powered by [TypeSafe Jev](https://typesafe.ai) (System One) by default — typed
decisions with calibrated probabilities in ~200 ms, cheap enough to run a screen
in front of *every* alert so your expensive triage tools (and your humans) only
see what survives it.

One binary. No daemon, no database, no framework. Pipe it, host it, cron it.

```
cat alerts.jsonl | triagedy run | jq '.action'
```

---

## Why

Analysts drown in alerts, and the real problem is rarely the malicious ones — it's
the volume of everything else. triagedy asks a decision model five specific
questions about each alert, gets back typed answers with probabilities, and then
routes the outcome with **ordinary code you control**. The model judges; your
code decides.

No prompt-parsing. No JSON-in-a-sentence. No agent framework. Just a filter.

**Not ready for Jev, or need to keep data on-prem?** Point `--backend openai` at
any OpenAI-compatible server — Ollama, vLLM, LM Studio, llama.cpp, OpenRouter —
and the pipeline is identical. Confidence values there are the model's
self-report, so treat them as uncalibrated.

## What it does

`triagedy` operationalizes a validated SOC Tier-1 security-operations workflow
grounded in **NIST SP 800-61 Rev. 2** (*Computer Security Incident Handling Guide*,
§3.2 Detection and Analysis, §3.2.6 Incident Prioritization) and the **MITRE ATT&CK
Enterprise Matrix** (see [docs/SECURITY_WORKFLOW.md](docs/SECURITY_WORKFLOW.md) for
the formal specification).

For each alert it asks five orthogonal questions and returns a typed, validated decision:

| Question | Standard Mapping | Type | Answer |
|---|---|---|---|
| What is the correct