The evidence gate
A clinical AI emits claims: a phenotype term for a referral note, an alert for a patient, a finding in a consultation note. The gate decides each claim on its own, against the evidence that existed when it was made.
There is no PASS. The gate never certifies a model, and it says so on every call it answers.
Each example below is a note, the terms a phenotype mapper returned for it, and what the gate did with each term. The highlighted words are the evidence the gate found. Notes are written the way they are written in Indian clinics, with English phenotype names inside English, Hindi, Tamil sentences.
a relative's findingEnglish
Proband evaluated for Abnormality of the liver; pedigree chart reveals a maternal first cousin with Neurodevelopmental delay.
scope.attributiona finding the note deniesHindi
Patient ko Thrombocytopenia present hai, lekin Blindness ki koi history nahi mili.
scope.negationa finding only being consideredTamil
Patient-ukku Apnea irukku. Recurrent respiratory infections irukka nu next review-la rule out pannanum.
scope.hypotheticala relative's findingTamil
Patient-ukku Skin rash irukku, ivarudaiya mother-ukku Intellectual disability iruppathaaga family history-il therivithullaargal.
scope.attributiona finding the note deniesEnglish
Child presented for genetic evaluation with no history of Fever; dysmorphic assessment reveals distinct Hypertelorism.
scope.negationa finding only being consideredEnglish
Child brought with complaints of Headache; advised USG abdomen to rule out any suspected Abnormality of the liver.
scope.hypotheticalan ordinary note, nothing wrongEnglish
Child reviewed in paediatric genetics clinic with prominent Growth delay noted on physical examination.
a term with nothing behind itEnglish
The quick brown fox jumps over the lazy dog.
evidence.spanEvery rule came from a defect we measured in a commercial mapper, and each one carries the finding it came from. A customer can ask one question about any decision: which rule stopped this, and on whose authority. The gate makes no model call, so the same note and the same terms always give the same answer, and it cannot invent its own justification.
| Rule | Asks | Action | Source |
|---|---|---|---|
evidence.span | No span in the note supports the term, directly or through a more specific term. | SUPPRESS | audit F1, F11 (vgen-hpo-audit/out/FINDINGS.md): terms emitted with no referent in the input. |
scope.attribution | The supporting span belongs to a family member, not the patient. | SUPPRESS | audit F2: 'His mother has epilepsy' -> Seizure on 3 of 3 runs. |
scope.negation | The supporting span is negated in its own clause. | SUPPRESS | audit F6: 'Denies seizures, headache, or visual loss' -> Headache + Visual loss on 3 of 3 runs. |
scope.hypothetical | The supporting span is raised as a possibility, not a finding. | HOLD | audit F9: planned and hypothesised findings emitted as present. |
qualifier.unsupported | The term carries a qualifier the note never states. | HOLD | audit F8: 'possible mild ataxia' -> Progressive ataxia on 3 of 3 runs. |
evidence.weak | Only a related or broader form of the term appears, not the term itself. | HOLD | audit F10: 'cough and cold' -> Coldness HP:0033850, the case the vendor demo ships. |
Measured on 125 adversarial notes and 60 ordinary ones, every term resolved against the published ontology release (20,413 terms). A violation is a term the note does not support. The last column is the price: terms the note does assert that the gate did not let through. We never publish the first column without it, because a gate that suppresses everything would win it outright.
| Mapper | Unsupported terms | With the gate | Accuracy | With the gate | Asserted terms kept | With the gate |
|---|---|---|---|---|---|---|
| mock | 18% | 0% | 0.255 | 0.255 | 18% | 14% |
| openai/gpt-4.1-mini | 2% | 0% | 0.786 | 0.872 | 78% | 66% |
| google/gemini-3.8-flash | 0% | 0% | 0.474 | 0.477 | 20% | 18% |
On a competent mapper the gate raises accuracy, because the terms it removes were the wrong ones. The keyword mapper is what a rule-based extractor looks like; its accuracy is low before and after, and the gate does not pretend to fix that.
The gate runs in front of a model, so it ships as an endpoint rather than a report. What we publish is public and needs no account: the rules above, the measured numbers, and the gate running on these cases.
GET /v1/rules every rule, with its source and authority GET /v1/benchmarks the table above GET /v1/demo/cases these published cases POST /v1/demo/gate runs the gate on one of them, by case_id
Your own notes need a key. The demo endpoint takes a case id and not free text, so patient data has nowhere to land on an endpoint with no account behind it.
curl -X POST $BASE/v1/gate/phenotype \
-H "Authorization: Bearer ghk_..." \
-H "Content-Type: application/json" \
-d '{"text": "...the note...", "terms": ["HP:0000252", "HP:0001250"]}'Each decision comes back with the rule, the authority behind it, and the span of text that earned or condemned the term. People sign in to a console to mint and revoke keys and to read their usage; machines send a key and never touch it. We record counts. We do not store the text you send.