How TypeSafe’s Jev — a model that returns probabilities, not paragraphs — replaces 500 regex rules with one API call, catches credential leaks in milliseconds, and monitors 100+ logs/sec using a batch window architecture nobody else is talking about.
🍋 The Lemon Explanation: What Even Is Jev?
Okay, let me start with the simplest possible explanation.
You know how when you ask ChatGPT something, it writes you paragraphs? It generates words. Lots of words. Some useful, some not. You then have to read those words and figure out what to do with them in your code.
Jev doesn’t do that.
Here’s the lemon version:
Imagine you have a super-smart friend who you can ask yes/no questions or “pick one from this list” questions — and they answer instantly with a confidence score. They don’t explain themselves. They don’t write essays. They just say: “Database issue. 87% confident. Emergency page on-call.”That’s Jev.
Jev is a System One model — it’s built for fast, structured judgment. Like your gut reaction, but calibrated, typed, and callable from code.
The output isn’t a string of text. It’s a typed JSON object with probabilities. Your code reads it and acts. No parsing, no prompt engineering for output format, no string regex to extract the answer.
🧠 Jev vs. Traditional LLMs — What’s Actually Different?
Let me make this crystal clear with a table:
FeatureGPT / Claude / GeminiJev (TypeSafe System One)Output formatText (you parse it)Typed JSON (probabilities + choice)What it does wellWriting, reasoning, explanationFast structured judgmentSpeedSeconds (reasoning takes time)Sub-second judgmentsToken costInput + output tokensInput only — output tokens = 0How you use itWrite a prompt, parse a responseDefine questions + criteria, consume answersGood forOpen-ended tasksDecisions your code needs to makeUncertaintyHidden inside textExplicit — every answer has a probabilityDrift riskHigh (prompt changes break output format)Low (schema is your contract)
The key insight: traditional LLMs are optimized to be helpful to humans reading their output. Jev is optimized to be helpful to code reading its output.
⚙️ How Jev Works — Three Primitives, That’s It
Jev gives you three building blocks. Everything is a combination of these three:
1. choice — Pick one from a defined list
{
“type”: “choice”,
“instructions”: “What is the failure domain of this log?”,
“criteria”: {
“database”: “DB queries, connection pools, Postgres errors”,
“network_dns”: “Socket timeout, DNS failure, TLS handshake”,
“auth_security”: “Auth failures, token errors, credential leaks”,
“app_logic”: “NullPointer, assertion, business rule violation”
}
}
Jev returns: { choice: “database”, confidence: 0.92 }
2. noul — Probability of a yes/no condition
{
“type”: “noul”,
“instructions”: “Is there risk of an imminent system outage?”,
“criteria”: {
“true”: “Cascading failure, resource exhaustion, multi-service degradation”,
“false”: “Isolated, recoverable, routine error”
}
}
Jev returns: { noul: 0.87 } — that’s 87% probability of YES.
3. score — Rate something along a defined scale
{
“type”: “score”,
“instructions”: “Rate severity from benign (1) to catastrophic (5)”,
“criteria”: [
“Level 1: Routine trace, healthy HTTP 200”,
“Level 2: Normal operational event”,
“Level 3: Non-critical warning”,
“Level 4: Degraded subsystem, high latency”,
“Level 5: Fatal failure, OOM, credential leak”
]
}
Jev returns: { score: 3.8, confidence: 0.91 }
You ask multiple questions in one API call, and they all run in parallel. No waiting for one to finish before asking the next.
🏗️ The Problem We Set Out to Solve: Log Analysis is Broken
Here’s what every engineering team does today:
Logs go into Datadog / CloudWatch / ELKYou write regex rules: if log.contains(“OOM”) → alertYou get paged at 3am because “OOM” appeared in a test logOR you miss a real outage because the message was “heap exhausted” not “OOM”
Regex-based log alerting has three fatal flaws:
❌ It’s literal — it only catches exact strings. “DB connection failed” and “could not connect to postgres” are the same thing to a human but different patterns to a regex.
❌ It’s single-log blind — each log is evaluated in isolation. But the scary pattern is: DB pool timeout → queue backup → memory pressure → OOM crash. Three individually “fine” logs that together scream “wake up on-call NOW.”
❌ It exposes secrets silently — a log like “Connecting to postgresql://admin:super_secret_123@prod-db:5432/users” contains a plaintext credential. Regex might catch password= but it won’t catch URL-encoded credentials, JWTs in headers, or PII in custom formats.
We wanted to solve all three with one model call.
🔨 How We Built the TypeSafe Log Guardian
Let me walk you through the actual architecture. It’s simpler than you think.
The Stack
Backend: Node.js + Express + TypeScriptAI Brain: TypeSafe Jev (via REST API)Frontend: Vanilla HTML/CSS/JS (no framework needed)Pattern: Batch Window Engine
The Breakthrough Idea: Batch Windows
Instead of analyzing logs one-by-one (which is slow and misses cross-log patterns), we collect ALL logs from a time window (say, 2 seconds) and send them to Jev in a single API call.
Logs coming in at 100/sec
↓
[Buffer for 2 seconds]
↓
2 seconds × 100 logs/sec = 200 logs
↓
ONE Jev call with all 200 logs
↓
Jev sees the whole picture, not just individual lines
This is the killer feature. Jev can say:
“3 services are showing simultaneous resource exhaustion. DB pool is full, memory is at 94%, and there are 284 requests queued. This is a coordinated cascade. Wake up on-call NOW.”
No per-log rule system can ever do that. Because each log, individually, looks borderline okay.
The Code: Sending a Batch to Jev
Here’s the real code from our typesafe-analyzer.ts:
// Build a compact log digest for Jev
const logDigest = logs
.map((l, i) =>
`[${i + 1}] svc=${l.service} level=${l.level} msg=”${l.message.substring(0, 200)}”`
)
.join(‘n’);const state = {
analysis_mode: ‘batch_window’,
window_duration_ms: windowMs,
log_count: logs.length,
services_present: […new Set(logs.map(l => l.service))],
level_distribution: {
ERROR: logs.filter(l => l.level === ‘ERROR’).length,
WARN: logs.filter(l => l.level === ‘WARN’).length,
INFO: logs.filter(l => l.level === ‘INFO’).length,
},
log_batch: logDigest,
};const questions = {
system_health_score: {
type: ‘score’,
instructions: `Rate the overall system health from 1 (catastrophic) to 10 (perfect)`,
criteria: [
‘Level 1: Multiple simultaneous critical failures — OOM, DB pool exhausted, credential leaks’,
// … etc
],
},
highest_urgency: {
type: ‘choice’,
instructions: ‘What is the HIGHEST urgency action required?’,
criteria: {
none: ‘All logs are benign. No action needed.’,
low: ‘Minor warnings. Engineering team should be aware.’,
high: ‘Significant issues — notify DevOps immediately.’,
critical: ‘CRITICAL: Multiple severe events — wake up on-call NOW.’,
},
},
batch_outage_risk: {
type: ‘noul’,
instructions: ‘Is there a credible risk of outage in the next 5–15 minutes?’,
criteria: {
true: ‘Patterns indicate cascading failure heading toward outage.’,
false: ‘Errors are isolated, handled, or not systemic.’,
},
},
batch_leak_detected: {
type: ‘noul’,
instructions: ‘Do ANY logs contain exposed secrets, credentials, or PII?’,
criteria: {
true: ‘At least one log has unredacted passwords, API keys, JWTs, or PII.’,
false: ‘No sensitive data detected in any log in this batch.’,
},
},
};// ONE API call for the entire batch
const response = await fetch(‘https://api.typesafe.ai/v1/systemone’, {
method: ‘POST’,
headers: { ‘Authorization’: `Bearer ${API_KEY}`, ‘Content-Type’: ‘application/json’ },
body: JSON.stringify({ state, model: ‘jev-latest’, questions }),
});
That’s it. One POST. Jev evaluates ALL questions against ALL logs simultaneously and returns structured JSON.
What Jev Returns
{
“answers”: {
“system_health_score”: { “score”: 2.1, “confidence”: 0.88 },
“highest_urgency”: { “choice”: “critical”, “confidence”: 0.95 },
“batch_outage_risk”: { “noul”: 0.89 },
“batch_leak_detected”: { “noul”: 0.97 }
},
“usage”: { “input_tokens”: 847 }
}
Notice: output_tokens doesn’t exist. Jev’s structured judgments are computationally free on the output side. You only pay for what you send in.
The Single-Log Deep Inspector
For manual analysis or individual suspicious logs, we also support single-log mode with 5 parallel questions:
QuestionPrimitiveWhat it tells yousensitive_data_leakchoiceIs there a password, JWT, API key, or PII?impending_outage_risknoulProbability this log signals a coming crashseverity_scorescore1-5 architectural severityrecommended_actionchoicesuppress / record / notify / emergency pagefailure_domainchoicedatabase / memory / network / auth / app_logic
All five run in one API call, in parallel.
The Redaction Engine
When Jev detects a credential leak, we don’t just alert — we automatically redact:
// If Jev says it’s a plaintext password:
redacted = message.replace(
/(password|pass|pwd|secret)s*[:=]s*[“‘]?([^”‘,s]+)[“‘]?/gi,
‘$1=”[REDACTED_SECRET]”‘
);// If Jev says it’s a JWT/API key:
redacted = message.replace(
/eyJ[a-zA-Z0-9_-]{10,}.eyJ[a-zA-Z0-9_-]{10,}.[a-zA-Z0-9_-]+/g,
‘[REDACTED_JWT]’
);
The detection is AI-powered (catches anything). The redaction is precise regex (fast, deterministic). Best of both worlds.
The Server Architecture
Express Server (port 3000)
│
├── POST /api/logs/analyze → Single-log Jev analysis
├── POST /api/logs/batch → Batch window Jev analysis
├── GET /api/stream → SSE stream (single-log results)
├── GET /api/batch-stream → SSE stream (batch results)
└── Static files → /public → Frontend dashboard
The frontend connects via Server-Sent Events (SSE) — a lightweight WebSocket alternative. New Jev results appear in the UI in real time without polling.
🎯 Use Cases Beyond Log Analysis
Once you understand the Jev pattern — send structured state, ask typed questions, get calibrated answers — you start seeing it everywhere:
1. 🛒 E-commerce: Smart Cart Abandonment
State: { user_session, cart_value, pages_viewed, time_on_site }
Questions:
– purchase_intent: noul (probability they’ll buy)
– discount_sensitivity: score (1-5 how price-sensitive)
– recommended_nudge: choice (none / email / coupon / live_chat)
No hallucinated persuasion copy. Just: show coupon? Yes/№78% confidence.
2. 🏥 Healthcare: Triage Routing
State: { patient_symptoms, vitals, history }
Questions:
– urgency_level: score (routine → emergency)
– likely_department: choice (cardiology / neurology / ortho / …)
– escalate_to_physician: noul
3. 📧 Email: Support Ticket Classification
State: { email_subject, email_body, sender_tier }
Questions:
– department: choice (billing / technical / sales / abuse)
– sentiment: score (furious → delighted)
– requires_human: noul
– priority: choice (low / normal / urgent / critical)
4. 🔐 Security: Real-Time Threat Scoring
State: { ip_address, request_pattern, user_agent, geo_location }
Questions:
– is_bot: noul
– attack_type: choice (sql_injection / xss / brute_force / legitimate)
– block_action: choice (allow / rate_limit / captcha / block)
5. 📝 Content Moderation at Scale
State: { post_content, user_history, platform_rules }
Questions:
– violates_policy: noul
– violation_category: choice (spam / hate / misinformation / explicit)
– action: choice (approve / warn / remove / ban)
6. 💰 FinTech: Transaction Risk
State: { transaction, account_history, device_fingerprint }
Questions:
– fraud_probability: noul
– risk_tier: score (low → high)
– action: choice (approve / step_up_auth / decline / freeze_account)
The pattern is always the same:
Describe your context as structured stateAsk your questions using the three primitivesConsume the typed answers in codeAct deterministically based on probabilities
📊 Why This Beats Traditional Approaches for Log Analysis
Let me be concrete about the problem our app solves:
ScenarioRegex / RulesJev Batch Mode”password=abc123″ in log✅ Caught (keyword match)✅ Caught”my DB creds are admin/secret”❌ Missed✅ Caught (understands context)JWT token in a URL param❌ Depends on regex✅ Caught3 services showing simultaneous exhaustion❌ Each log looks fine individually✅ Cross-log cascade detected”50 active connections” — critical or not?❌ No context✅ Context-aware (depends on max pool size, other logs)New log format you’ve never seen❌ New rules needed✅ Works out of the boxCostFree~$0.05–0.10 per 100-log batch
The $0.05–0.10 cost per 100-log batch vs. a security breach that costs $100,000+? The math is obvious.
🚀 Running It Yourself — 5 Minutes to a Running System
Prerequisites
Node.js 18+A TypeSafe API key (get one at typesafe.ai)
Clone & Run
# Clone the repo
git clone https://github.com/padmarajkore/AI-Log-Analyzer.git
cd log-analyzer# Install dependencies
npm install# Add your API key
echo “TYPESAFE_API_KEY=your_key_here” > .env# Start the server
npm run dev
Open http://localhost:3000 — you’ll see the dashboard.
Try the Simulator
# In a second terminal, start the log traffic generator
npm run simulate
This fires realistic microservice logs at 1 log/sec by default. Crank it up in the UI to 100+/sec to see the batch engine in action.
Send Your Own Logs
# Test a credential leak
curl -X POST http://localhost:3000/api/logs/batch
-H “Content-Type: application/json”
-d ‘{
“windowMs”: 2000,
“logs”: [
{
“service”: “auth-service”,
“level”: “ERROR”,
“message”: “DB connect failed: postgresql://admin:super_secret_prod_123@db.prod:5432/users”
},
{
“service”: “payment-gateway”,
“level”: “WARN”,
“message”: “Connection pool: active=50 idle=0 waiting=284”
}
]
}’
Watch the dashboard light up with a CRITICAL alert. Jev will catch the credential leak AND the cascading connection pool exhaustion — in one call.
🏁 What We Learned Building This
1. The batch window idea is underrated. The shift from per-log analysis to window-based batch analysis is a paradigm shift. It’s what lets you catch cascading failures that look invisible at the individual log level.
2. Output tokens = 0 is a superpower. Traditional LLM calls cost you input + output. Jev’s structured judgments have effectively zero output tokens. For a high-volume use case like log analysis, this cost model is orders of magnitude better.
3. Calibrated uncertainty is actually useful. When the outage probability is 0.51 vs 0.89, you want to know the difference. An LLM saying “there might be an issue” vs. Jev saying “87% outage probability” leads to completely different actions.
4. AI detection + deterministic redaction = best of both worlds. Don’t try to make AI do the redaction (slow, expensive, unpredictable). Use Jev to detect the category, then apply a precise regex to redact. Fast and reliable.
5. TypeScript + Jev = type safety all the way. Because Jev returns structured JSON with known shapes, you get end-to-end type safety. No any casting after parsing model output.
🔗 Try It Yourself
The full source code is available on GitHub:
👉 github.com/YOUR_GITHUB_LINK_HERE
It includes:
src/typesafe-analyzer.ts — The Jev integration (single + batch modes)src/server.ts — Express API + SSE streamingsrc/log-simulator.ts — 12 microservices, 80+ realistic log templatespublic/ — The real-time dashboard UItest/test-scenarios.ts — Ready-made test cases (credential leaks, OOM, cascades)
Clone it, drop in your TypeSafe API key, and have a live AI log guardian running in under 5 minutes.
💭 Final Thought
We’re at an interesting moment in AI tooling. There are two very different things AI can do for software:
Generate content for humans to read — ChatGPT, Claude, writing assistantsMake decisions for code to act on — Jev, structured judgment models
Most of the AI hype focuses on #1. But #2 — programmable AI decisions embedded directly in your application logic — is where I think the real engineering leverage is.
Jev is the first model I’ve used that genuinely feels like a programming primitive rather than a human assistant. You write code that uses its judgments the same way you’d use a return value from any function — type-safe, deterministic, predictable.
And for log analysis specifically? It catches the things regex can never catch, sees patterns across logs that per-log rules can never see, and runs at production scale for a cost that’s negligible compared to the incidents it prevents.
That feels like the future of AI in production software.
Built with TypeSafe Jev · Node.js · TypeScript · Express · Vanilla JS
👉 GitHub: https://github.com/padmarajkore/AI-Log-Analyzer
👉 TypeSafe docs: docs.typesafe.ai
Jev Is Not a Chatbot. It’s a Judgment Engine — And I Built a Real-Time Log Guardian With It was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.