How to use Hello, Jev.
This book is for developers who can use an AI coding assistant to build a script and now want to connect natural language to useful software behavior. You might have a folder of support tickets, an article waiting for review, or a user request that needs the right tool. The difficult part is deciding what the program should do after it reads that material.
We begin with a small deliverable: load one message, ask a precise question, and save a result. We then develop that workflow into support triage, a content checklist, and a tool router. The measure of progress is practical. Can you explain the input, the judgment standard, the returned value, and the action your application takes?
What you will build
All three cases share a Python example bundle. Each has synthetic inputs, authored offline responses, and an explicit path to the real API. The people, orders, and businesses in the sample data are teaching examples, not disclosed customer records.
| Case | Input | What you inspect | Deliverable |
|---|---|---|---|
| Support triage | Identified customer messages | Department, urgency, review conditions | Local results and a review queue |
| Content checker | A Markdown draft and checklist | Whether required material appears in the draft | A readable prepublication report |
| Tool router | A request and application state | Intent, parameters, authorization, tool failures | A mock FAQ or order lookup result |
Hello, Jev. is an independent CoolJev publication. Official links support product and API facts; the documentation review date for this edition is September 20, 2026. If the service and a screenshot or example differ, check the current official documentation and the example bundle's version notes before changing your application.
What you need
You should be able to open a terminal, move into a directory, and save a UTF-8 text file. Python 3.10 or newer is the learning baseline. You do not need to design a large application, but you should understand a dictionary, an if statement, and basic exception handling. The coding-assistant brief later in the book can help you work through unfamiliar code. You still need to decide what counts as an acceptable business result.
The bundled offline examples use Python's standard library. They require neither an SDK installation nor an API key. Live mode additionally needs a working TypeSafe account, API key, network connection, and account access. Check your own console for access and billing conditions; owning the book does not grant service access.
From the example project's root directory, your first command is:
python -m examples.hello_jev tickets --mode offline
If your system does not recognize python, follow the virtual-environment steps in Quickstart. This command tests a local sequence: load data, receive a known response shape, apply policy, and save output. It does not ask Jev a question.
Read the evidence labels
| Label | What it establishes | What it does not establish |
|---|---|---|
| Official documentation | The published interface or product description | Performance on your own workload |
| Teaching illustration | How a concept, calculation, or branch works | That a model produced the illustrated numbers |
offline_fixture |
Local code handles an authored response | Model accuracy, API latency, or real charges |
| Live API call | What happened on one recorded request | General performance across other tasks |
No usable API key was available while preparing this edition. Consequently, an offline result is never presented as a model evaluation. Treat numerical examples as illustrations unless they are accompanied by a real request record. Once you have access, run the same case with --mode live, retain the raw response and model version, and evaluate it against your own labels.
Choose a reading route
New to Jev? Read What is Jev?, Quickstart, Python API, and Question design in sequence. If your integration works but its decisions disappoint you, start with question design and Confidence and evaluation. If you arrived with one concrete business problem, open the matching case and follow its prerequisite links.
Keep a small judgment notebook as you work. Save the input, your expected result, the sentence in your rubric that supports that result, and the consequence of getting it wrong. A disagreement in that notebook is useful evidence. Repeatedly asking a model to “be more accurate” is much harder to diagnose.
You can complete the design exercises without an account. First establish whether your questions are clear and your code has a sensible fallback. Then use live calls to find out whether the model meets your standard. Keep those two kinds of progress separate in your records.