# Jev 1.14's Bounding Box Has No 'Not Found'

**Summary:** Jev 1.14 adds experimental image localization, but its Box type returns coordinates even for an absent object. I would require a separate presence check and test missing targets before letting a crop drive automation.

- Canonical: https://markhuang.ai/news/jev-1-14-bounding-box-no-not-found
- Language: en
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-10-14
- Section: News
- Tags: Jev 1.14, TypeSafe AI, Computer Vision, Bounding Boxes, AI Reliability
- Source: [TypeSafe AI](https://typesafe.ai/blog/jev-1-14)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![An illuminated rectangular frame selects an empty patch of table while a blue mug sits outside it](https://cdn.markhuang.ai/news/jev-1-14-bounding-box-no-not-found/hero.webp)

*Conceptual illustration: a precise rectangle can frame empty space. Jev's new Box type leaves the presence check to a separate question.*

[TypeSafe's Jev 1.14 release](https://typesafe.ai/blog/jev-1-14) adds experimental image support, a bounding-box type, and longer context alongside what the company describes as smaller model improvements. Its [model documentation](https://docs.typesafe.ai/models) dates Jev 1.14's availability to October 14, 2026. The detail that caught my attention is in the Box documentation: ask for an object that is absent, and the model still returns a rectangle.

I like this extension of Jev's typed-decision approach, but it gives the application another mistake to catch. Software can consume a guaranteed shape without noticing that the requested thing was never there. I would treat object presence and object location as separate decisions before letting this feature crop an image or direct another action.

TypeSafe makes the experimental status explicit. Images and Box questions require the `TypeSafe-Danger-Zone-Images: true` header, and the company says they have not met its production standards. That is a reason to prototype carefully. A stable output type should not make an experimental capability look ready for unattended use.

## The rectangle survives a missing object

The [Box reference](https://docs.typesafe.ai/go/box) describes one answer per question: four edges, expressed as fractions of the image's width and height, plus confidence. There is no "not found" answer. TypeSafe recommends asking a separate Noul question, its yes/no question type, about whether the target is visible and ignoring the box when that answer is low. It also says there is no recommended Box confidence threshold yet; developers must tune one on their own images.

I can work with that contract. A location question answers where, while a presence question decides whether the location deserves attention. The mistake would be to read the existence of coordinates as evidence that the object exists. Imagine a prototype that crops a product photo to the requested mug. If the mug is missing, passing those coordinates downstream could turn an empty patch into an apparently successful extraction.

This extends the distinction I made in [my earlier Jev analysis](https://markhuang.ai/news/jev-schema-guarantee-wrong-decision): a valid type does not establish a correct decision. A bad crop can remove the evidence another step would need to notice the mistake.

My proposed prototype would ask presence and location together, as the documentation allows, then make the application responsible for accepting the result:

```mermaid

flowchart LR
    A[Image and named target] --> B[Pinned Jev 1.14 with images enabled]
    B --> C[Presence answer]
    B --> D[Box and confidence]
    C --> E{Application checks}
    D --> E
    E -->|Absent or uncertain| F[Ignore box or request review]
    E -->|Passes tested thresholds| G[Create candidate crop]
    G --> H[Check crop before downstream use]
```

That final check would matter even when the object is present. TypeSafe reports that four separate edge questions caught 30 of 36 deliberately clipped painting crops, compared with 26 for a single completeness question. This is a small vendor test, but it illustrates a useful failure case: finding the right object and preserving all of it are separate requirements. I would keep the original image available while testing either.

## Composability buys convenience, then needs discipline

The [image documentation](https://docs.typesafe.ai/go/images) lets images appear in the state, a question's instructions, or its criteria. That makes examples part of the decision interface: a prototype could compare a scene with a reference photo or define allowed options with pictures. Image input works with Jev 1.13 as well as 1.14; Box requires 1.14.

I would read the reference rules before designing a large request. Uploading an image once does not mean the model sees it once. Each use of its reference adds another copy to the expanded request. The docs recommend putting an image shared by several questions in the state and referring to that field. I would settle the request layout before assuming that one upload makes repeated visual checks cheap.

Public discussion also suggests keeping the job of each check explicit. In a [Hacker News thread about a Jev document-review demo](https://news.ycombinator.com/item?id=50068443), commenters debated whether an extra model was catching useful semantic problems or duplicating validation better handled in code. That thread does not evaluate Jev 1.14. The distinction is still useful here: matching the requested object, locating it, and deciding what the application should do are different jobs.

## A larger context is another experiment

The release also opens longer context behind `TypeSafe-Danger-Zone-Long-Context: true`. The model docs list default limits of 64k tokens per request and 32k per question. With the header, both become 262k. TypeSafe says this mode costs the same per token but is slower and less accurate than staying within the defaults.

I would evaluate that change separately from image support. More room could let a prototype carry extra references, but it also changes the conditions under which I trusted the decision. Combining a new model, images, and longer context in the first experiment would make a regression harder to explain.

I would also keep the model version fixed. The release says `jev-latest` will move to 1.14 in a week; the inspected docs still map it to 1.13 and `jev-preview` to 1.14. TypeSafe recommends a versioned ID when thresholds have been tuned against a particular model. I would pin `jev-1.14.0` for the prototype and record the returned model ID.

## I would start with the missing cases

Mike Ramos's [independent poker evaluation](https://backnotprop.com/blog/jev-poker/) offers a useful skeptical precedent. It tested Jev 1.13 and reported decisions that changed when computed hand labels were added to the input. Its narrow setup cannot tell us how 1.14 handles images. It does support asking whether the information supplied to a decision model is enough for the judgment we expect.

For Box, I would start with labeled images that include absent targets and ambiguous duplicates, then inspect whether accepted crops preserve the intended object. I would measure false presence separately from bad localization. A single success rate would hide which boundary needs fixing.

I appreciate TypeSafe spelling out what it is not ready to vouch for. Visual questions with answers ordinary code can consume are worth trying. Before I let those answers drive automation, I want the empty-image cases in the evaluation. A missing object should produce an explicit application outcome, even when the model's type always produces a box.