Welcome

How to Cite This Book

If you use this book in your work, please cite it as:

APA: Chaudhri, A. (2026). Seven Ways to Use Jev. Self-published. https://seven-ways-jev.github.io/

BibTeX:

@online{chaudhri2026sevenwaysjev,
  author  = {Chaudhri, Akmal},
  title   = {Seven Ways to Use Jev},
  year    = {2026},
  url     = {https://seven-ways-jev.github.io/},
  urldate = {2026-10-01}
}

Cover

License

Copyright

Copyright © 2026 Akmal Chaudhri. All rights reserved.

Publication Information

First published: October 2026

The latest version of this book, together with updates, errata and additional resources, is available at:

seven-ways-jev.github.io

Book License

Seven Ways to Use Jev is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License (CC BY-NC-ND 4.0).

You are free to copy and redistribute this book in any medium or format under the following conditions:

• Attribution - You must give appropriate credit, provide a link to the license and indicate if changes were made.
• NonCommercial - You may not use the material for commercial purposes.
• NoDerivatives - If you remix, transform or build upon the material, you may not distribute the modified material.

The full license text is available at:

creativecommons.org/licenses/by-nc-nd/4.0

Code License

Unless otherwise stated, all code samples, notebooks, scripts and source files accompanying this book are licensed under the Apache License 2.0.

You are free to use, modify and redistribute this code, including for commercial purposes, subject to the terms of the Apache License 2.0.

The full license text is available at:

apache.org/licenses/LICENSE-2.0

This distinction means that the book’s written content is protected under the Creative Commons license, while the accompanying code remains freely available for use, modification and integration into your own projects.

Trademarks

Product names, company names and logos mentioned in this book may be trademarks or registered trademarks of their respective owners.

Their inclusion is for identification and educational purposes only and does not imply any affiliation with, sponsorship by or endorsement from the respective trademark holders. All trademarks remain the property of their respective owners.

Disclaimer

The information in this book, including all code samples, scripts and notebooks, is provided “as is” without warranty of any kind, express or implied.

The author makes no representations or warranties regarding the accuracy, completeness, reliability or suitability of the information contained herein for any particular purpose.

Examples are provided solely to illustrate technical concepts, patterns and software architectures.

Readers are responsible for independently validating all code, configurations and recommendations before using them in production environments.

To the fullest extent permitted by law, the author shall not be liable for any direct, indirect, incidental, special, consequential or other damages arising from the use of or inability to use, the information, code or techniques described in this book.

About the Author

Akmal Chaudhri is a technical leader, educator and author with extensive experience in databases, AI and developer relations. He specializes in technical writing, developer education and community building, helping engineers and organizations understand and adopt complex technologies through clear, practical and engaging content. He is a frequent international speaker, a published author and a contributor to industry discussions on data platforms, AI and software development.

Today, Akmal works in developer education at Neo4j, where he focuses on technical content, workshops and community initiatives. While his professional role has evolved, this book represents an independent exploration of Jev.

Based in the United Kingdom, Akmal continues to work at the intersection of databases, AI and developer tooling, helping developers build modern data-driven applications.

For book updates, code samples and additional resources, visit the Book website.

To connect professionally or follow his latest work, visit LinkedIn.

Introduction

Most AI models are designed to converse. You give them a prompt, they give you text back. That text might be excellent – detailed, nuanced, well-written – but it’s freeform. If you want to act on it programmatically, you have to parse it, validate it and hope the format holds across different inputs.

Jev, from TypeSafe AI, is built on a different premise. It’s a structured decision model: you give it a state object and a set of typed questions and it returns typed answers with calibrated confidence scores. No parsing required. No format negotiation. Just a decision and a number that tells you how certain that decision is.

TypeSafe describe Jev as a “System One” model – built for the kind of fast, atomic, well-scoped judgments that a highly knowledgeable person could make in a few seconds given the right context. Not a general-purpose reasoner. Not a planner. A decision maker.

The core primitive is the Choice: a question with named options, each described in plain language, plus an instruction telling Jev what to weigh. Each Choice returns the selected option and a confidence score between 0 and 1. That confidence score is what makes Jev useful in production – not just as a curiosity, but as an operational signal. A high-confidence decision routes automatically. A low-confidence decision goes to a human reviewer. The threshold between them is a business decision, not a technical one and it’s tunable.

What this book covers

Seven domains, seven notebooks, one pattern: structured state in, typed decision out, confidence score alongside.

The chapters are independent. You can read them in any order and run any notebook without having read the others. Each is self-contained, with synthetic data usually generated inside the notebook and no external dependencies beyond a TypeSafe API key.

The domains span a deliberate range of difficulty and context:

• Transit routing: a graph problem where we first try to use Jev the wrong way, then the right way
• Customer support triage: two sequential decisions per ticket, team then priority
• Financial fraud detection: a binary flag-or-pass decision with a three-tier response based on confidence
• Content moderation: three options and a finding about how Jev uses (or doesn’t use) the middle one
• Supply chain disruption: selecting an alternative supplier under pressure, with a surprising confidence pattern
• Hiring screening: three options again, with a much more even distribution than content moderation
• Medical symptom triage: four pathways, a conservative bias built into the instructions and the strongest disclaimer in the book

What you’ll see across chapters

A few patterns emerge across all seven chapters and are worth keeping in mind from the start.

The confidence score matters more than the decision for uncertain cases. Across every chapter, the low-confidence decisions are the interesting ones – not because Jev got them wrong, but because they’re the decisions where no system should be acting automatically. High confidence means act. Low confidence means review. The decision itself is secondary.

Three options work better in some domains than others. Hiring produced a genuine spread across Advance, Review and Decline. Content moderation produced almost no Flag decisions – Jev leaned binary and the confidence score did the work that Flag was supposed to do.

Confidence reflects internal certainty, not objective difficulty. The supply chain chapter shows this most clearly: the scenario we expected to be hardest produced the highest confidence, because Jev had a strong opinion about which trade-off mattered. The one we expected to be easy produced the lowest confidence, because the options were genuinely close.

The threshold is always yours to set. Every chapter ends with some version of the same observation: the confidence threshold that separates automatic decisions from human review is a business decision. Jev provides the infrastructure; you set the policy.

Running the notebooks

Each notebook installs its own dependencies, generates its own data and runs end to end with a single environment variable:

export TYPESAFE_API_KEY="your-api-key"

jupyter notebook 01_northern_line.ipynb

Chapter 1 additionally uses CARTO map tiles for the Folium maps. A CARTO API key is optional – the notebook falls back to OpenStreetMap tiles if none is provided:

export CARTO_API_KEY="your-api-key"

Chapter 1 also requires three CSV files in a data/ directory alongside the notebook. All other chapters generate their data internally.

Chapter 1: Transit Routing

The Northern Line Branch

The London Underground’s Northern line presents a genuine decision problem. Between Kennington and Euston the line splits into two branches that don’t share a single station until they both reach Euston:

• Via Charing Cross (8 stops): a slightly shorter route running through the West End
• Via Bank (9 stops): a slightly longer route running through the City

On a quiet day with both branches running normally, the right choice is obvious: take Charing Cross, it’s one stop shorter. But the moment something goes wrong on the network, the right choice depends on live information that a static algorithm doesn’t have.

This chapter uses that branch decision as a vehicle for exploring two questions. First: can Jev navigate a network hop by hop, making a fresh decision at every step? Second: is that even the right way to use it?

What we find along the way tells us something useful about where Jev actually earns its place.

The Data

We use the real London Underground dataset: around 350 stations, all lines, with geographic coordinates for each station. We load it into a NetworkX MultiGraph directly from CSV files. A MultiGraph is essential here because many stations are served by multiple lines and a plain Graph would overwrite one line’s edges with another’s when the same station pair appears more than once.

Each station is a node carrying its coordinates and zone. Each connection is an edge carrying the line name. The dataset includes all its real-world naming quirks: “Kings Cross St. Pancras” has no apostrophe, and “Elephant and Castle” is spelled out in full.

The notebook verifies all branch station names against the graph before running anything.

Part 1: Jev as a Sequential Planner

Our first approach was to use Jev as a navigation agent: query the graph for the current station’s neighbors, pass the live state to Jev, let it pick the next hop, and repeat until we reach Euston.

This is an appealing idea. It means the route adapts at every step rather than being fixed at the start. If something changes mid-journey, the very next call to Jev incorporates it.

Baselines

Before introducing Jev, we establish two baselines using NetworkX’s shortest_path().

The unconstrained version finds the globally optimal route across all lines: 6 hops via Waterloo, Westminster, Green Park, Oxford Circus and Warren Street. That crosses the Jubilee and Victoria lines – a real Northern line passenger wouldn’t consider this a valid route.

Adding a Northern-line-only constraint finds the correct result: 8 hops via the Charing Cross branch (Waterloo, Embankment, Charing Cross, Leicester Square, Tottenham Court Road, Goodge Street, Warren Street). Both queries run in well under a millisecond.

The key point: shortest_path() is exact and context-naive by design. It finds the best answer within whatever constraints you give it. The constraints are your job.

What happened

Across multiple northbound runs from Kennington to Euston, Jev consistently chose the Bank branch – 9 hops every time, even though the Charing Cross branch is one stop shorter. Hop-1 confidence was consistently low throughout.

We then injected a disruption. At Leicester Square, four stops into the Charing Cross route, the incident note reported Warren Street suspended ahead. The hypothesis was that Jev might decide to push on toward the disruption or backtrack and reroute via Bank. Instead, it made no change at all. Same Bank branch, same 9 hops, same confidence range – because it had already committed to Bank at Kennington before Leicester Square was ever in the path.

The reverse journey (Euston to Kennington, southbound) was more consistent but in the opposite direction: Charing Cross branch every time, with noticeably higher confidence. The same network, the same graph, a different direction and a different stable preference. That directional asymmetry is almost certainly a training data artifact, not geographic reasoning.

The most revealing experiment was starting from Waterloo, which sits on the Charing Cross branch with no fork to navigate. Without the anchor of a clear branch decision, hop counts varied widely across 5 runs and confidence dropped significantly. The structured problem that had produced consistent results at Kennington became underdetermined when the framing changed.

What this tells us

TypeSafe are explicit about what Jev is designed for: fast, atomic, well-scoped judgments – “the kind a highly knowledgeable person could make in a few seconds given the right context.” A nine-hop sequential plan isn’t that. It’s a planning problem, and shortest_path() solves planning problems in under a millisecond.

None of this is a criticism of Jev. It’s a mismatch between problem shape and tool design.

Part 2: Branch Triage

The fairer test is to ask Jev for one decision: at Kennington, which branch should a passenger take?

We store disruption state directly on the graph nodes, query both branches’ current state, build a plain-language summary of each and pass both to Jev as a single Choice question with two options. One call, clear state, two options. That’s the shape of problem Jev was built for.

We run this across four disruption severities, three times each:

This is exactly the behavior TypeSafe describe. With both branches clear, Jev chose Charing Cross – the shorter route – with solid confidence. A 5-minute delay on a station that can’t be bypassed was enough to flip the decision to Bank and confidence rose because the signal got clearer. A full suspension produced even higher confidence and two suspended stations produced the highest confidence of all. Every run was unanimous. Latency was well under 500 milliseconds per call – a fraction of the time the sequential pathfinder took per complete journey.

The confidence with no disruption is worth noting. Jev isn’t overconfident. Both branches are valid, Charing Cross is one stop shorter and the moderate confidence reflects a real preference – but it also signals that Bank isn’t a bad choice, which is true.

The Right Architecture

A shortest-path algorithm is exact, instant and optimal within whatever constraints you give it. Add a line constraint and it finds the Northern-line-only optimal in the same single call. It has no concept of disruption, live state, or calibrated uncertainty. Those aren’t gaps – they’re design choices.

Jev is the right tool for the judgment calls that sit on top of that: which of these valid options is better right now, given what’s happening? That question requires weighing uncertain information and returning a decision with calibrated confidence. That’s what Jev is built for.

The algorithm finds the route. Jev decides which route is worth taking.

Chapter 2: Customer Support Triage

The Problem

Every support operation faces the same challenge: an incoming ticket needs to reach the right team at the right priority and it needs to happen fast. Get it wrong and a critical production outage sits in the general queue. A billing dispute gets escalated to the engineering team. A security researcher’s responsible disclosure report sits unanswered for three days.

Rules-based routing – keyword matching, tier lookups, category flags – works until the edge cases arrive. A Gold customer whose “quick question” turns out to be a production outage. A billing dispute that’s actually an account security issue. A Free-tier user whose problem, if ignored, will end up in a public forum.

This chapter uses Jev to make two sequential decisions for each incoming ticket: which team should handle it and at what priority? Each decision returns a calibrated confidence score alongside the answer. That confidence score is the key difference from a rules-based router: instead of silently routing every ticket with equal certainty, Jev flags the ones it’s unsure about so a human can review them before they go anywhere.

The Setup

No external dataset is needed. We generate 20 synthetic tickets spread across four bands designed to test the model across a range of difficulty:

• Clear high-priority: unambiguous critical or urgent issues (API outage, security breach, large overbilling)
• Clear low-priority: unambiguous routine requests (how-to questions, invoice copies, feature requests)
• Ambiguous: mixed signals where the right routing is genuinely unclear (slow dashboard, integration not syncing, login error with a deadline)
• Edge cases: unusual combinations that test the boundaries (responsible disclosure report, churn risk from an Enterprise customer, upgrade blocked by a broken billing page)

Each ticket has a customer tier (Free, Pro, Enterprise), an issue category, a subject line and a description written the way a real customer might write it.

We route to four teams: Billing, Technical, Account Management and General Support. Priority levels are Critical, High, Medium and Low.

Two Decisions per Ticket

Each ticket goes through two sequential Choice calls. The team decision uses the full ticket context. The priority decision adds the team assignment to the state so Jev can factor in who will be handling it before deciding how urgently they need to act.

# Decision 1: Team
team_response = client.system_one(
    state=state,
    questions={
        "team": Choice(
            instructions="Which support team should handle this ticket?",
            criteria=TEAMS,
        )
    },
)

# Decision 2: Priority (state now includes assigned team)
state["assigned_team"] = team_response.choices["team"].choice
priority_response = client.system_one(
    state=state,
    questions={
        "priority": Choice(
            instructions="What priority level should this ticket receive?",
            criteria=PRIORITIES,
        )
    },
)

Results

What the Numbers Tell Us

Team routing is more certain than priority

Across all 20 tickets, Jev was consistently more confident about which team should handle a ticket than about what priority it deserved. That gap is meaningful: knowing where a ticket belongs is often clearer than knowing how urgently it needs to be handled.

Clear tickets aren’t always easier

The confidence-by-band chart shows an unexpected result: clear high-priority tickets had lower mean priority confidence than clear low-priority ones. The reason is that “Low” is easy to assign with certainty – a routine how-to question is unambiguously low priority. But “Critical vs High” is a harder call even for obvious tickets. The large overbilling ticket is a good example: it’s not a service outage, but it’s a serious financial error. Jev’s hesitation there is correct.

Tier is a weak signal

Mean confidence barely varies across customer tiers. Enterprise tickets are slightly easier to route, probably because Enterprise customers write more detailed descriptions. But the difference is small. A rules-based router would give Enterprise tickets automatic priority treatment based on tier alone. Jev is making decisions based on what the ticket actually says.

The three tickets worth flagging

At the confidence threshold, three tickets fall below the line:

T016 (security researcher’s responsible disclosure): high team confidence but low priority confidence. Jev knows it’s Technical but genuinely doesn’t know whether a responsible disclosure report is High or Critical priority. That’s an honest answer – it depends on company policy, not just the ticket content.

T018 (Pro customer trying to upgrade, billing page broken): low team confidence. It’s simultaneously a billing issue and a technical issue – a broken UI on a payment page. Jev can’t decide which team owns this and it shouldn’t pretend otherwise.

T020 (Free user worried about unauthorized account access): low confidence on both team and priority. Routed to General Support at Critical priority. Arguably should go to Technical since it’s potentially a security incident. Both the routing and the urgency are uncertain and the low confidence says so.

These are exactly the tickets a human reviewer should see before they go anywhere.

Latency

Two Jev calls per ticket, running sequentially. Twenty tickets completed in well under a minute. In a production system the two calls could run in parallel for tickets where team and priority are independent, cutting total time roughly in half. Or the priority call could be deferred – route the ticket immediately on team, then assign priority asynchronously before the agent picks it up.

The Confidence Threshold

The threshold is a business decision, not a technical one. Lower it and more tickets get human review – slower but fewer routing errors. Raise it and more tickets route automatically – faster but more misrouted ones. The right number depends on the cost of a wrong routing decision in your operation.

What Jev provides is the infrastructure to make that trade-off explicit. A rules-based router routes every ticket with implicit certainty. Jev routes most tickets automatically and surfaces the ones where certainty runs out.

Chapter 3: Financial Fraud Detection

The Problem

Every payment processor faces the same tension: flag too little and fraudulent transactions go through; flag too much and legitimate customers get blocked and frustrated. Rules-based systems – velocity checks, amount thresholds, country blocklists – are fast but brittle. They miss novel fraud patterns and block legitimate transactions that happen to look unusual.

The deeper problem is that fraud detection is inherently a judgment call. A large jewelry purchase abroad is suspicious for most accounts and completely normal for others. A 4am pharmacy visit is unusual but not fraudulent. A significant electronics purchase at a known retailer in the customer’s home city is probably fine, but it’s well above their typical monthly spend and worth a second look.

This chapter uses Jev to make a single binary decision for each incoming transaction: flag it for review, or pass it through? One call, two options, a calibrated confidence score. The confidence score is what makes this useful in production: a transaction flagged with high confidence goes straight to the fraud queue, while one flagged with lower confidence might warrant a softer intervention – a one-time password or a confirmation SMS – rather than an outright block.

The Setup

We generate 20 synthetic transactions across four bands, each carrying nine contextual signals:

• Amount in USD
• Merchant category and name
• Location (home city, domestic, international)
• Time of day
• Account age in days
• Number of previous flags on the account
• Transactions in the last hour (velocity)
• Typical monthly spend

The four bands are designed to test the full range of difficulty: clear fraud (multiple stacked risk signals), clear legitimate (established account, normal behavior), ambiguous (one or two flags but not conclusive) and edge cases (unusual but potentially legitimate patterns).

One Decision per Transaction

Each transaction goes through a single Choice call. All nine signals go into the state so Jev can weigh them together rather than applying rules sequentially.

response = client.system_one(
    state={
        "amount_usd":                tx["amount_usd"],
        "merchant_category":         tx["merchant_category"],
        "merchant_name":             tx["merchant_name"],
        "location":                  tx["location"],
        "time_of_day":               tx["time_of_day"],
        "account_age_days":          tx["account_age_days"],
        "previous_flags":            tx["previous_flags"],
        "transactions_last_hour":    tx["transactions_last_hour"],
        "typical_monthly_spend_usd": tx["typical_monthly_spend_usd"],
    },
    questions={
        "decision": Choice(
            instructions=(
                "Based on all available signals, should this transaction "
                "be flagged for review or passed through?"
            ),
            criteria=FRAUD_DECISION,
        )
    },
)

Results

What the Numbers Tell Us

Clear cases are easy, edge cases are hard

Mean confidence by band tells the expected story at the extremes: maximum confidence for both clear fraud and clear legitimate. The drop into the ambiguous and edge case bands is substantial and edge cases actually produced lower mean confidence than ambiguous ones – the unusual-but-legitimate patterns were harder for Jev to call than the straightforward mixed-signal cases.

The two most interesting results

TX011 (large electronics purchase at a known retailer, home city, established account): passed with very low confidence. The merchant is legitimate and the location is right, but the amount is well above this customer’s typical monthly spend. Jev passed it but barely believed the decision.

TX014 (ATM withdrawal, Las Vegas, late night, established account): also passed with very low confidence. Domestic, established account, not an extreme amount – but a Las Vegas ATM late at night has a particular profile. Jev passed it and wasn’t sure.

Both of these are exactly the transactions that should trigger step-up authentication rather than a silent decision in either direction.

Category confidence reveals inherent uncertainty

The merchant category confidence ranking shows which categories carry inherent uncertainty regardless of other signals:

• Highest uncertainty: Pharmacy, ATM Withdrawal, Online Gaming, Online Retail – categories where context matters far more than the category name
• Middle: Travel, Jewelry, Electronics – amount and account history do the heavy lifting here
• Lowest uncertainty: Restaurant, Gas Station, Grocery, Home Improvement, Wire Transfer, Gift Cards – the last two are certain in the fraud direction, the others in the legitimate direction

Electronics is the most interesting category across multiple transactions, appearing in both clear fraud (new accounts, international, late night) and edge cases (established account, home city, known retailer). The category name tells Jev almost nothing – it needs the full context.

Transactions flagged for step-up authentication

Below the confidence threshold, several transactions fall into the uncertain zone and should trigger a softer intervention rather than an automatic decision. These are the genuinely uncertain cases that a rules-based system would have decided silently.

Latency

One Jev call per transaction, completing in well under a second each. At this latency, a production fraud detection system could assess transactions in real time before they complete, with enough headroom to trigger step-up authentication and wait for the customer’s response before the payment times out.

The Three-Tier Response

The confidence score enables a more nuanced response than binary flag-or-pass:

• High confidence Flag (above the threshold): route to fraud queue, hold transaction
• High confidence Pass (above the threshold): approve and process
• Low confidence (below the threshold): trigger step-up authentication, let the customer confirm

The threshold is a business decision, not a technical one. The right number depends on the cost of a false positive (a blocked legitimate customer) versus a false negative (a passed fraudulent transaction) in your specific context. What Jev provides is the infrastructure to make that trade-off explicit and tunable, rather than baking it invisibly into a set of rules.

Chapter 4: Content Moderation

The Problem

Platforms that host user-generated content face a decision for every post, comment and review: approve it, flag it for human review or remove it immediately. Get it wrong in either direction and the consequences are real. Miss a genuine threat and someone gets hurt. Remove legitimate content and you’ve silenced a user, damaged trust and potentially exposed the platform to legal challenge.

Rules-based moderation – keyword blocklists, regex patterns, account age thresholds – is fast but brittle. It misses context, catches satire and fails on novel patterns. Human moderation is accurate but doesn’t scale.

This chapter uses Jev to make a three-option decision for each piece of content: approve it, flag it for human review, or remove it. The three-option structure is deliberate. A binary approve/remove decision forces a choice that shouldn’t always be forced. The “Flag” option is where genuine uncertainty belongs – and a calibrated confidence score tells you how uncertain Jev actually is about each decision.

The Setup

We generate 20 posts across four bands, each carrying the content itself plus account signals and platform context that a real moderation system would have:

• Clear violation (5 posts): direct threats, spam with malicious links, hate speech, extortion
• Clear acceptable (5 posts): product reviews, technical questions, general discussion, support requests
• Ambiguous (5 posts): frustrated venting, strong political opinion, an angry product review, dark humor
• Edge cases (5 posts): satire that could be misread, a professional asking an unusual question, an angry cancellation request, a strong but legitimate political opinion

Each post carries five signals: platform (Social Media, Community Forum, Product Reviews, Customer Support), account age, prior violation count, verified status and the post content itself.

One Decision per Post

One Choice call per post, three options: Approve, Flag or Remove.

response = client.system_one(
    state={
        "platform":         post["platform"],
        "account_age_days": post["account_age_days"],
        "prior_violations": post["prior_violations"],
        "verified_account": post["verified"],
        "content":          post["content"],
    },
    questions={
        "decision": Choice(
            instructions=(
                "Based on the content and account context, what moderation "
                "decision should be applied?"
            ),
            criteria=MODERATION_DECISION,
        )
    },
)

Results

What the Numbers Tell Us

Perfect at the extremes

All five clear violations were removed at maximum confidence. All five clear acceptable posts were approved at maximum confidence. No hesitation in either direction. The model has a strong, consistent signal at the extremes of the spectrum.

Jev prefers binary decisions

The most notable finding is how rarely the Flag option was used. Across 10 ambiguous and edge case posts, Flag appeared exactly once – P014, the angry product review threatening reputation damage. Jev leaned heavily toward Approve across the middle bands.

This tells us something important about how Jev handles a three-option choice: it doesn’t naturally distribute decisions across all three options. It tends toward confident binary decisions and the confidence score is where the uncertainty actually surfaces rather than the choice of the middle option. The posts that fell below the confidence threshold are all approved or flagged decisions Jev wasn’t sure about. Those low-confidence signals are more useful than the Flag option itself.

The three posts worth reviewing

P012 (strong political opinion about government failures): legitimate political expression but heated enough to give Jev pause. Low confidence signals “probably fine but worth a look.”

P014 (angry product review calling the company “criminals” and threatening to damage their reputation): the one post Jev flagged. It’s genuinely borderline – the language is aggressive but the underlying complaint is a legitimate consumer grievance. Jev got this right by flagging rather than removing.

P018 (customer threatening chargebacks and negative reviews unless their issue is resolved): on a customer support platform this reads as a frustrated customer at the end of their patience, not a bad actor. Low confidence is exactly the honest signal here.

Platform confidence

Customer Support had the lowest mean confidence, driven by P018. Social Media had the highest, because it contained the clearest examples at both extremes. Community Forum and Product Reviews sat in the middle. The platform context influenced decisions at the margins – the same angry language reads differently on a customer support channel than on social media.

Decision distribution

The Flag option was used once and with low confidence. In practice, the low-confidence Approve decisions are functionally equivalent to flags – they should join the human review queue regardless of which option Jev chose.

Latency

One Jev call per post, completing in well under a second each. Twenty posts processed in well under a minute.

The Practical Takeaway

The three-option structure is correct in theory but the confidence score is the more reliable signal in practice. Rather than routing purely on the decision (Approve / Flag / Remove), a production moderation system should route on decision and confidence together:

• Remove above the confidence threshold: remove immediately
• Approve above the confidence threshold: publish immediately
• Anything below the confidence threshold, regardless of decision: route to human review

This reframes Flag not as a specific outcome but as a proxy for “confidence below threshold” – and the confidence score makes that threshold explicit and tunable.

Chapter 5: Supply Chain Disruption Response

The Problem

A disruption hits your primary supplier. A port strike, a factory fire, an export restriction, a quality recall. You have alternative suppliers, but choosing the right one under pressure requires weighing multiple factors simultaneously: lead time, reliability, current capacity, cost and geographic risk. Get it wrong and production stalls. Get it right and nobody notices.

Rules-based fallback logic – activate Supplier B if Supplier A is down – works for simple scenarios. It breaks when the alternatives themselves are partially compromised, when you need to weigh trade-offs between cost and speed or when the disruption affects an entire region and your fallback suppliers share the same risk.

This chapter uses Jev to select the best available alternative supplier when a primary supplier is disrupted. One Choice call per disruption scenario, with the full current state of each alternative supplier in the criteria. The confidence score indicates how certain Jev is about its choice, which may not correspond to how difficult the supplier situation appears from the outside.

The Setup

We model Vantara Devices, a fictional consumer electronics manufacturer sourcing five key components: display panels, batteries, processors, casings and cables. Each component has a primary supplier and two or three alternatives. Every supplier carries five attributes: reliability score, lead time, available capacity, cost index relative to the primary and geographic region.

Five disruption scenarios cover a range of difficulty:

• S001 Display Panels: port strike affecting all East Asia shipments – two of three alternatives share the disrupted region
• S002 Batteries: factory fire – clear trade-off between a faster but lower-capacity alternative and a slower but higher-capacity one
• S003 Processors: export restrictions on East Asia semiconductors – one of three alternatives is also in the restricted region
• S004 Casings: quality recall – two alternatives with different speed and cost profiles
• S005 Cables: logistics failure – all three alternatives have a meaningful weakness, no clean winner

One Decision per Scenario

Each scenario produces one Choice call. The disruption goes into the state; each alternative supplier becomes a criterion described in plain language.

criteria = {
    name: describe_supplier(name, attrs)
    for name, attrs in alternatives.items()
}

response = client.system_one(
    state={
        "component":        component,
        "primary_supplier": primary["name"],
        "disruption":       disruption,
        "priority":         "Minimise production delay while managing cost and risk.",
    },
    questions={
        "supplier": Choice(
            instructions=(
                "Which alternative supplier should we activate for this component "
                "given the disruption and the current state of each alternative?"
            ),
            criteria=criteria,
        )
    },
)

Results

What the Numbers Tell Us

S001: Display Panels – regional risk handled correctly

Jev chose VisionParts Europe – the only alternative outside the disrupted East Asia region – over two East Asian alternatives that were cheaper and faster. That’s the right call: activating a supplier in the same region as the disruption simply moves the problem rather than solving it. The low confidence reflects the real cost of that decision: VisionParts is slower, less reliable and meaningfully more expensive. It’s the right choice but not a comfortable one.

S002: Batteries – speed over capacity

Jev chose EnergyPack USA over VoltSource Japan, prioritising lead time over reliability and available capacity. The moderate confidence reflects a genuine trade-off – the faster supplier has lower capacity and higher cost. Whether speed or capacity matters more depends on inventory levels and production schedules, context that wasn’t in the state. The confidence score signals that this is a reasonable but not obvious call.

S003: Processors – the clearest decision

Once NexChip South Korea is excluded due to the export restrictions, SiliconWave USA is the clear choice over MicroLogic Europe: higher reliability, shorter lead time, lower cost. MicroLogic has more available capacity but loses on every other dimension. High confidence is correct – this isn’t close.

S004: Casings – a surprising choice

Jev chose FrameWorks Poland over ShellCraft Mexico despite Mexico being faster, cheaper and at near-full capacity. The deciding factor appears to have been reliability score, where Poland has a slight edge. The low confidence is the honest signal here: most supply chain managers would probably choose Mexico, and Jev’s slight preference for Poland isn’t strongly supported by the data. This is exactly the decision that should go to a human review before activation.

S005: Cables – speed wins when everything is compromised

With all three alternatives having meaningful weaknesses, Jev chose CableCo USA: the fastest option with the highest reliability, but limited capacity and the highest cost. It apparently weighted speed and reliability above capacity and cost, which is a defensible priority when production is stalled. Confidence was higher than expected for an “all compromised” scenario – Jev had a clear opinion about which trade-off mattered most.

The confidence scores didn’t track our expected difficulty

Our band labels reflected our expectations: clear alternatives should produce high confidence, all-compromised scenarios should produce low confidence. The actual results inverted this – the all-compromised cables scenario produced the highest confidence while the clear-alternative casings scenario produced the lowest.

The explanation is that our labels described the supply network structure, not how Jev experienced the decision. When Jev has a strong opinion about which factor matters most – speed for cables, regional safety for display panels – it acts on that opinion confidently even when the network situation looks objectively harder. When the factors are genuinely balanced – casings, where the two alternatives are close on almost everything – the confidence drops regardless of how the scenario was labeled.

This is a useful calibration: confidence reflects Jev’s internal certainty about the decision, not the objective difficulty of the problem.

Latency

One Jev call per scenario, completing in well under a second each. In a production supply chain system, these decisions would typically be made under time pressure but not in real time – a disruption notification triggers an assessment within seconds rather than within milliseconds. The latency is well within any practical response window.

Chapter 6: Hiring Screening

Important Disclaimer

This chapter is illustrative only. Jev is assessing structured summaries against structured requirements – it is not making final hiring decisions and should not be used as one. Any real implementation of AI-assisted hiring screening requires human oversight, regular bias auditing and compliance with applicable employment law. The candidates and job description in this chapter are entirely fictional.

The Problem

Recruiting teams face a familiar bottleneck: a role opens, applications arrive faster than anyone can read them and the risk of a bad screen in either direction is real. Miss a strong candidate and they accept another offer. Advance a poor fit and you waste an interviewer’s time and the candidate’s.

Rules-based screening – keyword matching on required skills, minimum years of experience, degree requirements – is fast but crude. It filters on the presence of words rather than the quality of fit. A candidate who writes “built distributed systems” passes; one who writes “designed and shipped a high-throughput event pipeline” might not, even if the latter is the stronger hire.

This chapter uses Jev to make a three-option screening decision for each candidate: advance them to interview, flag them for human review, or decline. One Choice call per candidate, structured CV summary against structured job requirements, a calibrated confidence score that tells you how certain the decision is.

The Setup

One job description – Senior Backend Engineer, Platform Engineering – and 20 candidate CV summaries across four bands:

• Strong match (5 candidates): clearly meets all requirements – right experience, right stack, right seniority
• Clear mismatch (5 candidates): clearly doesn’t meet requirements – wrong field, too junior, missing core skills
• Borderline (5 candidates): partially meets requirements – right stack but too junior, right seniority but wrong stack, adjacent field
• Edge cases (5 candidates): unusual profiles that a keyword filter would handle badly – overqualified, employment gap, vague CV with strong GitHub, recent stack mismatch, career changer without a CS degree

One Decision per Candidate

One Choice call per candidate. The job requirements go into the state alongside the candidate’s structured CV summary.

response = client.system_one(
    state={
        "role_title":        job["title"],
        "seniority_level":   job["level"],
        "required_skills":   job["required_skills"],
        "preferred_skills":  job["preferred_skills"],
        "not_suitable_if":   job["not_suitable"],
        "candidate_summary": candidate["summary"],
        "years_experience":  candidate["years_experience"],
        "current_title":     candidate["current_title"],
    },
    questions={
        "decision": Choice(
            instructions=(
                "Based on the candidate's experience and the role requirements, "
                "should this candidate be advanced to interview, flagged for "
                "human review, or declined?"
            ),
            criteria=SCREENING_DECISION,
        )
    },
)

Results

What the Numbers Tell Us

Review used as a genuine middle ground

Unlike the content moderation chapter where Flag appeared just once, Review appeared seven times – across three borderline candidates and four edge cases. Hiring decisions are inherently more nuanced than content moderation and Jev reflects that: it used the middle option where the middle option was warranted.

The decision distribution shows a clean pattern: Advance for the five strong matches, Decline for the five clear mismatches and a genuine spread of Review and Decline across the harder cases. Mean confidence by decision tells the right story too – Advance and Decline are more confident decisions than Review, which sits in the middle as it should.

Confidence drops with difficulty

Mean confidence fell steadily from clear mismatch (highest – these decisions are easy) through strong match (very high – all five advanced with high certainty) to borderline and edge cases (lower – genuinely harder calls). Clear mismatch being the most confident band makes intuitive sense: it’s easier to be certain someone doesn’t qualify than to be certain they do.

The most interesting individual results

C005 (Chris Nakamura): the only strong match below maximum confidence. Five years is exactly at the minimum threshold and the CV notes no Kafka experience. Jev advanced him but with slightly lower confidence than the stronger candidates. That’s an honest signal.

C012 (Avery Santos): a Java engineer with seven years of experience and strong distributed systems background – but no Python or Go. The lowest confidence in the borderline band. Genuinely the hardest call: experience level and systems depth are right, but the stack mismatch is real.

C015 (Drew Hassan): sole backend engineer at a startup for five years – strong ownership signals but no peer review, team collaboration or mentoring context. Jev put this in Review with high confidence, correctly identifying that human judgment is needed rather than an automatic advance or decline.

C016 (Frankie Diaz): overqualified Principal Engineer with twelve years of experience applying for a Senior role. Jev didn’t advance or decline – correctly flagged this as a situation requiring human judgment. Is this a deliberate step back? A management-to-IC transition? Those questions need a conversation.

C018 (Blair Kim): vague CV language with strong GitHub contributions suggesting better skills than the CV conveys. Jev flagged this for human review with very high confidence – one of the highest-confidence Review decisions in the dataset. It correctly identified that the signals are contradictory and a human needs to look further.

C019 (Robin Castillo): seven years experience but the most recent three years in PHP at a web agency. Jev declined with moderate confidence – acknowledging the earlier Python experience but deciding the recent stack distance was too significant. Lower confidence than the clear mismatch declines, which is appropriate.

C020 (Sage Thompson): career changer with no CS degree, self-taught, six years of shipped backend work. Jev put this in Review rather than declining, which is the right call – non-traditional backgrounds deserve human assessment rather than automatic rejection.

Latency

One Jev call per candidate, completing in well under a second each. Twenty candidates screened in well under a minute.

The Right Architecture

Jev screening handles the easy cases automatically and surfaces the hard ones. High-confidence Advance decisions move straight to interview scheduling. High-confidence Decline decisions move straight to a rejection. Everything below the confidence threshold – and everything in Review regardless of confidence – goes to a human recruiter.

This is not a replacement for human judgment. It’s a way to ensure that human judgment is applied where it matters most, rather than being consumed by decisions that are objectively straightforward.

Chapter 7: Medical Symptom Triage

⚠ Critical Disclaimer

This chapter is for illustrative and educational purposes only.

The presentations, decisions and confidence scores in this chapter are fictional. Jev is not a medical device, has not been clinically validated and must not be used to make or influence real healthcare decisions.

If you or someone else is experiencing a medical emergency, call the emergency services immediately.

Any real application of AI in clinical triage requires regulatory approval, clinical validation, human oversight and clear accountability for every decision. Nothing in this chapter should be interpreted as guidance for real-world medical use.

The Problem

A patient contacts a healthcare service. They describe their symptoms. Someone – or something – has to decide how urgently they need to be seen.

Traditional triage uses structured protocols: numerical scores, decision trees, trained clinicians working through standardized questions. These work well but require skilled human time. At scale – a busy out-of-hours service, a telehealth platform handling thousands of daily contacts – the bottleneck is always clinical capacity.

This chapter uses Jev to assign each patient presentation to one of four care pathways: Emergency, Urgent Care, Routine or Self-Care. One Choice call per presentation, patient symptoms and context in the state, calibrated confidence alongside the decision.

The goal is not to replace clinical triage. It is to illustrate where confidence-scored structured decisions can help: routing clear cases quickly and flagging uncertain ones for human review.

The Setup

We generate 20 fictional patient presentations across four bands. Each carries the reported symptoms, patient age, sex, relevant medical history and symptom duration.

The four pathways reflect standard triage levels:

• Emergency: potentially life-threatening, call emergency services immediately
• Urgent Care: needs clinical assessment within hours
• Routine: warrants clinical review but not urgent, GP appointment within days
• Self-Care: minor, can be managed at home

The triage instructions include a conservative bias: when in doubt, assign the more urgent pathway. In medical triage, the cost of under-triaging a serious condition is far higher than the cost of over-triaging a minor one.

One Decision per Presentation

One Choice call per presentation. All available patient context goes into the state.

response = client.system_one(
    state={
        "patient_age":       presentation["age"],
        "patient_sex":       presentation["sex"],
        "medical_history":   presentation["medical_history"],
        "reported_symptoms": presentation["symptoms"],
        "symptom_duration":  presentation["duration"],
    },
    questions={
        "pathway": Choice(
            instructions=(
                "Based on the reported symptoms, patient age, medical history "
                "and symptom duration, which care pathway is most appropriate? "
                "When in doubt, assign the more urgent pathway."
            ),
            criteria=CARE_PATHWAYS,
        )
    },
)

Results

What the Numbers Tell Us

Clean at the extremes

All five clear self-care presentations were correctly assigned to Self-Care with high confidence. Four of the five clear emergencies were correctly assigned to Emergency at maximum confidence. The fifth is the most interesting result of the chapter.

P005: haemoptysis – the one debatable clear emergency

P005, a 45-year-old male smoker who has coughed up blood for the first time after a three-week cough, was assigned to Urgent Care rather than Emergency – with very low confidence. Coughing up blood in a long-term smoker is a serious red flag warranting urgent investigation, but it isn’t immediately life-threatening in the way a heart attack or stroke is. The low confidence reflects genuine clinical uncertainty about whether this requires an ambulance right now or an urgent same-day appointment. Arguable either way and the low confidence correctly signals this for human review.

Conservative bias working as intended

The instruction to “assign the more urgent pathway when in doubt” is visible in the edge case results. Three edge case presentations were assigned Emergency:

P016 (82-year-old on blood thinners who has fallen): even without a head injury, the blood thinner history and age significantly elevate the risk of internal bleeding from what might otherwise look like a minor fall.

P019 (25-year-old with panic attack history, symptoms overlap with cardiac and respiratory emergency): the prior diagnosis points toward a panic attack, but the symptoms are indistinguishable from a cardiac event without clinical assessment. Jev assigned Emergency with moderate confidence – defensible given the instruction.

P020 (55-year-old hypertensive with new blurry vision): sudden visual changes in a hypertensive patient could indicate a hypertensive emergency or a transient ischaemic attack. The conservative bias pushed this to Emergency.

P017: the most concerning result

The 7-year-old with a 39.2C fever for 24 hours was assigned Self-Care – with the lowest confidence of any result in the dataset. In most paediatric triage protocols, a persistent fever at that temperature in a child would warrant at minimum a Routine appointment and more commonly Urgent Care. The very low confidence is the correct signal: this decision should not stand without clinical review.

Confidence tracks uncertainty correctly

Mean confidence by band drops steadily from clear self-care (highest) through clear emergency to ambiguous and edge cases (lowest). Emergency and Self-Care are the high-confidence pathways – Jev is more certain at both ends of the urgency spectrum than in the middle. Urgent Care and Routine sit at lower mean confidence, reflecting that these are the genuinely harder calls.

Latency

One Jev call per presentation, completing in well under a second each. Twenty presentations triaged in well under a minute.

The Right Architecture

In a real system, every decision would be reviewed by a qualified clinician before any action is taken. The confidence score determines the priority of that review: high-confidence decisions can be processed quickly, low-confidence decisions need immediate human attention.

The value Jev adds is not replacing clinical judgment – it is making the uncertain cases visible. A call handler working through a hundred contacts can’t give equal attention to all of them. A confidence score flags the presentations where attention matters most.

Reminder: this chapter is for illustrative purposes only. Never use Jev or any AI system as a substitute for clinical judgment.

Conclusions

Seven domains. Seven notebooks. The same pattern every time: structured state in, typed decision out, confidence score alongside.

Looking across all seven chapters, a few things stand out.

The confidence score is the real output

The decision – Flag or Pass, Advance or Decline, Emergency or Self-Care – is what gets acted on. But the confidence score is what makes the system trustworthy.

In every chapter, the most interesting results weren’t the high-confidence ones. They were the low-confidence ones: the electronics purchase that Jev passed at near-zero confidence, the child with a fever assigned Self-Care at the lowest confidence in the dataset, the billing-or-technical ticket that Jev couldn’t decide who owned. These are the decisions that should never be automatic and the confidence score identifies them without any additional logic.

A binary classifier gives you a decision. Jev gives you a decision and a signal about how much to trust it. That second thing is what makes the difference between a system that routes automatically and one that routes intelligently.

The middle option behaves differently across domains

Three chapters used three-option choices. The results were different in each.

In content moderation, Flag appeared once across twenty posts. Jev leaned binary and the confidence score did the work that Flag was supposed to do – the low-confidence Approve decisions were functionally flags, just expressed differently.

In hiring screening, Review appeared seven times. The middle option worked as intended: a genuine holding zone for candidates who needed human judgment rather than an automatic decision.

In medical triage, four pathways produced a spread across all of them, but with the conservative bias pushing toward the more urgent option when Jev was uncertain. The pathway was less important than the confidence – a low-confidence Emergency assignment tells you something different from a high-confidence one.

The lesson isn’t that three options are always better than two, or that they’re always worse. It’s that the middle option’s utility depends on the domain. In some domains, genuine uncertainty has a natural home in the middle. In others, uncertainty shows up in the confidence score of a binary decision instead.

Confidence reflects internal certainty, not objective difficulty

The supply chain chapter showed this most clearly. The scenario designed to be hardest – all three cable suppliers compromised, no clean winner – produced the highest confidence. The scenario designed to be easiest – two casings suppliers with clear profiles – produced the lowest.

The explanation is that Jev had a strong opinion about which factor mattered most in the cables scenario (speed) and acted on that opinion confidently. In the casings scenario, the two alternatives were close on almost everything and Jev genuinely couldn’t separate them.

This pattern appeared in every chapter. The confidence score doesn’t measure how hard the problem is. It measures how certain Jev is about its answer. Those two things correlate – harder problems tend to produce lower confidence – but they’re not the same and the medical triage chapter shows what happens when they diverge: Jev assigned a child’s fever to Self-Care at very low confidence, correctly signalling that a human needed to review that decision even though the symptoms were objectively mild.

The threshold is always a business decision

Every chapter ends with the same observation in a different form. The confidence threshold that separates automatic decisions from human review isn’t something Jev sets. It’s something you set, based on the cost of errors in your specific context.

For fraud detection: the cost of a false positive (blocking a legitimate customer) versus a false negative (passing a fraudulent transaction) sets your threshold. For medical triage: the cost of under-triaging a serious condition versus over-triaging a minor one. For hiring: the cost of missing a strong candidate versus advancing a poor fit.

Jev gives you the infrastructure to make that trade-off explicit. The threshold is your policy, not Jev’s.

Where Jev works best

Chapter 1 is the one chapter that starts by using Jev the wrong way. The sequential pathfinding experiment – asking Jev to navigate a network hop by hop, making a dependent chain of decisions – produced inconsistent routes and failed to respond to live disruption information. Not because Jev is a weak model, but because that’s not the shape of problem it was built for.

The branch triage experiment in the same chapter shows the right shape: one decision, clear options, rich structured state. That’s the pattern that worked across all seven domains. A well-scoped question with named options and enough context to answer it – that’s where Jev earns its place.

The seven chapters in this book are a range of examples. The underlying pattern is always the same.

Free Books

The SingleStore Cookbook: Recipes for Multi-Model, Machine Learning and AI Data Engineering

Read Online ↗

A hands-on cookbook covering SingleStore’s multi-model capabilities, from time series and geospatial data through vector search, machine learning pipelines and AI-powered applications. The recipes draw on first-hand experience building applications with the platform and are organized into four parts:

1. Multi-Model
2. Streaming and Big Data Pipelines
3. Machine Learning
4. AI and Agentic Frameworks

Seven Vector Databases in Seven Days

Read Online ↗

A practical guide that takes one vector database per day and pairs each with a use case chosen to showcase that database’s strengths. Databases covered:

1. PostgreSQL and pgvector - Semantic job search
2. MongoDB Atlas - Recipe finder
3. Pinecone - E-commerce search
4. Weaviate - Research paper discovery
5. Neo4j - Fraud detection
6. Snowflake - Customer support analytics
7. Databricks - RAG over internal documents

Each chapter is self-contained, comes with a Jupyter notebook and gives an assessment of when you’d look elsewhere.

Generative AI: A Manager’s Guide

Read Online ↗

A practical guide for managers, directors and executives who need to make decisions about AI in their organizations, not the engineers building it, but the people responsible for making it work well. The book uses a single central metaphor, the Digital Intern, to frame what AI is genuinely good at, where it falls short and what managing it actually requires. It covers governance, risk, board-level accountability, business case building and the organizational change of moving from pilot to embedded capability.

Seven Ways to Do Vector Search in Python

Read Online ↗

A practitioner’s guide that benchmarks seven Python libraries against the same dataset, measuring recall and latency consistently so you can compare like-for-like. Libraries covered:

1. FAISS
2. Voyager
3. Scikit-learn NearestNeighbors
4. PyNNDescent
5. USearch
6. Chroma
7. LanceDB

Each chapter covers one library, explains what it’s genuinely good at and when you’d reach for something else.

Real-Time Vehicle Tracking with Neo4j, Databricks Lakebase and OpenStreetMap

Read Online ↗

A fleet operations demo that puts ten simulated vehicles onto real road networks loaded from OpenStreetMap. The architecture:

• Neo4j Aura holds the road network graph
• Databricks Lakebase stores live vehicle positions
• Databricks Lakehouse handles historical analytics

Two Streamlit dashboards display live positions and trend data. The primary demo uses the London Borough of Merton, with additional configurations for San Francisco and Singapore.

Real-Time Supply Chain Routing with Neo4j, Snowflake Postgres and Confluent Kafka

Read Online ↗

A supply chain routing demo that combines graph-based route optimization with real-time event streaming. The architecture:

• Neo4j Aura holds the supplier and logistics network graph
• Snowflake Postgres stores product and inventory data
• Confluent Kafka streams supply chain events in real time

Route queries traverse the graph to find optimal paths between suppliers, warehouses and distribution centers under live capacity and disruption constraints.

Neo4j Beyond the Graph

Read Online ↗

A hands-on guide to Neo4j’s multi-model capabilities, going beyond graph traversal to explore seven native features of the platform. Each chapter pairs one capability with a use case chosen to showcase it:

1. Native Graph - London Underground routing
2. Full-Text Search - Research paper discovery
3. Geospatial - Air quality along the Pyrenees corridor
4. Temporal - S&P 500 stock price analysis
5. Document-Style Properties - Library inventory management
6. Vector Search - Fashion image similarity
7. Graph + Vector - Fraud ring detection

Every chapter comes with a Jupyter notebook and a Streamlit application. All examples run on Neo4j Aura’s free tier.

Seven Ways to Use Jev

Read Online ↗

A practical guide to TypeSafe AI’s structured decision model, exploring seven domains where a single Choice call – structured state in, typed decision out, calibrated confidence alongside – replaces brittle rules-based logic. Each chapter pairs one domain with a hands-on Jupyter notebook and examines what the confidence score reveals about the decision:

1. Transit Routing - Northern Line branch triage using a NetworkX graph
2. Customer Support Triage - Ticket routing by team and priority
3. Financial Fraud Detection - Flag or pass with a three-tier confidence response
4. Content Moderation - Approve, flag or remove user-generated content
5. Supply Chain Disruption - Alternative supplier selection under live constraints
6. Hiring Screening - CV screening against a structured job description
7. Medical Symptom Triage - Care pathway assignment with a conservative bias

A recurring theme across all seven chapters: the confidence score is more informative than the decision itself for uncertain cases and the threshold between automatic routing and human review is always a business decision, not a technical one.

Lessons Learned Putting Jev Inside Neo4j

Read Online ↗

A hands-on account of building a Neo4j function and batch procedure in Java that ask a model to make a decision about a node and store the answer back in the graph. The book follows one running example, 500 synthetic transactions and each chapter adds the code that the previous chapter’s problem called for. The lessons:

1. Why in the Database - Where a decision belongs and what the finished function returns
2. A First Working Function - Converting Neo4j’s types on the way in and out
3. Failures as Data - Returning errors as values so one bad node can’t stop a query
4. Testing Without a Network - Seams for the network and the clock, with 68 fast tests
5. Keeping the Key Safe - Sending a credential only to the host the parser reports
6. Many at Once - A bounded, ordered pool and a measured concurrency sweep
7. Running It Locally - Swapping in a small local model and seeing how the judgment changes

Every chapter with code has its own folder in the repository and each Cypher script also comes as a notebook, so you can use whichever you prefer. The results are reported as measured, including the ones we can’t explain!