500 Emails Classified in Seconds for $0.035
Where fast, structured AI decisions fit in real software workflows, and where they do not.
Five hundred emails. A few seconds. A reported model cost of $0.035. The number catches attention, but the business question matters more: which repeated decisions in your workflow could become that fast and inexpensive without giving AI control of the outcome?
The result comes from a public builder report, not an independent benchmark. Its value is the pattern it exposes. Many teams do not need another system that writes paragraphs. They need help with a repeated judgment buried inside an existing workflow: which queue should receive this ticket, which document needs review, or which search result best answers a query?
That is the practical boundary for Jev, TypeSafe’s model for making small, structured decisions inside software. Your application supplies relevant state and a typed question. Jev returns an allowed choice, a rubric score, or a probability that code can use. It does not compose an email, build a plan, or decide its own next action.
This guide starts with a broad use-case map, then keeps the shared support inbox as a detailed end-to-end example. The map is based on TypeSafe’s official example use cases, but read it as an idea source, not proof that Jev will perform well in every listed workflow. Each team still needs to test its own inputs, labels, thresholds, costs, and error consequences.
Start with the decision, not the industry
A promising Jev workflow has five traits:
- Repeated unstructured inputs. The team receives many emails, documents, messages, logs, prompts, transcripts, or records written in inconsistent language.
- A bounded decision. The useful output can be expressed as a fixed category, a yes-or-no probability, or a position on a defined rubric.
- A downstream action. Code or a person does something specific with that output, such as route, rank, flag, hold, or escalate.
- Enough volume. The decision appears often enough that integration, evaluation, monitoring, and review could be worth the effort.
- Reviewable errors. The team can inspect wrong decisions, compare them with expected outcomes, and send uncertain or risky cases to review.
If one of those elements is missing, the use case is probably too vague. “Understand our customers” is not a bounded decision. “Classify each inbound message as billing, product support, sales, account help, or needs review” is. The second formulation gives software a finite result and gives the team something it can evaluate.
TypeSafe exposes three question types, or primitives:
- Choice selects one option from a fixed list. The response includes the selected option, option probabilities, and confidence. Use it when one known category or candidate should win.
- Noul evaluates a yes-or-no statement and returns the probability that the answer is yes. Use it for detection: does this message request a refund, contain personal data, or satisfy an inclusion criterion?
- Score places an item on ordered, described levels. The response includes the score, level probabilities, and confidence. Use it for severity, relevance, quality, risk, or another genuine spectrum.
The distinction matters. A Noul value near 0.5 is not “medium severity”; it means yes and no have similar probability. Severity belongs in a Score with explicit levels. Likewise, a Choice among departments answers a relative question about the best route, while separate Nouls ask whether each property is present. Pick the type whose output maps most directly to the next line of code.
Keep each question atomic. “Is this a serious complaint that billing should handle immediately?” mixes topic, severity, urgency, and route. Ask those judgments separately, then combine them with deterministic rules. TypeSafe’s current introduction says independent questions can share one state and be evaluated together, while application code remains responsible for composing the answers.
A practical use-case map
The following inventory turns broad categories from TypeSafe’s official map into narrow operating decisions. These are candidate designs, not validated deployments or performance claims. “Choice / Score / Noul” names the main primitive; a production workflow may ask several independent questions in one request.
Workflow | Source input | Narrow Jev decision | What happens next |
|---|---|---|---|
1. Customer support triage | Ticket subject and body, customer status, product area, and relevant open-order data | Choice: billing, orders, product support, sales, account help, or needs review. Companion Nouls can detect a refund request or exposed credentials; a Score can rate expressed frustration. | Code places a clear ticket in the proposed queue, adds non-destructive flags, and sends low-confidence or conflicting cases to a triage operator. A person still approves refunds, account changes, and replies. |
2. Sales and lead routing | Inbound form text, email, company profile, role, and declared need | Choice: named territory or sales motion. Score: fit against an explicit ideal-customer rubric. Noul: does the message show a defined purchase signal? | Code assigns the lead, sets a review priority, or holds it for enrichment. A sales operator reviews uncertain matches rather than treating a score as a revenue forecast. |
3. Recruiting review | Resume, application answers, role requirements, and job-related screening criteria | Nouls: is there evidence for each required competency? Score: evidence strength on a defined rubric. Choice: best-matching open role or manual review. | The applicant tracking system groups evidence and routes the file to a recruiter or hiring manager. People make employment decisions and review potential bias, accommodations, missing context, and uncertain cases. |
4. Legal and compliance intake | Contract, marketing claim, policy, filing, or vendor response plus an approved checklist | Choice: document or issue type. Nouls: is a required clause missing, or is a prohibited claim present? Score: review severity based on stated criteria. | Code opens the right checklist, highlights the relevant passage, and routes material or uncertain findings to counsel or compliance. Jev does not provide legal advice or approve publication. |
5. Moderation and trust and safety | User post, marketplace listing, chat message, conversation context, and a current policy excerpt | Choice: allow, warn, review, or block candidate. Nouls: signs of harassment, fraud, personal-data exposure, or an opt-out request. Score: policy-defined severity. | Policy code combines the signals and confidence with account history and hard rules. Borderline or high-impact actions go to trained reviewers; automatic actions are limited to cases whose error costs have been assessed. |
6. Advertising and content analysis | Ad copy, creative description, landing-page text, placement context, and campaign policy | Choice: audience or message category. Nouls: prohibited claim, brand-safety issue, or mismatch between ad and landing page. Score: alignment or suitability on explicit levels. | Code tags assets, builds a comparison dataset, and sends possible violations to marketing or compliance review. It does not infer campaign lift or approve spend from semantic labels alone. |
7. Model routing and LLM guardrails | User prompt, retrieved context, proposed model output, or planned tool call | Choice: deterministic handler, small model, large model, or human review. Nouls: prompt injection, sensitive-data exposure, unsupported citation, or policy failure. Score: difficulty or hazard severity. | The application selects a handler, blocks or holds a risky request, strips disallowed context through deterministic code, or escalates. The guardrail result is logged as one signal rather than treated as infallible. |
8. Search, retrieval, and ranking | Natural-language query plus candidate passages, products, records, or documents | Choice: best candidate within a bounded shortlist. Score: query-to-candidate relevance. Noul: does the candidate set contain an answer at all? | Code reranks the shortlist, selects context for a downstream model, or returns “no supported result.” Access controls and exact filters run before semantic ranking. |
9. Incident and log triage | Incident report, alert text, stack trace, operator note, service metadata, and known runbook categories | Choice: owning service or incident class. Score: operational severity using an agreed rubric. Nouls: user impact, possible security relevance, or known-issue match. | Code pages the appropriate on-call team, links a runbook, or places a low-risk item in a review queue. Monitoring facts, paging policy, and service health checks remain deterministic. |
10. Invoices and document classification | OCR text, email attachment text, sender metadata, purchase-order records, and known document types | Choice: invoice, credit note, receipt, purchase order, or unknown. Nouls: purchase-order reference present, duplicate-looking document, or missing required field. | Code opens the correct extraction or approval path, checks amounts and identifiers with normal parsers, and sends mismatches to accounts payable. No payment is released on a semantic decision alone. |
11. Research screening | Paper title, abstract, methods excerpt, and explicit inclusion and exclusion criteria | Nouls: does the paper satisfy each criterion? Choice: include candidate, exclude candidate, or full-text review. Score: evidence relevance to the research question. | Review software prioritizes records and shows the criterion-level signals. Researchers resolve ambiguity, document exclusion reasons, and make the final systematic-review decision. |
12. Qualitative research coding | Interview transcript passage, open-ended survey response, field note, and a predefined codebook | Choice: primary theme. Independent Nouls: is each named theme present? Score: strength of evidence for a theme under described levels. | Code groups passages and builds a review sample; researchers confirm codes, refine the codebook, and retain minority or contradictory cases instead of forcing every passage into a neat narrative. |
The shared shape is more important than the sector. A piece of unstructured evidence arrives. Jev answers one narrow question. Code applies ordinary rules. A person takes over where the consequence, ambiguity, or policy requires judgment.
A useful design sentence is: Given this source input, ask this bounded question so code can take this reversible next step. If the sentence ends with “so the AI can handle it,” the workflow is not defined tightly enough.
Detailed example for a shared support inbox
A shared inbox is a strong first test because many different messages still lead to the same few operational decisions. Someone identifies the topic, spots signals that need attention, and assigns the right queue. That repeated judgment can delay the person who can solve the issue.
Keyword rules help until language becomes ambiguous. “Charge” could mean a duplicate payment, a refund status, an annual-pricing question, or a prospect asking about billing terms. “Cancel” could refer to an account, an order, or a meeting. The answer is not to make the whole workflow probabilistic. Keep deterministic facts and powers in code:
- Confirm the sender, account, plan, and order data from internal systems.
- Enforce permissions, service-level commitments, and account policies.
- Calculate dates, amounts, and queue capacity with normal software.
- Record the original message, structured decision, model output, and final human action.
- Send replies, issue credits, cancel accounts, or change records only through approved application logic.
Jev belongs at the language judgment point. Consider this hypothetical email:
Subject: Charged twice for order A-104
Hi, I can see two charges for order A-104. The order arrived, so I do not need to cancel it. Please refund the duplicate charge. This is the second time I have contacted you.
The smallest useful state might include the subject, body, whether the sender matches a customer, and a list of relevant orders. It should not include the entire account history if the questions do not need it.
Do not ask, “What should we do?” Ask independent, typed questions:
- Topic Choice: Which queue best matches the primary request:
billing,orders,product_support,sales,account_help, orneeds_review? - Refund Noul: Does the customer explicitly ask for money back or an account credit, rather than only question a charge?
- Frustration Score: How frustrated does the customer appear: calm and factual; frustrated but civil; or very angry or threatening to leave?
An illustrative, human-readable summary might be:
topic: billing
refund requested: likely
frustration: frustrated but civilThat is not a live Jev result. In production, retain the actual typed answer fields, option or level probabilities, and available confidence values returned by the API. The application should not reduce uncertain output to a confident-looking sentence.
Code now owns the route:
Structured signal | Deterministic next step |
|---|---|
Topic is | Place the ticket in the billing queue |
Topic is | Place it in the order-support queue |
Topic is | Place it in the sales queue |
Refund appears requested | Add a review flag; do not issue money |
Frustration is elevated | Raise review priority within the selected queue |
Topic is unclear, account data conflicts, or confidence misses the pilot gate | Send it to manual triage |
This separation is the point. A topic can select a queue without bypassing identity checks or refund policy. A frustration score can affect review order without deciding whether the customer is right. Uncertainty has an explicit destination instead of falling into a hopeful default.
TypeSafe’s confidence-gated routing pattern treats the answer and confidence as separate signals: one says what the model selected; the other helps code decide whether to act. Do not copy a documentation threshold into production. Choose gates against labeled messages from your own inbox, and set stricter requirements as the cost of a wrong action rises.
Pilot the workflow before automating it
Start with one inbox, one language, the current queue list, and a recent sample with known final owners. Exclude security reports, legal notices, payment disputes, threats, and any category where a wrong route could create unacceptable delay. The first pilot should be easy to pause.
Run it in stages:
- Write the decision contract. Define each allowed output, what belongs there, what belongs in neighboring categories instead, and representative examples. Define each Noul statement and Score level separately.
- Create an evaluation set. Sample normal cases, rare cases, confusing neighbors, and high-cost errors. Remove unnecessary personal or confidential data. Keep the expected route and reviewer notes.
- Replay in shadow mode. Evaluate historical items without changing live queues. Compare results with the final human route, but inspect disagreements because historical labels can be wrong too.
- Assist before automating. Show the suggested route and signals to the triage operator. Let the operator accept or override them. Record why overrides happen.
- Automate only reversible paths. Move clear, low-risk cases while preserving a manual-review path. Reassess thresholds when categories, policies, language mix, or source data change.
Measure the whole workflow rather than presenting one accuracy number:
- time from arrival to the correct owner;
- share sent directly to the final queue;
- transfers caused by a wrong first route;
- manual-review and operator-override rates by category;
- false negatives for high-cost signals;
- review time and rework;
- latency, API cost, integration cost, and monitoring cost;
- performance by language, source, customer group, or other relevant slice.
A pilot succeeds only if the handoff improves without creating more review and repair work than it saves. Evaluation should also reflect the cost of different mistakes. Sending a routine billing question to manual triage is inefficient; failing to identify a security issue can be far more serious.
One public ShipWithJev page says its builder classified 500 emails in seconds for $0.035. Treat that only as an author-reported demonstration. It is not an independent benchmark, a customer result, or a forecast. Your input length, number of questions, model version, exception rate, and human-review process determine the real cost and value.
Know where Jev should not be used
Use a short rejection test before building. Jev is a poor fit when:
- the required output is a composed reply, policy explanation, investigation, or multi-step plan;
- exact code, database filters, arithmetic, or a conventional parser can produce the answer reliably;
- the action is irreversible or high-stakes and no qualified person reviews it;
- the team cannot define allowed outputs, criteria, or what each result changes;
- volume is too low or cases are too unique to justify integration and monitoring;
- ground truth is unavailable and errors cannot be reviewed;
- required context cannot be shared safely or lawfully;
- the workflow expects the model to send messages, move money, change permissions, or make legal, medical, credit, employment, or safety decisions on its own.
A simple deterministic rule should stay a rule. If every message from a monitored abuse address must enter the security queue, write that in code. If a document must contain an exact account number, validate the field directly. Jev is for bounded semantic judgment, not a replacement for reliable software.
The best starting question is concrete: Which repeated judgment delays an important workflow, what fixed output represents that judgment, and what reversible action should follow? If those three parts are clear, the use-case map can help you design a pilot. If they are not, clean up the workflow before adding a model.
Send MajesticLabs one repeated workflow and one recent, redacted example. A fixed-scope workflow review examines the last three handoffs and returns one recommendation: stop, clean up the workflow first, or run a bounded pilot.