Brainstorm results: Jev use cases that have not been widely discussed

1. The question and the two runs

Jev is the first "System One" model from TypeSafe AI. It takes unstructured state and a typed question. It returns a typed answer (a choice among up to 255 options, a score, or a boolean) with probabilities, and never returns free text. The question for the brainstorm was: which use cases of Jev are not yet widely discussed?

The same prompt ran twice, on two different evidence bases.

The prompt asked every candidate to be judged from three views: the factual or evidentiary view, the reader view, and what other publications cover. The agents handled the first and third views. The reader view was a judgment that I made in the parent session. No reader test was run.

2. Run 1: open web research

2.1 What the first stage found

• Coverage map. One agent counted use-case categories over 27 pages. Saturated: agent safety gating and ticket triage (19 pages each), bulk labeling (15), games and control loops (14), reranking (13), model routing (12), moderation (10). Absent from every page read: healthcare, education, government, manufacturing and supply chain, procurement, translation, UX research, accounting, and robotics on real hardware.
• Failure reports. A fair die gave 82.9% stated probability on face 1 at 19.0% accuracy (chance is 16.7%). A stated 30% risk became 5.3%, 45% became 6.6%, and 55% became 95.9%. A Tetris player cleared 23, 115, and 23 lines on three seeds, against 118, 73, and 118 for a keyword regex.
• Vendor facts. Three question types. A 64k token limit for the state plus all questions, and 32k for the state plus the longest question. 40 requests per second and 100K tokens per second. Nine documented failure modes, including counting, math, and date comparison.

2.2 The 20 candidates

2.3 The chosen idea: contradiction scan of a policy corpus

1. Split a corpus of policies into clauses, for example a handbook, terms of service, or a grant rulebook.
2. Use embeddings to pick candidate pairs of clauses.
3. Ask Jev one question per pair, in both orders: "contradict / consistent / unrelated".
4. Flag a pair only when both orders say "contradict" with p of 0.7 or higher.
5. Check numbers and dates in code, not in Jev. The vendor lists counting, math, and date comparison as failure modes.

Why it won. The both-orders rule turns a documented weakness into a filter. A community audit found that the first-listed option gains 0.37. A human can verify each flagged pair by reading two clauses. No page in the coverage map covers government or public-sector use, and the search found no Jev-specific contradiction scan.

Cost. About 400 million tokens for 1,000 clauses in both orders, which is about $17 at $0.042 per million. The vendor request limit of 40 per second applied to about 999,000 calls gives about 6.9 hours, so the request limit is the tighter constraint. Putting one clause in the shared state and asking up to 13 questions per call should reduce this. The vendor cookbook reports 10.0 times faster for 13 questions in one request.

Test. Use the LegalWiz documents with injected contradictions. Pass if recall is 0.70 or higher in the top 200 flagged pairs and precision@50 is 0.50 or higher. These thresholds are an agent's proposal.

2.4 Rejected candidates, ranked

1. Clause-ambiguity index. Scores a clause by how much the answer changes under reworded questions. Brittleness of the model and ambiguity of the text are confounded, and the test needs human-labeled disputed clauses.
2. Delta debugging with Jev as the oracle. An unstable oracle can drop the real cause of a failure.
3. Genealogy same-person matching. Overlaps entity resolution, which is saturated. Common names are chance-like inputs.
4. Stale-note checker. The audience is narrow.
5. Archives access and retention review. A wrong "open" releases confidential material.
6. Manufacturing report routing. No public dataset can test it.
7. Translation QA gate. The vendor says English works best and other languages less well.
8. Volunteer-transcription adjudication. The high novelty rating rests on 2 search queries.
9. Permit completeness. Non-Jev vendors already sell it.
10. Medical coding audit. A Jev prior-authorization proof of concept is adjacent.
11. Production semantic assert. Test-time tools exist.
12. Low-novelty group. Leakage probe, label-noise audit, difficulty stratifier, claim-versus-table check, FOIA scoring, sort comparator, A/B surrogate, cache verifier. Each has close prior art.

The agents dropped four ideas before they wrote them, because Jev work already existed: prior authorization, interview coding, short-answer grading, and bookkeeping.

3. Run 2: the launch blog and the awesome-jev list only

3.1 What the first stage found

Four agents each read a slice of the list's category files (167,674 bytes in total, about 552 entries by their hand tallies). They reported:

• Saturated: GUI and browser action selection (about 19 entries), tool-call gating (about 18), coding-agent model routing (about 13), retrieval and reranking (about 20), language SDKs (about 23), open Jev replicas (about 33).
• Empty or thin: the scientific-pipelines category has 0 entries and compliance-legal has 2. Output-side guardrails have 1 entry. The list has no entry for healthcare, insurance, education, or manufacturing triage, and none for map-reduce, which the blog names.
• Absent integrations: n8n, Airflow, Kafka, dbt, Temporal, CrewAI, Redis, Elasticsearch, Qdrant, Cloudflare Workers, and OpenTelemetry. One later correction: a LangGraph entry does exist.
• Limits recorded in the list: the fair-die result (82.9% against 19.0%); a 706,048-parameter specialist that scored 99.7% against Jev's 83.6% on form filling; an open model that completed 38.5% of web tasks against 16.7% for Jev 1.13; and a cost study that measured Jev at 6.6 to 12.7 times an LLM's token cost on its task.

3.2 The 15 candidates

3.3 The chosen idea: dead-letter-queue triage with a replay contract

A message queue sends messages that keep failing to a "dead-letter queue". During an incident, thousands of these messages pile up, and an engineer sorts them by hand.

1. A small consumer reads each failed message: error, headers, and payload, about 600 tokens.
2. It adds about 30 known failure signatures, about 450 tokens.
3. Jev answers one choice: replay, replay after fix N, quarantine, or page a human.
4. Code enforces the contract. Only idempotent messages replay automatically, and Jev can never discard a message.

Why it won. The list has no entry for dead-letter queues. A grep of its README for "dead letter", "dlq", "kafka", "poison", "message queue", "rabbitmq", and "sqs" found no hit. The blog names workflow routing and real-time use, and the list has no streaming-operations entry. The worst error, a wrong replay, is blocked by the idempotency rule in code, so the design does not depend on Jev's probabilities being calibrated.

Cost. For one million messages at 1,050 tokens each, that is 1,050 MTok at $0.042, which is $44.10 for an incident hour. The token counts are an agent's assumption. The list's Jev for Physical AI entry reports $24.57 per million decisions, which is about 585 tokens per decision at the same price, a figure in the same range.

Test. Take 2,000 engineer-labeled messages. Pass if the replay class has 99% or higher agreement at p of 0.95 or higher, with 40% or higher coverage. Fail if any non-idempotent message is replayed automatically. The thresholds are an agent's proposal.

3.4 Rejected candidates, ranked

1. Questionnaire pretest with synthetic respondents. Uses the wording sensitivity of Jev as the measurement. It rests on one list entry whose repository I did not open, and correlated synthetic respondents are the main risk.
2. Material-change classification of policy or terms pages. The blog has no long-context benchmark, and a missed change is the costly error.
3. Clinical-trial eligibility pre-screen. The list's medical entries are exams and hallucination tests. A wrong "not met" removes an eligible patient.
4. Insurance first-notice-of-loss routing. New industry on a routing pattern that the list already covers heavily.
5. Shipment-exception handling. Same problem. The nearest entry is warehouse robot triage.
6. Hazard-log risk map. Depends on score ordering, and the list records a ranking benchmark that failed four of six conditions.
7. Hierarchical code assignment. Errors compound: 0.9 per level gives 65.6% over four levels.
8. Root-cause hop navigation. An existing entry uses the method on a knowledge graph. 0.9 per hop gives 59% over five hops.
9. Voice end-of-turn local head. Adapts the list's stuntd pattern. Voice turn-taking appears as a demo.
10. Entity resolution with one choice per record. Costs $1,722 for 10 million records against $5,040 for pairwise questions. The list already has a pairwise tool.
11. Product-taxonomy assignment. The mechanism is shown on other item types.
12. Short-answer rubric scoring. The list records a subjective-scoring test where no model beat the label base rates.
13. Airflow or Temporal branch node. Only the engine names are new.
14. Next-file prefetch. A plain recency rule likely wins.

The agents dropped systematic-review screening, support-ticket routing, and spam moderation before ranking, because the list covers them.

4. Comparing the two runs

• The winners differ. Run 1 produced a corpus-level analysis tool and run 2 produced an operational pipeline step. The two evidence bases led to different ideas.
• Both winners have a code-side guard. In run 1, code handles numbers and dates and the both-orders rule filters Jev's output. In run 2, the idempotency rule limits the action that Jev can trigger. This pattern appeared in both choices. I did not test whether it is general.
• The runner-ups both use Jev's weakness as the measurement. The clause-ambiguity index and the questionnaire pretest both measure how much the answer changes under reworded questions.
• The run-2 list had more candidates marked "high novelty" (8 of 15) than run 1 (3 of 20). Part of the cause is the method. Run 2 judged novelty by grepping one list, and run 1 searched the web.

5. What is not verified

• No candidate was built, and no call to Jev was made. Every validation threshold is an agent's proposal.
• The agents read search summaries and some pages. I opened only a few of the sources myself.
• The novelty ratings are only as good as the searches. Run 1 searched the web, and run 2 searched one curated list.
• The list's entries are not endorsements, by the list's own warning. Several entries cited here are personal repositories that I did not run.
• This is one task, run twice, with one model. The runs give no measure of variance.