Is the ~200 ms per alert figure measured, or aspirational?

It is presented as the reason the tool is cheap enough to sit in front of every alert. The closest thing to a measurement is triagedy doctor, which prints a decision round-trip time against the live endpoint. No throughput numbers, concurrency figures or alert-volume benchmarks are published, so treat 200 ms as a design claim you can check yourself with doctor.

What changes if I run it against a local model instead of Jev?

The pipeline is identical — point --backend openai at Ollama, vLLM, LM Studio, llama.cpp or OpenRouter. What changes is trust: the README says confidence values there are the model's self-report and should be treated as uncalibrated. Records then carry confidence_calibrated false plus an advisory note, and contain or high-severity escalate force review_required so a shaky number cannot quietly trigger containment.

Will one malformed alert take down the batch?

No. A bad line becomes an error record with ok false and an error message, and the run continues. Output stays one JSON object per input alert in input order, even under --jobs 4, because parallelism never reorders. Exit codes separate the cases: 0 when every record is ok, 1 when at least one failed, 2 for a config or runtime error.

Are the routing thresholds fitted to real data, or hand-written?

Hand-written constants, and the README offers no procedure for fitting them to your environment. The policy in src/policy.rs is deliberately plain Rust with no prompts in it, which makes it easy to edit, but nothing tells you which values suit your alert volume. A close needs to clear a false-positive gate that tightens with severity, and a high duplicate_of_recent can downgrade an escalate to an investigate below severity 2.0.

What are the five questions asked per alert?

A disposition Choice over close, escalate, contain, or investigate; a severity Score from 0 to 3; a false-positive Noul; an immediate-IR-escalation Noul; and an attack-class Choice mapped to MITRE ATT&CK categories.

How is the API key stored?

triagedy init prompts with hidden input, writes ~/.config/triagedy/env at mode 0600, and prints only the key's length and last four characters; it never echoes the key or puts it on a command line.

Which input formats can it read?

Native JSONL, Elastic ECS flat or nested, and CrowdStrike FDR fields, plus Windows Event Log XML through triagedy convert --format sysmon-xml; the converter rejects DTD and entity declarations.

CommunityJev Tools & CLIs

Triagedy

A Rust filter that reads JSONL security alerts on stdin and asks five Jev questions per alert — disposition, severity, false positive, escalation, ATT&CK class — then applies the routing policy in ordinary code you control.

See highlights

Open github.com

Stars: 1
Language: Rust
License: MIT
Published by: Community
Author: m0rphtail
Last verified: Oct 2026

m0rphtail/triagedy

User repository on GitHub

View on GitHub

Alert triage as a UNIX filter: JSONL security alerts in, typed decisions out. Runs on TypeSafe Jev or a local model; policy routing stays in code.

Forks: 1
Last pushed: Updated Sep 2026

Repo stats from the GitHub API, cached Oct 2026.

About this project

Alert triage as a UNIX filter: JSONL security alerts in, typed decisions out. Powered by TypeSafe Jev (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.

Quoted from the project's README. Read the full README.

Tagscommunity jevbest catalog-import

Works forJev for Classification Jev for Routing Jev for Moderation

Used inJev for Software & DevTools

Languages: Rust

Highlights

The model judges and your code decides: the routing thresholds live in src/policy.rs as plain Rust, with no prompts and no framework.
Five orthogonal questions use all three primitives — two Choice, one Score, two Noul — mapped to NIST SP 800-61 triage and the ATT&CK Enterprise Matrix.
Answers are validated against the declared option sets and ranges first, and an invalid answer becomes an error record rather than a silent default.
Parallel runs keep input order, a bad line becomes an error record instead of killing the batch, and --context lets a previous run downgrade restatements.

Watch out

Triage is not detection. The tool assumes something upstream already produced the alert, and applies a codified SOC Tier-1 workflow whose five questions map to specific NIST SP 800-61 sections and ATT&CK technique categories, with the formal spec in docs/SECURITY_WORKFLOW.md — so an attack that never produces a recognisable alert never reaches it. The routing thresholds are authored constants in src/policy.rs, not values fitted to your traffic: a close must clear a false-positive gate that tightens as severity rises, an investigate escalates only when escalation probability and severity both clear their bars, contain is never downgraded, and any confidence under 0.6 flags the record for review. The README documents no procedure for re-fitting those thresholds to your own environment. The on-prem fallback is honest about its cost: --backend openai works against any OpenAI-compatible server and keeps the same output shape, but there the confidences are the model's self-report, so records are marked confidence_calibrated false, get an advisory note, and high-impact actions force review. The claimed round trip is roughly 200 ms per alert, which is what makes a screen in front of every alert plausible. --backend ollama and --ollama-url still work but are legacy aliases. Copy reviewed against the repository README on 2026-10-04, not from running it.

Questions about this entry

Short answers drawn from the linked project or page.

More Jev resources like this

doc-router

Rust CLI that checks each PDF page for a usable text layer, extracts text pages locally, sends only the rest to an OCR model via LiteLLM, and merges a page-ordered result.