Jev: Decisions > Essays, And A Glimmer Of Hope For Defenders

EDIT: Well, I should have known this was too good to last. TypeSafe just stole the concept without attribution — https://laya.convaiinnovations.com/ — and spun up infra. We really need to burn this all down.

What is Jev?

TypeSafe is a new “AI” kid on the block and they came out fighting with a new model — System One — and a new idiom for interacting with inference engines. They’ve dubbed it “Jev”.

It’s fast and it’s super cheap ($0.042 per million input tokens; no charge on output), and I hope every executive in every major “AI” provider had to change their undergarments the day this new model/service dropped, because it should 100% destroy their chances for trillion dollar IPOs (Narrator: “It won’t”).

I’m going to explain the model and service a bit, but am more going to lean into why I think this is going to be a boon to cybersecurity defenders. You can find a more detailed take on Jev and it’s disruption capabilities in “TypeSafe’s Jev Is About to Change the AI Economy”.

EDIT: If you like mysteries, @jtk@infosec.exchange Shared this excellent attempt to dissect what this black box has beneath it’s cloak: Jev’s Architecture Unmasked — archerhume

First, let me over-simplify the framing…

With “normal” “AI” (think, “chatbot”), you ask it something, then it writes paragraphs. Lots and lots of paragraphs in some dialect of Claudish. They’re all great?, slow blotherers that sometimes (often?) make stuff up, and the blather it spits out is hard for code to use.

With Jev, you show it some text, you ask a question, and it answers one of the choices YOU gave it, plus a number representing how sure it is. For example, give it the headers and body text of an email and ask it “Is this phishing or normal?” and it might respond with ‘"phishing", 97% sure.’ (except in lovely JSON).

This is useful for a few reasons. First, it’s fast and cheap. Think “quick reflex” vs deep thinking. You can run it on a million things without waiting forever or breaking the bank.

Furthermore, answers are fixed shapes. You decide the choices, and it can only pick from your list, so your code doesn’t have to guess what it meant.

Finally, that number it provides is a confidence score that’s rooted in maths from the process, not the LLM generating digits and a percent sign from a next-token process. For the spam case, if the model returns 97% sure, it’s likely safe to auto-block. If that value is 55%, then you can route the process to a human for triage.

An analogy might be a security guard at a door. You give the guard a card with boxes to check (“suspicious? yes/no”, “threat level 1-5”). Guard reads the person, checks boxes, writes a number for how sure. You have rules codified that decide who gets in. The guard never decides alone.

It generates the confidence scores based upon a new training process — Reinforcement Learning for Calibrated Decisions (RLCD). The model doesn’t just get a gold star for being right. It gets said star for truthfully reporting its confidence. So, if it says it’s 80% sure, it actually needs to be right 80% of the time (this is why it’s different from the made up generated percentages from traditional models).

Jed modalties

Jev exposes three primitives for you to use. All share one request shape: state (i.e., the content to judge), questions (i.e., a map of id → question), and instructions.

It may help to actually show the form, but we’ll save full structured examples til the end.

Choice — pick one from fixed set**

When to use it: answer is one of N options, no order between them.

Returns: choice (picked), probabilities (every option), confidence.

Structure:

{
  "type": "choice",
  "instructions": "Which team should handle this ticket?",
  "criteria": {
    "returns": "Exchanges, refunds, wrong or damaged items",
    "shipping": "Delivery status, delays, lost packages",
    "billing": "Charges, invoices, payment problems"
  }
}

Some prompting guidance:

• criteria = map key → description (both sent to model). Descriptions must separate options from each other as two near-identical options = confused probabilities.
• Always add no-match option (“other”, “none of the above”) when nothing may fit as the model cannot pick an omitted value.
• The you get a response back and can use the confidence scores deterministically to either automate something or get a human (or some other process) involved.

Noul — yes/no probability

When to use it: you want a single condition true or false. One Noul per label when several flags may apply independently.

Returns: noul = probability answer is yes. No confidence field.

Structure:

{
  "type": "noul",
  "instructions": "Is the customer asking for a human agent?",
  "criteria": {
    "true": "Mentions a prior attempt, ticket, or asked before",
    "false": "No sign of previous contact"
  }
}

PromptiSome prompting guidance:

• Phrase so high probability = “yes” as this will keep meaning unambiguous.
• Note that the criteria is optional. Only add it when yes/no meaning needs nuance. Definitely test with and without, then pick what scores better on your data.
• Note also that a noul near 0.5 = no signal. Not “medium”.

Score — a position on ordered spectrum

When to use it: answer is degree along a describable scale. Severity, relevance, urgency, formality.

Returns: score (can fall between levels), probabilities per level, confidence.

Structure:

{
  "type": "score",
  "instructions": "How severe is the reported bug?",
  "criteria": [
    "Cosmetic; no impact to functionality",
    "Broken feature, but workaround exists",
    "Blocking issue; no workaround exists"
  ]
}

Some prompting guidance:

• Super important: criteria is ordered array, low end first → high end. There’s also a minimum of two levels and a maximim of ten.
• Each level must describe a concrete/stand alone situation. Vague or multi-dimensional levels will result in a flatter distribution, all with likely low confidence.
• One more time: position is implicit by order. Jev’s own example docs show “0:” prefixes as illustration only. They are not part of the criteria.
• Use Choice if you are unsure about order.

All three modalities have some shared rules:

• Use one narrow judgment per question. Do NOT cram “what kind AND how bad” into one.
• The model needs sufficient state to make a decent call. Give the text plus identities/relationships/policy it needs. Named JSON fields beat one long blob. The docs show how to reference nested states.
• You can (and should?) batch independent questions over same state in one request. They run parallel, and are not influenced by other answers.
• Your thresholds on confidence need to be scaled by risk. High confidence == act. Medium == confirm/flag. Low == human. This way, a potentially destructive action gets a higher bar than read-only. Start conservative, and 100% tune on your own data.

Defender use cases

Jev’s shapes fit defender triage at scale: run a judgment on every alert/event with a threshold on returned probability, with post-processing code that acts only above it.

This is very different than the LLM prompt-and-parse dance:

• There’s a “deterministic” output type (it’s still stochastic model, and the results are heavily dependent on how solidly it was trained). No JSON re-parse (and, let’s be frank, even the generative models tuned to spit out JSON suck at it). Also, there’s no “sorry I can’t” prose. We finally have an interface contract/guarantee.
• I think of the return content from traditional generative processes as “vibes”. Jev’s probabilities are real (provided you got the prompt and context right) that make it way easier to use it in processes that do real actions.
• Your rules, weights, thresholds live in code, so they’re always auditable. The model only judges. Bye bye prompt-injection!
• Cheap/fast enough to run per-event in many cybersecurity workflows

Here are some defender problems that may be “Jev-shaped”.

Detection & triage

• Alert noise. Noul “is this alert a true positive?” plus score severity. SOC only sees alerts above threshold. SOAR auto-fires high-confidence.
• Unknown log/event classification. Judge malicious vs benign on raw/new event text. Find signals before writing detection rules.
• Secret-scanner verification. Regex hits a candidate credential; judge “real secret vs placeholder/example/false positive.” Kills false-positive flood.

Phishing & social

• Email intent. Choice over BEC / credential-harvest / malware / benign, extract URLs, score urgency. Probability drives quarantine vs report-only.
• Domain impersonation. Noul “does domain X impersonate brand Y” at scale over new registrations / cert transparency.

Threat intel

• IOC extraction from unstructured reports, blogs, pastebins. Then Noul verify “is this IOC actually tied to the described campaign.”
• Claim/citation check on vendor reports. Verify a claim against its source text.
• Evidence rerank. Rank logs/docs/emails by relevance to an investigation hypothesis.

Vuln mgmt

• CVE relevance. Score “exploitable/relevant to our stack” combining description + vulnerability metadata + asset context. Replaces blanket “patch everything.”

Investigation

• Analyst question to typed query. Function calling maps natural language to whatever log/TIP/enrichment stack you have.
• Config/C2 extraction from decoded malware strings.

Compliance (ugh)

• Map control evidence text to NIST/CIS controls for audit prep.

A concrete example

I hesitated putting this part in as it has the potential help some entities that deserve neither help or my thoughts anymore. But, let’s be real, they’re just going to prompt an AI to do human work anyway, so will likely fail miserably at this particular task).

As I blather about way too much, I run a deception fleet with Glenn Thorpe and there’s a pretty sweet use case for Jev in this context. For non-cyber folks (this is another oversimplification), a deception fleet == fake web apps (honeypots). Existing detection rules catch known signatures: specific paths, known scanner UAs, default creds. But every day a long tail of requests matches nothing. From previous experience I can assure you that an analyst can’t hand-review thousands of these. That tail is where Jev fits.

The setup: all detection rules stay authoritative and deterministic. Jev only touches unclassified requests. Rules are syntactic (match this path/regex), this Jev process is semantic (what is this actually trying to do?).

Step 1 — unclassified request lands

(Fake) example that slipped no rule caught:

{
  "method": "POST",
  "path": "/wp-login.php",
  "host": "payroll.internal.example.com",
  "user_agent": "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)",
  "source_ip": "203.0.113.5",
  "source_asn": "AS64500",
  "body": "log=admin&pwd=Password123!&wp-submit=Log+In",
  "ts": "2026-09-19T04:12:33Z"
}

No rule fires because no single field trips a signature. But three things together are bad: POST to login, default creds, fake Googlebot UA.

Step 2 — batch independent questions over one state

One request, four parallel judgments:

{
  "state": { "...request fields above..." },
  "model": "jev-latest",
  "questions": {
    "is_automated": {
      "type": "noul",
      "instructions": "Is this request automated, not a human in a browser?"
    },
    "intent": {
      "type": "choice",
      "instructions": "What is the requester's apparent goal?",
      "criteria": {
        "credential_access": "Trying to log in, guess credentials, or access accounts",
        "recon": "Probing paths, versions, or capabilities",
        "exploitation": "Attempting to run code, inject, or exploit a vulnerability",
        "exfiltration": "Attempting to read or extract sensitive data",
        "benign": "Legitimate or harmless traffic"
      }
    },
    "ua_spoofed": {
      "type": "noul",
      "instructions": "Is the User-Agent impersonating a known bot or crawler?"
    },
    "threat_level": {
      "type": "score",
      "instructions": "How threatening is this request to a decoy host?",
      "criteria": [
        "Benign noise, nothing targeting",
        "Suspicious but inconclusive",
        "Likely malicious, clear targeting",
        "Active attack against a specific service"
      ]
    }
  }
}

Step 3 — Jev returns typed answers

{
  "answers": {
    "is_automated": { "type": "noul", "noul": 0.98 },
    "intent": {
      "type": "choice",
      "choice": "credential_access",
      "probabilities": {
        "credential_access": 0.91,
        "recon": 0.05,
        "exploitation": 0.03,
        "exfiltration": 0.0,
        "benign": 0.01
      },
      "confidence": 0.88
    },
    "ua_spoofed": { "type": "noul", "noul": 0.96 },
    "threat_level": {
      "type": "score",
      "score": 2.7,
      "probabilities": { "0": 0.0, "1": 0.05, "2": 0.35, "3": 0.6 },
      "confidence": 0.72
    }
  }
}

Step 4 — code routes on probabilities, not text

The model never acts. Code owns policy:

package jevacata

import "slices"

type Intent struct {
	Choice     string
	Confidence float64
}

type ThreatLevel struct {
	Score float64
}

type Answers struct {
	Intent      Intent
	ThreatLevel ThreatLevel
}

type Request struct {
	SourceIP string
	// ...
}

// createAlert takes an options struct instead of Python keyword args.
type AlertOptions struct {
	Labels string
	Threat float64
}

var maliciousIntents = []string{"credential_access", "exploitation", "exfiltration"}

func Handle(request *Request, answers Answers) {
	intent := answers.Intent
	threat := answers.ThreatLevel

	switch {
	case intent.Confidence < 0.5:
		routeToAnalyst(request) // model unsure, don't guess

	case intent.Choice == "benign" && threat.Score < 1.0:
		drop(request) // noise, discard

	case slices.Contains(maliciousIntents, intent.Choice) && threat.Score >= 2.0:
		createAlert(request, AlertOptions{
			Labels: intent.Choice,
			Threat: threat.Score,
		})
		blockSourceIP(request.SourceIP)
		feedThreatIntel(request) // IOC + ASN to feed

	default:
		queueForReview(request) // mid-confidence, human verifies
	}
}

Step 5 — close the loop

High-confidence labels have two modalities:

• Immediate: auto-block, honeypot can serve deeper fake content.
• Feedback: analyst-confirmed labels become training signal. Same pattern seen N times = promote to deterministic rule. Rule then catches it before Jev even runs.

Detection rules handle the known head.

Jev handles the semantic tail.

Human arbitrates the uncertain middle.

FIN

I have not been excited about much in “tech” for about six months, mostly due to the impact AI has had on tech.

I work with “AI” to help defenders (especially the underresourced ones) have some sort of chance at stopping or finding attackers by baking in the knowledge and capabilities of seasoned practitioners into systems hooked up to high-quality data to help real humans make real decisions as quickly as they need to in this elevated threat landscape we live in.

I am truly excited at the possibilities Jev offers, and even more excited that I can see this becoming something we can run locally with models hyper-trained to solve cyber-shaped problems.

Now, it’s time to build some solutions.