How this demo works

chart searches a library of published, de-identified patient case reports (PMC-Patients). Every search feature you see is a hev layer gateway feature — the app posts queries and renders the gateway's decisions. It adds no search code of its own.

Query routing

One box, three retrieval strategies. The gateway's Auto router reads each query and picks hybrid_text (exact/lexical with typo tolerance — a drug, a dose, an abbreviation), fused (both retrieval legs, rank-merged — a clinical phrase), or semantic (meaning-based over the note embedding — a whole clinical picture in prose). Clinical queries are sharply bimodal — token lookups and prose pictures — which is why the decision visibly matters here. The badge above the results is the gateway's own routing decision, echoed back; the demo renders it rather than re-deciding anything.

Docs: Query routing

Hybrid text

The lexical strategy is more than BM25: HybridText fuses exact full-text matching with per-token fuzzy matching, so aspirn still finds aspirin — and when a fuzzy match rescues a result, the gateway says so in the response (surfacing). The fused route runs this lexical leg and the semantic leg together and merges them with reciprocal-rank fusion, upstream of the app. The facet rail's per-search counts come from the same machinery: a scan counts the full match set for the active route, not just the rows on screen.

Docs: Hybrid text fusion · Scans

Agentic search

The Agentic search toggle sends the same query through a configured reasoning loop — a hev layer Agent — instead of the single-hop router. A model reformulates the query into variants, fans them out for recall over the corpus, grades the candidates for relevance, and returns the standard row shape. It is slower and better-ranked, and it shows its work: the sidebar becomes the run inspector (the planned variants and what each contributed), and each hit carries the variant that surfaced it plus its graded relevance. Facet filters don't apply in this mode — the agent infers its own filters, visible in its plan.

Docs: Agents API · Agent resource

Clinical-event cascade (UDF with a self-hosted model)

The Clinical event, Specialty, and Diagnosis facets are not in the source data — they are written back by a user-defined function running an open-weight Gemma model on cluster GPUs (hev layer's Function runtime: self-hosted, scale-to-zero, guided decoding). The cascade reads each note once and extracts clinical events — medication discontinuation is the headline — plus the facet labels in the same pass: one GPU pass, many labels. It composes with routing: an events filter over a routed search answers questions like "who discontinued a statin due to an adverse reaction?". The cascade runs as a backfill; facets appear as it progresses through the corpus.

Why self-host instead of a batch API? The natural baseline for classification at rest is a provider batch endpoint (e.g. the Claude Message Batches API on Haiku, at half of realtime pricing). The cascade beats that baseline roughly 4–5× on marginal cost: one GPU pass derives every label at once, the worker keeps the GPU saturated with continuous batching, and scale-to-zero means idle cost is zero — while the notes never leave the cluster, which matters when the corpus is real clinical data rather than published case reports.

Measured on the real backfill (11,373 notes, ~4 hours, zero failures) via Layer's cost reporting; larger claim sizes leave further headroom.

Docs: Function resource · GPU classifier