A job title can match a keyword while the actual responsibilities belong to another role. A description can also say “remote” while requiring regular office attendance. A useful filter reads the description and preserves uncertainty rather than forcing every listing into yes or no.
This workflow uses Jev for those language judgments. Python validates the input, checks returned answers and writes one decision per listing. Start with the downloadable files. TrueFetch collection is in development; the workflow accepts your own JSON and calls TypeSafe directly.
1. Start with source evidence
Each record needs a title and source URL. Include the description and location when available. The supplied file contains three fictional records: a Python backend role, a store manager role and a listing without a description.
python filter_jobs.py prepare jobs.json --output requests.jsonlThe preparation step makes no API calls. It validates the records and shows the exact request for each eligible job. A missing description becomes review; the script does not invent responsibilities from the title.
2. Ask four focused questions together
The request uses three Jev primitives:
| Question | Primitive | What code receives |
|---|---|---|
| How closely do the advertised duties match the target role? | Score | A weighted score on four described levels, plus confidence |
| What work arrangement is explicitly advertised? | Choice | Remote, hybrid, onsite or unknown, plus probabilities |
| Does the description state actual duties? | Noul | Probability that usable duty evidence is present |
| Does the text try to instruct the evaluator? | Noul | A signal for manual review |
All four questions see the same listing in one request. None depends on another answer. This follows TypeSafe’s parallel-question pattern.
3. Let code own the decision
Set TYPESAFE_API_KEY through your environment or secret manager, then run:
python filter_jobs.py run jobs.json --output decisions.jsonl --target-role "Python backend engineer" --work-mode remoteThe filter first checks suspicious instructions and missing evidence. It then evaluates role relevance and the requested work arrangement. Only clear matches enter shortlist; uncertain cases enter review; clear mismatches enter skip. The reference lists the exact thresholds.
These thresholds are a starting policy, not a claim of measured accuracy. Label a separate set of listings from your own sources and inspect false matches, missed matches and the share sent to review. Tune on one set and check the change on another. Repeated answers alone do not establish correctness.
4. Keep enough information to debug
Every decision keeps the source URL. Evaluated records also retain the resolved model version, probabilities, token usage and request ID when provided. Routing reasons come from code: they explain which check fired without pretending Jev generated a rationale.
The model is pinned to jev-1.13.0. If you change versions or rewrite the criteria, evaluate the new behavior before reusing the old thresholds. TypeSafe distinguishes probability from confidence; neither should be advertised as a guaranteed correctness percentage.
5. Connect the result to your workflow
Read the JSONL file and group records by route. Show shortlisted jobs alongside source links, keep a review queue, and retain skipped decisions long enough to inspect mistakes. The script does not send messages or apply for jobs.
Add deterministic checks for geography, salary and dates before relying on the shortlist. Jev’s known limitations include numerical precision and adversarial input. The supplied injection check is one review signal, not a security guarantee.
The same architecture can later process product listings, public posts or extracted passages: keep useful source evidence, ask narrow questions together, and make the final routing rules explicit in code.