Question 1

If the example response is hand-written, what do the tests actually test?

Accepted Answer

The shape of things. The four tests check that the example request parses, that the response carries the typed fields, and that the arithmetic Jev documents — choice distributions summing to one, confidence derived from entropy — comes out right. They need no API key and no network. What they cannot show is whether the live endpoint would accept the request or whether the model would have answered `billing`; the README says both plainly. The fixture exists to show the format, not to assert a classification.

Question 2

Is this official documentation I can trust when the API changes?

Accepted Answer

It is not official. The README states it is an independent reference, not a TypeSafe AI publication, and the prompt it supplies tells the assistant to check the current official provider contract before finalising live integration code, to preserve approved pinned versions, and not to silently switch providers or API formats. Treat it as a well-organised starting point whose API details need re-verifying against the vendor's own docs before you ship anything that depends on them.

Question 3

How do I stop an assistant from claiming my integration works when it does not?

Accepted Answer

The reference is built around a handover file. Section 0.4 is an unpopulated template covering actual files, approved decisions, test results, unresolved issues, stopping point and next action, with unsupported fields left as UNKNOWN. The suggested workflow keeps that template blank in a public repo and instantiates it as a private handover file in your own workspace. The prompts also ask the assistant to separate completed work from planned work, record checks it could not run, and say plainly when it could not save or execute anything.

Question 4

Is the ticket-router example a working service I can copy and run?

Accepted Answer

No, and the README is clear that it is not. It is a worked example: a synthetic customer message, three typed questions about it — which team, whether urgency is explicitly requested, how frustration is expressed — a hand-authored response, and a prompt you can paste into a coding session. The intent is that ordinary code validates the response and applies its own review policy, with automatic routing left off. The README also warns that later automation needs a separately validated policy rather than an arbitrary confidence threshold.

Question 5

What is actually in the repository?

Accepted Answer

It is a documentation repository, not an application, SDK, or deployed service. It holds README.md, Jev_System_One_Reference.md with the API guidance, examples, known limitations, source catalogue, and an unpopulated project handover in Section 0.4, plus LICENSE and THIRD_PARTY_NOTICES.md.

Question 6

What does the ticket-router example ask Jev?

Accepted Answer

Three separate questions about one synthetic message: a choice for which team should handle the issue (billing, technical, sales, or other), a noul for whether the message explicitly requests urgent handling, and a score for how the customer expresses frustration. It stays review-only and keeps automatic routing disabled.

Question 7

Can I see the example's offline tests?

Accepted Answer

Yes. Copy the request, the synthetic response, and the test file from Section 3 into a local folder as request.json, response.example.json, and test_reference_example.py, then run python3 -m unittest -v test_reference_example.py. They validate example structure and internal arithmetic only, require no API key, and do not establish server acceptance or model accuracy.

Jev System One Reference

About this project

Highlights

Questions about this entry

More Jev resources like this

From the Jev guides

From the Jev community