Jev 1.14 brings images into your acceptance criteria

TL;DR: TypeSafe has enabled images as evidence, instructions and even answer criteria, opening a useful prototype for QA and product teams: judge a screen against agreed visual examples instead of asking a model whether it “looks right.” Jev 1.14 also adds a single bounding-box answer. These image capabilities are experimental, not production-ready. Start with a review assistant, not an automated release gate.

A checkout drawer can differ from its approved design without being broken. It can also look almost identical while hiding the button a customer needs.

That is the useful question behind TypeSafe’s October 14 release. Not “Can AI see screenshots?” but “Can product and QA express the same visual acceptance rule in a form a model can evaluate?”

The new interface makes that worth prototyping. It does not establish that Jev is a reliable visual tester. This article develops a source-backed design; we have not run the image workflow against Jev and report no measured accuracy, latency or cost.

What changed and which model to use

The release combines a new model with newly enabled capabilities. They are not the same thing.

As checked October 15, the direct API model documentation maps jev-preview to jev-1.14.0 and jev-latest to jev-1.13.0. The announcement says the stable alias is planned to move in a week. That is a plan, not evidence it has already moved. Pin jev-1.14.0 for a repeatable prototype and record the returned model ID.

This article uses TypeSafe’s direct POST https://api.typesafe.ai/v1/systemone contract. Do not transplant those identifiers or upload fields into another provider’s endpoint without checking that provider’s documentation.

The dedicated image documentation explicitly supports both releases, although the model overview’s input table still says “Text.” Use the dedicated image contract for this experimental path. Every request containing an image or Box question needs TypeSafe-Danger-Zone-Images: true.

TypeSafe calls images and Box “dreamer-ready” and says their formats, limits and accuracy may change. They are not ready for production use according to the provider.

Make the acceptance criteria visible

Imagine a product team reviewing a redesigned checkout drawer. The important rule is not pixel identity. The order summary should remain visible, and the confirmation control should not be covered by another panel.

Product supplies an approved reference and examples of unacceptable obstruction. QA adds awkward but valid states: a long product name, a translated label and a narrow viewport. Together they label which differences matter.

Jev’s image placement contract gives those inputs different jobs:

• State: the candidate screenshot being reviewed, plus viewport and scenario context.

• Instructions: the specific question, with a reference image if it belongs only to that question.

• Criteria: example images and descriptions defining the allowed categories.

A proposed Choice might return acceptable_layout, control_obscured, or needs_review. Those are application-defined labels, not built-in Jev categories. The criteria should say why an example belongs in a category. Otherwise the model may learn the wrong distinction, such as color theme instead of obstruction.

Keep the question narrow: “Does the confirmation region match an accepted unobstructed layout?” is a different task from “Would customers find this checkout easy?” A screenshot classification cannot establish usability, accessibility or conversion performance.

The same library helps product and QA even before a model runs. It exposes disagreements about what “acceptable” means.

Presence comes before location

The most consequential detail in the Box documentation is easy to miss: a Box answer always contains a box. There is no not-found answer.

Ask for a confirmation button that is absent and you still receive four edges. Treating those coordinates as proof of existence would turn a well-formed answer into a false finding.

Separate the proposed checks:

1. Ask a Noul, Jev’s yes-probability question, whether the target is visible.

2. Ask a Box question where that specific target appears.

3. Ignore the box when the presence check fails your evaluated policy or is uncertain.

4. Present the original screenshot and proposed crop together for human review.

A Box question has type and instructions, not criteria. Each question returns one box, expressed as top, bottom, left and right fractions of the image dimensions. Multiple similar controls need disambiguation. “The confirmation control in the open checkout drawer” is a more useful target than “the button.”

Neither presence nor location proves that the control is enabled, reachable by keyboard or connected to a working checkout. Keep exact text, focus behavior, DOM visibility and resulting application state in ordinary browser tests. Use the visual judgment for the question those checks do not answer.

Do not turn a predicted box directly into permission to click, submit an order or approve a release.

A small evaluation product and QA can build together

Use synthetic screens before customer screenshots. Freeze the expected labels before looking at model answers. Here is a proposed fixture set, not executed results:

Compare the prototype with the existing workflow, not a deliberately weak baseline. A pixel comparison can flag changes; DOM assertions can establish specific properties; a human can interpret design intent. Record where each helps and where it misses.

Measure false acceptance of unacceptable layouts separately from unnecessary review of acceptable ones. Track absent-target errors separately from localization quality on targets known to be present. Keep API failures and rejected images in the operational report instead of dropping them from the denominator.

Use held-out examples when choosing thresholds. TypeSafe provides no recommended Box confidence cutoff. A confident rectangle is not calibrated evidence that your release is safe.

The next human action is a joint review of disagreements: clarify the rubric, improve the examples, or decide the task should remain manual. Do not quietly relabel the difficult cases to make the model appear better.

The input details can invalidate the experiment

Images live in the request’s top-level assets map and are referenced from string values. TypeSafe recommends unique references because replacement happens inside text; a short reference can accidentally match part of another word. Object keys are not replaced.

Upload once does not mean evaluate once. Repeating an image reference adds another image copy to the expanded request. If several questions need the same picture, put it in state and refer to that state field rather than embedding it repeatedly in instructions.

The documented limits accept still PNG or JPEG images. Each dimension must fall between 256 and 1568 pixels, and the total area has its own minimum and maximum. A screenshot outside the limits is rejected, not automatically resized. There are also per-image, request-body, processed-image and expanded-request byte limits.

That matters for full-page screenshots and tiny crops. Prepare valid image sizes deliberately and preserve the mapping between a crop and its original. A valid upload is only an input check, not evidence of model quality.

Long context is a separate experiment. TypeSafe-Danger-Zone-Long-Context: true raises both documented context limits to 262k tokens. It does not remove image byte limits or make a pile of unrelated screens useful evidence. Start with the smallest relevant state.

The release also introduces an opt-in to help TypeSafe debug queries while saying it will still not train on them. Do not interpret “not used for training” as permission to upload customer screens or as a universal zero-retention promise. Approve data handling separately and leave optional diagnostic sharing off unless authorized.

Prepare the visual library before automating the judgment

As agents evaluate more interface variants, teams may need versioned visual examples alongside written acceptance criteria.

Build that example library now, with explicit acceptable differences, absent-target cases, and a named human owner for disputed labels.

Keep the reference version, candidate image, viewport, scenario, question definitions and model version together. If an agent later investigates a rejected screen, give it the ordered actions, known start state, expected and actual outcomes, and permission limits too. A crop alone loses the path that produced the screen.

The immediate opportunity is a review assistant with inspectable evidence. Whether it becomes useful automation depends on the evaluation, not the novelty of the image input.

Keep the path behind a visual finding

If the prototype flags a screen, the receiving engineer needs more than the predicted rectangle. Try Samelogic’s bug reproduction workflow: deliberately record the browser steps that lead to the issue, replay the sequence, and inspect the affected element. Keep the approved reference and model finding beside those steps, and review the recording for sensitive content before sharing. Your teammate gets a place to start investigating rather than a crop presented as a complete bug report. This is a proposed workflow connection, not a shipped Jev integration or a claim of automatic diagnosis.

Sources

• TypeSafe’s October 14 Jev release

• Images, placement, uploads and limits

• Box format, absence behavior and confidence

• Model IDs, aliases and long context

• Direct API reference