Jev Limits: What Data Analysis Cannot Do

By William Zhu & the InfiniSynapse Data Team · Published: 2026-09-23 · Last updated: 2026-09-26 · Last verified: 2026-09-26 · Next review: 2026-12-23 · Editorial standards · Corrections

Author credentials: William Zhu, Cofounder of InfiniSynapse, and the InfiniSynapse Data Team. This page supplies an original eligibility framework and illustrative worked example. It contains no customer experiment, measured Jev benchmark, or production integration claim.

Jev Limits: What Data Analysis Cannot Do

On this page

TL;DR

Jev limits cap the state plus the longest question at about 32,000 tokens, cap the full request at 64,000 tokens, stop Choice at 255 options, and return typed probabilities rather than text. Inside those Jev limits, the model can choose a path when the answer space is closed, the judgment can be labeled, and a miss has a safe fallback. It does not run SQL, perform arithmetic, compare dates, establish causality, grant authorization, or write the report.

This is a proposed architecture, not a claim that InfiniSynapse currently integrates Jev. The useful boundary is simple: Jev limits allow a bounded judgment; deterministic systems compute and enforce; analysts approve consequential exceptions. The downloadable Jev eligibility worksheet applies that boundary to a worked metric-definition routing example.

We evaluated the interface for this page without adding a new service call or production measurement, and we use William Zhu’s previously published retrieval evaluation as a labeled case below.

Judgment is not computation

Data analysis mixes at least four kinds of work:

  1. retrieval finds potentially relevant sources;
  2. judgment classifies or scores ambiguous context;
  3. computation runs SQL, arithmetic, statistics, and reconciliation;
  4. governance enforces access and publication policy.

Jev limits belong only in the second category. Jev’s extraction example demonstrates typed Choice, Score, and Noul questions over supplied state in a bounded extraction use case. That pattern can route an analysis, but it cannot replace the warehouse, query engine, statistical method, or authorization service.

GoogleSQL documents arithmetic as operators over numeric operands in the BigQuery operators reference. If a task requires an exact sum, ratio, date difference, or join, code should calculate it. Asking a probabilistic model to “decide” the number weakens a deterministic operation.

The eligibility test.

A candidate is suitable only when all five statements are true:

  • the input state is available without hidden credentials;
  • acceptable answers can be enumerated before inference;
  • semantic judgment, not exact computation, is the missing step;
  • expected labels and error costs can be evaluated;
  • low confidence or service failure has a safe destination.

Fail any one of these tests and Jev limits should keep the model off that step. The worksheet encodes this as a transparent decision rule rather than a vague maturity score.

Request budget and choice ceiling

The TypeSafe model page documents two Jev limits on size. One request may use 64,000 tokens for the shared state plus every question. The state plus the single longest question may use 32,000 tokens. Questions are evaluated against that state in parallel, so a 10-K, a wide metric catalog, or a long table sample still has to be chunked in code before the call. These Jev limits also stop a Choice at 255 options, so a metric router cannot send every governed metric in one question. Score returns a rubric tier plus a distribution. Noul returns a probability from 0 to 1 and has no separate confidence field. Input is text only: no images, audio, or video, and no streaming response.

The same page lists 1,200 requests per minute and 250,000 tokens per second, and it says those Jev limits can change without notice. A call over either cap returns HTTP 429. The page does not describe a free tier. Input is $0.042 per million tokens, and output tokens are not charged. At that rate, 100,000 calls of 1,000 input tokens are 100 million tokens, which is $4.20. The alias jev-latest currently resolves to jev-1.13.0; pin the versioned id when a threshold has been tuned to one release. A score of 0.85 describes the shape of the returned distribution. It is not a promise that 85% of your metric routes will be right. Task-level public figures stay on the Jev benchmark page.

Eight appropriate use cases

The eight cases below are proposed placements inside Jev limits. They are not claims of measured Jev accuracy. Each names what Jev data analysis may judge and what the surrounding system must still do.

1. Route among authorized source candidates

Given a small list of source descriptors, a Choice can propose which source best matches the question’s subject, grain, and freshness. The source connector must then recheck access and open the selected source.

Good state under these Jev limits includes source names, descriptions, freshness, and supported grains. Bad state includes credentials, unrestricted row samples, or a request to search every system without candidates.

The founder’s public Apple 10-K evaluation provides a concrete boundary. Its vector baseline separated gold and negative documents by only 0.012 in mean similarity and reached 64.6% only with an oracle threshold fitted on that dataset; official Jev reported 92.2% accuracy on the same 79 pairs. The practical lesson is to use vectors for top-k retrieval and evaluate the second-stage filter under Jev limits. Do not treat either number as portable to a new corpus.

2. Select a knowledge-base collection

An analyst may have approved collections for metric definitions, support policy, product events, and finance controls. A bounded route under Jev limits can select the most relevant collection before retrieval. Retrieval still ranks documents, and citations still support any final claim.

This case is strongest when collection ownership is stable and the answer set includes none_or_review. It is weak when the knowledge base is unknown or rapidly changing.

3. Route a metric-definition candidate

When several governed metrics share similar names, Jev limits still let the model propose gross_revenue, net_revenue, recognized_revenue, or human_review from supplied definitions. The semantic layer remains authoritative.

dbt’s documentation treats semantic models as definitions built on models and entities. A probabilistic route may choose which definition to inspect; it must not silently rewrite the metric or bypass its governed expression.

4. Choose a table or view candidate

Given catalog metadata for five approved relations, Jev limits allow a judgment of which relation is semantically closest to the request. The query planner then validates columns, grain, and freshness. A candidate selection is not proof that a join is valid.

Include no_suitable_relation as an answer. Without it, the model is forced to pick a bad table even when none qualifies. A candidate list longer than 255 options has to be narrowed in code before it fits these Jev limits.

5. Score anomaly triage priority

A Score under Jev limits can map an anomaly description onto a predeclared rubric such as informational, investigate this week, investigate today, or stop publishing. Deterministic monitors still calculate deviation, volume, and threshold breaches.

The model should see the computed facts and business context. It should not calculate the anomaly itself. Error costs also matter: false reassurance on a finance control needs a safer fallback than over-prioritizing a dashboard cosmetic issue.

6. Judge evidence sufficiency for the next step

A Noul probability under Jev limits can estimate whether the supplied evidence addresses a checklist, while a Choice can select collect_more, reconcile, or ready_for_gate. Required evidence remains deterministic: missing lineage, row counts, or reconciliation results are hard failures.

This use case prioritizes work; it does not certify correctness. The quality gates must stay outside the model and block artifacts when required checks fail.

7. Route report-publication risk

A bounded rubric can classify a proposed artifact as internal draft, needs subject-matter review, needs privacy review, or blocked. A human or policy engine then applies the publication rule.

The underlying checks may include sensitivity labels, unsupported claims, and unresolved reconciliation. Jev limits allow a summary of the risk lane. The model may not approve release by itself.

8. Escalate ambiguous cases to a human

The final use case is the safety valve for every other one. If probabilities are diffuse, confidence is below an evaluated threshold, candidates are incomplete, or the cost of error is high, Jev limits should send the case to a review lane.

Human escalation is not a failure metric to minimize at all costs. It is the destination that makes bounded automation defensible. Track whether review was useful and whether the original answer set omitted a recurring legitimate case.

Six explicit anti-cases

These tasks may appear near the eight use cases, but they require a different system.

1. Do not use Jev to run or generate SQL

Jev limits exclude a SQL parser, planner, or execution engine. The model returns typed judgments from supplied state. Use governed query generation and warehouse validation for SQL. A route may select a query template, but code must bind parameters, validate the plan, and execute it.

PostgreSQL’s SELECT documentation specifies the clauses and processing of a query. That deterministic language contract cannot be replaced by a probability attached to a label.

2. Do not use Jev for exact arithmetic

Revenue totals, rates, weighted averages, confidence intervals, and reconciliations belong in tested code. BigQuery’s mathematical functions include explicit behavior for arithmetic and error handling. Jev limits also cover counting and date comparison. TypeSafe’s Jev 1.13 jaggedness note flags numeric precision, counting, dates, literal wording, adversarial state, and long context. If invoice lines must sum to the total, or an event must fall inside 30 days, code computes that boolean and the model only judges the policy that follows. Jev data analysis may classify the context around a number; it must not manufacture the number.

3. Do not use Jev to claim causal effects

“Why did sales fall?” is not solved by selecting a plausible reason. Causal analysis requires a design, assumptions, comparison, and uncertainty. Google documents a dedicated AI.CAUSAL_EFFECT function with intervention timing, counterfactual estimates, and statistical outputs. Whether that method is appropriate still requires expert review.

Use Jev limits to keep the model on routing the question into a causal-analysis workflow. Do not let it declare a cause.

4. Do not use Jev for authorization.

A source can be relevant and forbidden at the same time. Identity, grants, purpose, and row-level controls must be evaluated by the data platform. BigQuery’s data control language uses explicit GRANT and REVOKE statements over resources. A high score under these Jev limits is not a grant.

5. Do not use Jev as the final quality gate.

Required controls should be deterministic where possible: schema checks, row counts, freshness, reconciliation, privacy labels, and approval state. Jev limits allow a route around a failed or ambiguous case. They do not let the model waive a gate.

This boundary prevents a semantic judgment from becoming an undocumented exception mechanism.

6. Do not use Jev to write the final analysis.

Jev limits rule out report generation. A final narrative needs computed results, citations, limitations, and approved evidence. Use an analyst or a generative model operating over stored evidence, then apply review and publication gates.

The final report must distinguish facts from hypotheses. A route label alone cannot support a sentence about business performance.

The downloadable eligibility worksheet

The eligibility worksheet is the information-gain asset for this page. It contains:

  • five mandatory eligibility questions;
  • six prohibited capability flags;
  • a deterministic eligible, conditional, or ineligible rule;
  • the eight candidate use cases;
  • the six anti-cases;
  • one completed metric-definition routing example.

Because the worksheet is JSON, reviewers can parse it, inspect the rule, and compare the worked answer with the stated outcome. The file labels every example value as illustrative.

Illustrative grouped bar chart: data-analysis task by semantic fit and deterministic dependency

Figure. Illustrative eligibility scores; exact computation and authorization remain deterministic.

Worked example: metric-definition routing.

The example asks which approved metric definition matches “weekly revenue after refunds and credits.” Its answer set is gross_revenue, net_revenue, recognized_revenue, and human_review.

The worksheet marks the candidate eligible with controls because the answer space is closed, semantic judgment is the missing step, labels can be prepared, and uncertainty can go to a human. It also marks SQL, arithmetic, causal inference, and authorization as outside Jev.

After a route selects net_revenue, the semantic layer supplies the definition, the warehouse computes the value, and the user’s permissions are checked independently. That handoff is the core Jev limits boundary.

Design the evaluation before deployment

An eligible use case is not yet a production-ready use case. Build a labeled set from representative states, including ambiguous and out-of-scope examples. Record class balance, reviewer agreement, and the cost of each error type.

Evaluate the pinned model and question version together. Measure per-class precision and recall, calibration where relevant, abstention or escalation rate, latency, and high-cost errors. Do not copy vendor-wide performance claims into a domain decision. Read Jev benchmark accuracy and latency for task-level public figures and the rerun protocol.

Set thresholds by consequence.

A low-risk knowledge-base route may tolerate a lower automation threshold because retrieval and citations provide another check. A publication-risk route should require stricter evidence and more review. One global confidence threshold is rarely defensible.

Thresholds also need a change process. If the answer definitions, source catalog, or model version changes, rerun the evaluation before restoring automatic handling.

Place the judgment inside a Decision Job

The Decision Job keeps input, sources, named views, evidence, gates, and artifacts under one identity. Attach each event that stays inside Jev limits to the object it reads and record the eventual runtime action.

The data infrastructure hub provides the broader runtime context. For agent-specific route contracts, see the Jev agent route contract. For implementation details, the Jev API for data agents owns the adapter boundary.

Record the handoff, not just the label.

Persist the candidate set, question version, model version, probability distribution, confidence, thresholds, fallback reason, and final action. Also record which deterministic system performed the next step: catalog, semantic layer, warehouse, policy engine, or review queue.

That final field prevents an audit trail from implying the model performed SQL, arithmetic, causal analysis, or authorization. Those jobs sit outside Jev limits.

Frequently Asked Questions

Can Jev analyze a dataframe by itself?

Bottom line: It can judge supplied row or state content through an integration, but the dataframe library still loads, transforms, and computes the data. Evaluate row-wise costs and errors before use.

Can Jev calculate a KPI?

Bottom line: No. Calculate the KPI with SQL or tested code. Jev limits leave the number in code and allow only a route to the correct governed metric definition.

Can Jev decide whether a user may access a table?

Bottom line: No. Relevance is not authorization. The data platform must enforce identity, grants, and resource policy.

Is anomaly scoring an appropriate use case?

Bottom line: Triage can be appropriate when deterministic systems have already computed the anomaly and the score stays inside Jev limits: a closed rubric and a safe review path.

Does InfiniSynapse currently integrate Jev?

Bottom line: This page does not make that claim. It describes a proposed architecture and a worksheet for evaluating possible placements.

How should low-confidence answers be handled?

Bottom line: Route them to a declared fallback—usually more evidence, a deterministic default, or human review. Never convert uncertainty into permission.

What is the Jev request limit?

Bottom line: TypeSafe documents 32,000 tokens for the state plus the longest question, and 64,000 tokens for the full request. Those Jev limits are why a longer document has to be chunked in code before you send it.

How many choices can one Jev question take?

Bottom line: A Choice stops at 255 options. Narrow a metric or table catalog in code when the approved list is longer, and keep an answer such as human_review or no_suitable_relation.

Which data-analysis jobs stay outside Jev limits?

Bottom line: SQL, arithmetic, counting, date comparison, causal claims, authorization, the final quality gate, and the written report. The worksheet marks those jobs ineligible.

Conclusion

Jev data analysis is useful at bounded semantic junctions: source, collection, metric, relation, triage, evidence, publication-risk, and escalation routing. Jev limits keep SQL, arithmetic, causal analysis, authorization, quality gates, and report writing outside the model. Use the worksheet to prove the first category before integration.

Jev Limits: What Data Analysis Cannot Do