What you can test
- Testing an explicit sales handoff policy
- Keeping unknown facts separate from negative answers
- Reviewing conflicting inquiries before prioritization
Jev lead qualification routes a stated buying situation to a useful next step. Edit the facts, inspect the response and see why missing budget is different from no budget.
Qualification is a decision about the next conversation, not a prediction that a person will buy. This example gives Jev five choices and an explicit policy. A fully stated near-term buying plan can go to sales. A genuine inquiry with an unanswered qualification question goes to follow-up. A future project goes to nurture. Contradictory records remain available for review.
Microsoft describes budget, authority, need and timeline as qualification dimensions, while also distinguishing company fit from intent signals. Our policy is a deliberately small exercise using those dimensions. The 90-day window is our chosen test rule, not a universal sales standard. Change it to match your own process before evaluating real inquiries.
The X source describes typed lead scoring across a larger batch. We built an independent, smaller Choice example from that idea. We have not reproduced its reported lead count, cost or timing. Company size appears in some inputs to test a useful boundary: it must not supply evidence of purchasing budget or authority that the record never states.

Define the handoff rule before you rank the records.
Use the actual inquiry and confirmed account information. Redact private details and leave absent qualification fields unknown.
Set the need, authority, budget and timing conditions. Decide where incomplete and contradictory records should go.
Run the presets, then change one fact at a time. Inspect the full distribution when the leading choice seems surprising.
Check the record and ask for the missing fact. The demo does not contact a lead, update a CRM or schedule follow-up.
| Original inquiry | Observed label | Leading probability |
|---|---|---|
| Confirmed buying plan | Sales ready | 100% |
| Budget not stated | Follow up | 99% |
| Next year project | Nurture | 99% |
| Research request | Not a prospect | 100% |
| Conflicting notes | Needs review | 100% |
| Large company only | Needs review | 100% |
Six live Jev requests on September 27, 2026. Synthetic functional checks, not a conversion or accuracy benchmark. Fresh distributions may differ.Verified
A missing budget field and an explicit statement that no budget is available are different facts. The first should prompt a question. The second may justify staying in touch for a later cycle. Treating both as a low score hides the reason for the decision and makes it difficult for a seller to correct the record.
For Follow up, return to the original inquiry and identify the unanswered qualification fact. For Nurture, preserve the stated timing instead of repeatedly asking for a meeting. A Not a prospect result can keep an academic request in a documentation queue. Needs review protects conflicting or nearly empty records from a fabricated buying story.
Download the exact fixture and the one-request runner below. Install @typesafe-ai/sdk in a private Node.js folder, set TYPESAFE_API_KEY in your shell, then run node run-choice-sample.mjs observed-leads.json budget. This sends one live request with retries disabled. Change the selected sample ID to compare another inquiry. The saved observations are a separate record of our original test, not a cached replacement for the live response.
The leading probability describes the model's preference among your labels for that input. It is not a conversion rate, expected deal value or evidence of consent to contact someone. Keep contact permission and CRM changes in your application workflow. Evaluate the policy against reviewed examples from your own sales process before relying on it for prioritization.
Try a controlled edit: add an approved budget to the missing-budget inquiry while keeping its need, authority and timeline unchanged. Then remove the timeline. Looking at one changed fact at a time makes a policy disagreement easier to inspect than changing the entire record.

import { readFile } from 'node:fs/promises';
import { choice, TypeSafeClient } from '@typesafe-ai/sdk';
// Run one selected sample. There are no retries or automatic batch requests.
const [file, sampleId] = process.argv.slice(2);
if (!file || !sampleId || !process.env.TYPESAFE_API_KEY) {
throw new Error('Set TYPESAFE_API_KEY, then run: node run-choice-sample.mjs FIXTURE.json SAMPLE_ID');
}
const raw = await readFile(file, 'utf8');
if (Buffer.byteLength(raw) > 1_000_000) throw new Error('Fixture is too large');
/** @type {{samples: Array<{id: string, request: {context: string, question: string, choices: string[]}}>}} */
const fixture = JSON.parse(raw);
const matches = fixture.samples.filter(sample => sample.id === sampleId);
if (matches.length !== 1) throw new Error('Select exactly one existing sample ID');
const { context, question, choices } = matches[0].request;
if (typeof context !== 'string' || typeof question !== 'string' || context.length > 12000
|| question.length > 500 || !Array.isArray(choices) || choices.length < 2 || choices.length > 12
|| choices.some(label => typeof label !== 'string' || !label || label.length > 120)
|| new Set(choices).size !== choices.length) throw new Error('Invalid sample request');
const client = new TypeSafeClient({ logLevel: 'off' });
const start = performance.now();
try {
const result = await client.systemOne({ model: 'jev-latest', state: { context, question, choices },
questions: { decision: choice(question, Object.fromEntries(choices.map(label => [label, null]))) } },
{ timeout: 10000, retry: { maxRetries: 0 } });
console.log(JSON.stringify({ sampleId, elapsedMs: Math.round(performance.now() - start), result }, null, 2));
} catch {
console.error('The API request failed. No retry was sent; check your account and network privately.');
process.exitCode = 1;
}Understand the choices, the source and what a live result means.
An empty field says the fact is unknown. A statement that funds are unavailable is affirmative evidence. Our policy uses Follow up for missing qualification facts and Nurture for a genuine future project without current budget.
No. The policy requires stated decision authority. A title and employer size can provide context, but they do not establish purchasing permission, approved budget or a current need.
No. It reflects the returned distribution over these supplied labels. This demonstration does not estimate a prospect's chance of buying or train on your sales outcomes.
No. These are original synthetic inquiries tested independently. We do not adopt the source post's batch-size, timing or price claims.
Yes. Edit the input and policy in the hero window to make a real API request. Remove personal or confidential details first. The result does not send outreach or modify a CRM.
Try another input here or build a different Choice question in the Playground.