openjev-router-lora

OpenJev healthcare router, LoRA adapter

An 87 MB rank-16 adapter on Qwen3-1.7B that beats the commercial typed-decision API it was benchmarked against, from 395 training examples and 258 seconds on one GPU.

Ten questions answered in a single forward pass over the shared message: one intent choice, five multi-label noul topic flags, four safety gates.

from openjev import DecisionModel, Choice, Noul

model = DecisionModel.from_pretrained("s1lv3rj1nx/openjev-router-lora")

out = model.answer(
    "I need a refill on my thyroid tablets, and are you open on Sunday?",
    {
        "A_intent": Choice(
            instructions="Which single topic does this pharmacy message concern?",
            criteria={"refill": "asking us to dispense another fill of an existing prescription",
                      "store_hours": "when a branch is open",
                      "order_status": "where an existing order is"}),
        "C_store_hours": Noul(instructions="Does this message ask about when a branch is open?"),
        "G_clinical": Noul(instructions="Does this describe a clinical symptom?"),
    },
)
out["A_intent"].label                       # 'store_hours'  p = 0.85
out["C_store_hours"].probabilities["true"]  # 1.000
out["G_clinical"].probabilities["true"]     # 0.000

That output is worth reading closely. The message contains two intents, a refill and an opening-hours question, and A_intent can only return one of them — here it picks store_hours. The noul flag catches the other at 1.000. This is exactly why multi-label routing uses one noul per label rather than a single choice: a softmax over intents cannot say "both", and on three-intent messages that difference is 0.903 against 0.645.

pip install git+https://github.com/S1LV3RJ1NX/openjev. The adapter is merged into the base weights on load, because leaving it unmerged costs about 2x at inference for nothing.

Measured against jev-1.13.0

Accuracy on the left, all three systems on the same 450 test items. Latency on the right, whole router in one call. One caveat on that panel: our figures are local GPU compute and the API's 407 ms is an end-to-end hosted call including network, so it is the latency a user experiences and not a claim about the speed of their model.

Paired on the same 450 held-out test items, exact McNemar. Reproduce with scripts/compare_to_jev.py.

Three wins, four ties, no losses.

Why an adapter and not a fine-tune

Every configuration we tried on this task, same data, same 6 epochs:

Adapting 17M parameters beats opening 1,725M, at a thirty-ninth of the size. The likely reason is the learning rate a full fine-tune tolerates: 1e-5 over six epochs of 395 examples barely moves a 1.7B model, while LoRA at 2e-4 adapts quickly without disturbing the weights it rides on. Neither was tuned past one setting.

It also means one loaded backbone can serve many routers, which a 3.4 GB per-task artifact cannot.

Limitations

Synthetic data. Handwritten and systematically composed pharmacy messages, not real traffic. Evidence the recipe works, not a claim about your users.

The scope gate over-fires. False-positive rate 0.826 on 23 negative examples. It beats the reference API overall and is still the weakest of the four.

One tier cannot prove itself. clinical_oblique has 29 items, so a paired test with zero losses floors at p = 0.0625. The 0.966 against 0.793 is real and not statistically separable.

Not a medical device. The gates flag whether a message mentions clinical content so it can be escalated to a human.

No zero-shot claim. This is fine-tuned on its task. On a schema it has never seen, OpenJev scores well below the reference API, and that is documented rather than hidden.

Related

• Code and full results
• Training data
• General checkpoint for tasks without labels
• Held-out suite

Licence

Apache 2.0. Base model under its own licence.