Jev_Ontology

Only as in-sample confidence movement on authoring tickets. The WrongfulCharge addition moved three hedged tickets from 0.56-0.68 to 1.000, but accuracy and significance were not established and one fix opened a new gap elsewhere.

The LLM authors structure infrequently and Jev classifies at volume against it as state, with no retraining when the ontology changes. Jev signals like low confidence or zero-traffic classes feed the next LLM revision.

Mean confidence crept from 0.940 to 0.948 with flagged tickets falling 3 to 2 to 2 and only one leaf change in 52 tickets. That is diminishing change on this set, not proof of a steady state or error floor.

Run unittest discovery from the root for offline suites; the paid live smoke check needs TYPESAFE_API_KEY and fails nonzero on missing keys or invalid answers. The project is now pivoting toward image classification in Images/.

Five session groups used 204,325 input tokens for 190 classification passes, about $0.0085 at the rate recorded at the time. That estimate excludes ontology authoring, human review and operations, and the README flags that the performance and pricing figures are historical assumptions from the original experiment rather than current provider guarantees.

As of its 2026-09-22 pivot it is moving to the visual side: classifying images in a university library collection against a revisable taxonomy with the same LLM plus Jev cascade, in the Images/ sub-project with its own README and LIBRARY.md plan. The support-ticket ontology work stays in the repository as the exploratory record it is.

No. They constrain the output vocabulary and nothing more: they do not prevent confidently wrong classifications, malformed responses or transport errors. That is why the runners validate response shapes and values before accepting a result, and why the jump from 0.560 to 1.000 confidence after adding WrongfulCharge reads as a hint the new class may be too broad rather than as a win.