# Jev 1.13 jaggedness: 9 failure modes and what to do instead

> Jev 1.13 is fast and calibrated but literal: 9 known jagged edges from TypeSafe docs — counting, dates, indirection, large state — and the code-first fixes that avoid them.

*Source: https://velstech.net/jev-1-13-jaggedness · Updated: 2026-09-20 · Category: AI · Tags: TypeSafe, Jev, LLM, Prompting*

*Markdown version of [Jev 1.13 jaggedness: 9 failure modes and what to do instead](https://velstech.net/jev-1-13-jaggedness). [Read the full guide with interactive tools](https://velstech.net/jev-1-13-jaggedness).*
*Also as Markdown: [Hindi](https://velstech.net/jev-1-13-jaggedness.hi.md) · [Tamil](https://velstech.net/jev-1-13-jaggedness.ta.md).*

---

**Jev 1.13** (`jev-1.13`) is TypeSafe's fast, calibrated
judgment model – best at *System One* tasks: quick yes/no
(`Noul`) and pick-one (`Choice`) decisions over text you hand it.
It is not a calculator, not a date parser, and not a text generator. TypeSafe's own
[model-jaggedness page for jev-1.13](https://docs.typesafe.ai/model-jaggedness/jev-1.13)
(last reviewed 2026-09-17) lists nine places where it stays sharp and where it goes
jagged. This guide summarises those nine with the practical fix for each, so you stop
asking the model to do what belongs in code.

The one-line rule: **give Jev the judgment, keep the math in code.**
Extraction is a judgment – hand it over. Counting, comparing dates, enforcing that
"yes" and "not yes" add to one – that is code's job.

## The 9 failure modes at a glance

| # | Failure mode | Do this instead |
| --- | --- | --- |
| 1 | Literal reading | Write the exact condition and boundary cases |
| 2 | Math and numbers | Count and compute in code |
| 3 | Date and time comparison | Extract parts with the model, compare in code |
| 4 | Indirection | Reduce hops, point at the relevant state |
| 5 | Large state, lots of irrelevance | Filter first, send only what the question needs |
| 6 | Adversarial content | Precise criteria + edge-case tests before deploy |
| 7 | Contradictory instructions and criteria | Align instruction and criteria wording |
| 8 | Common-sense structural invariants | Ask each decision one way; enforce identities in code |
| 9 | Generation | Use a generative model; let Jev pick, not write |

Source: TypeSafe docs, [Jev 1.13 jaggedness](https://docs.typesafe.ai/model-jaggedness/jev-1.13).
Details below are my summary with added examples.

## 1. Literal reading

Jev answers the question you wrote, not the one you meant. Scoping words, negations,
and implied conditions are read at face value. A human hears intent; Jev reads text.
Whenever you catch yourself explaining "what I really meant" after a wrong answer,
that explanation was the missing half of your instruction.

**Fix:** state the exact condition in `instructions`, spell out
boundary cases in the criteria, and when interpretation is unavoidable, split one fuzzy
question into two literal questions and combine the answers in code.

## 2. Math and numbers – Jev is not a calculator

Three related traps: **counting** (characters, term occurrences, list items –
error grows with size), **numeric representations** (hex colours, RGB triples,
assembly or binary read worse than names and high-level code), and
**score interpolation** (you can threshold an expectation, but do not
interpolate between score levels to reconstruct an exact number – calibration is weak there).

**Fix:** if a regex or parser can find the unit, count in code. Ask one
yes/no per candidate, then sum yourself:

```
from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient(model="jev-1.13")
YES = 0.5  # threshold depends on your use case

items = ["typesafe", "apple", "california", "banana",
         "likes", "calibration", "orange", "vertex"]

result = client.system_one(
    {"items": items},
    {f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?")
     for i in range(len(items))},
)
count = sum(result.nouls[f"item_{i}"].noul > YES for i in range(len(items)))
```

Same idea for colours and code: convert in code to a number or a named bucket first,
and reserve the model for the genuine judgment (for example, whether a colour reads as a warning).

## 3. Date and time comparison

Jev reads dates as text, not ordered quantities. "Which date comes first?", "how far
apart?", "inside this window?" – unreliable, and worse with mixed formats, relative
references ("next Friday"), and domain boundaries like quarters or settlement windows.

**Fix:** split the work. Extraction is a judgment, so model each part
(year, month, day) as a `Choice` over a small closed set with an explicit
"not stated" option – then assemble a real date in code and let code own ordering,
duration, offsets, and weekdays. TypeSafe's date-extraction cookbook has the worked version.

## 4. Indirection

Double negatives and multi-hop questions ("a property of a property") cost accuracy.
Every extra hop of reasoning is a chance to drift.

**Fix:** write instructions as directly as possible and name the relevant
slice of state explicitly instead of making the model chase pointers.

## 5. Large state full of irrelevant detail

Accuracy falls as unrelated content grows – distractors drown the signal, and debugging
("which input caused this?") gets harder. Jev also has a bounded context window (see the
TypeSafe Models page for exact token limits), and unrelated material costs accuracy
well before you hit the wall – what practitioners call context rot.

**Fix:** retrieve and filter in code first; send only the fields the question
needs. When filtering up front is impossible, use a `Noul` as a relevance gate
(TypeSafe's classifying-RAG-passages cookbook shows the pattern).

## 6. Adversarial content

State is data, and Jev does not treat it as hostile by default. Injected instructions,
misleading framing, or text that argues for its own classification can move the answer.

**Fix:** be explicit in the criteria about what counts, and test edge cases
thoroughly before rolling out to many users. TypeSafe says hardening here is on the roadmap.

## 7. Contradictory instructions and criteria

When `instructions` and `criteria` pull in different directions –
the classic example is a `Noul` where `true` is worded as "no" and
`false` as "yes" – performance drops. Aim for phrasing an average person reads
once and gets right.

**Fix:** treat criteria as an extension of the instruction and align the two
in plain, precise language.

## 8. Common-sense structural invariants that do not hold

Jev is very consistent on similar inputs, but separate questions do not obey arithmetic
identities. Two documented examples from TypeSafe:

- Same refund question as a Noul (0.22) vs a yes/no Choice
(yes 0.01 / no 0.99, confidence 0.97) – the comparable numbers do not line up the way you would expect.

- A question and its negation as two Nouls scoring 0.72 and 0.47 – summing to 1.19, not 1.0.

A `Choice` is relative (which option?), while each `Noul` is absolute
(is this one true?) – all `Nouls` can be low at once. Do not carry a threshold
tuned on one primitive over to the other.

**Fix:** word each question to mean directly what you want, and enforce
identities in code. The skill-suggestion cookbook pattern is the template: a
`Choice` to pick the skill, `Nouls` to decide whether to suggest one at all.

## 9. Generation – do not make Jev write prose

Jev is not trained to generate text. Chaining choices to force generation is slow and bad.
For extraction, pull candidate spans with regex or a generative model first.

**Fix:** when the answer space is bounded, turn extraction into a
`Choice` over the options. If you genuinely need open-ended text, use a
generative model for that part.

## Checklist before you ship

- Never ask the model something code can compute exactly.

- Never hide several judgments inside one question – split them.

- System Two tasks (layers of indirection) do not belong on a System One model.

- Never send more state than the question needs.

## Bottom line

Jev 1.13 earns its speed on short, literal, well-scoped judgments with small, relevant
state. Everything on the jagged list is the same mistake in different clothes: asking a
judgment model to be a calculator, a calendar, a filter, or a writer. Push the exact
parts into code, keep Jev on the semantic decision, and the "jaggedness" mostly disappears.
Full source: [docs.typesafe.ai/model-jaggedness/jev-1.13](https://docs.typesafe.ai/model-jaggedness/jev-1.13).

## FAQ

**What is Jev 1.13 jaggedness?**

The nine documented failure modes of TypeSafe's jev-1.13 judgment model (literal reading, math, dates, indirection, large state, adversarial content, contradictory criteria, structural invariants, generation) — places where a fast System One model gives unreliable answers.

**Can Jev 1.13 count or compare dates?**

Not reliably. Count in code (one yes/no per candidate, then sum), and split dates: let the model extract year/month/day as Choices, then compare and order with real date code.

**Should Jev 1.13 generate text?**

No. It is a judgment model (Noul/Choice), not a generator. Extract candidates with regex or a generative model, then let Jev pick the right one.

---

*VelsTech – technology explained for everyone. Original: https://velstech.net/jev-1-13-jaggedness*