How it works
No model in the loop. That is the feature.
HLA-Verify is not an assistant, a classifier or a fine-tune. It is a lookup engine over a pinned release of IPD-IMGT/HLA, plus the resolution rules a laboratory would apply by hand if it had time to apply them to every name in every report.
The pipeline
Tokenize
Every allele-shaped token in the input is extracted — free text, a report, a JSON blob, a model's answer. Locus-prefixed names in any era's format, plus G and P group names.
Classify
Each token is resolved against the pinned release and its full rename history back to 1.05.0. One of five verdicts comes back, with the successor name where one exists.
Resolve & flag
Valid and deleted names also get a current 2-field reduction, a G group (or AMBIGUOUS/NONE), and clinical flags — null allele, deprecated name, ambiguity.
The five verdicts
The whole vocabulary. Anything shaped like an allele name lands in exactly one of these buckets.
| Status | Means | Example |
|---|---|---|
| valid | Assigned in this release, or a valid lower-resolution prefix of assigned alleles | B*15:504:01 |
| group | A G or P group name that exists in this release | DQB1*05:03:01G |
| deleted | Was assigned once, is not current — returned with its successor | A*0101 → A*01:01:01:01 |
| fabricated_group | Shaped like a G/P group, but no such group exists | P*24:02 |
| hallucinated | No such name in any release back to 1.05.0 — invented | DQB1*05:03:26:99 |
A response is "clean": true only when there are no hallucinated names, no fabricated groups and no deleted names in the input.
Why determinism is the product
It cannot hallucinate
There is no generative step to hallucinate in. Every field in every response is read out of the reference files or computed from them by fixed rules. The failure mode of a language model checking a language model does not exist here.
It cannot drift
Same input, same release, same answer — today, and in eighteen months when a study or an audit asks why a name was mapped the way it was. No temperature, no sampling, no silent model swap underneath you.
It is pinned, not "latest"
You name the release. Reference files are fetched at runtime and MD5-verified against the release's own checksum file before anything is answered from them. Moving to a new release is your decision and a visible event.
It is auditable end to end
Every response carries the release it was computed against and the source attribution. The grading engine behind the API is the same engine that produces HLA-Bench-A, which is published in the open.
What is behind the pin
Figures below are read from IPD-IMGT/HLA release 3.65.0, the release HLA-Verify currently pins by default.
alleles
Assigned in release 3.65.0 across all loci.
releases of history
Name history is resolved back to 1.05.0, so a name from any era can be traced forward.
deleted names
Of which 267 resolve to a named successor; the rest are reported as deleted without one.
G groups
Plus 1,563 P groups, loaded from the WMDA nomenclature files of the same release.
new alleles per quarter
Which is why "the model knew this at training time" is not a durable answer.
Where it sits in your stack
- As a guardrail. Between an LLM feature and whatever the laboratory sees. If the model's output is not
clean, do not show it — or show it with the fabricated token marked. - As a batch normalizer. A column of typing strings collected over twenty years in, current names plus 2-field reductions plus G groups plus flags out.
- As a report check. Run finished reports through
/v1/verifybefore sign-out and catch the deprecated name that survived a copy-paste. - As a fact lookup.
/v1/allele/{name}for G group, P group, serology, first release and confirmation status, without scraping anything.