How Maya delivers your documents.

What you actually see.

A typical exchange. You ask a question about your own record. Maya finds the document, answers from it, and shows you the source so you can read it yourself.

No clinical interpretation. No inference. Navigation back to the document, with the relevant excerpt and a citation you can verify.

Three views of the same document.

Your medical records arrive from each health system as FHIR DocumentReference resources — structured records with metadata (date, author, type, encounter) and the document content itself.

For every document, Maya stores three views — and queries all three in parallel when you ask a question.

The three views compensate for each other's weaknesses. Structured FHIR is fast but only tells you what fields contain. Raw text catches exact phrases but misses synonyms. Semantic embeddings catch meaning but can drift. Used together, they give Maya the best chance of finding the document you are actually asking about.

The queries, in full.

What follows is the structure of a real document retrieval. The schemas have been simplified for readability, but the logic is the logic.

Step 1 — Candidate selection by metadata

SELECT
  doc_id,
  document_date,
  document_type,
  author_name,
  encounter_id
FROM document_references
WHERE patient_id = :patient_id
  AND document_date BETWEEN :start_date AND :end_date
  AND (
    document_type LIKE '%' || :type_filter || '%'
    OR :type_filter IS NULL
  )
ORDER BY document_date DESC;

This query runs against a SQLite file that lives on your own hardware. There is no network call. There is no cloud lookup. The file path itself encodes patient identity — each patient has a separate database, and the application binding to one cannot read another.

Step 2 — Pull raw text for ranking

SELECT
  d.doc_id,
  d.document_date,
  d.author_name,
  d.document_type,
  t.raw_text
FROM document_references d
JOIN document_text t ON d.doc_id = t.doc_id
WHERE d.doc_id IN (:candidate_ids);

Step 3 — Semantic ranking against per-patient embeddings

# The collection name is bound to patient identity
# at the application layer. There is no shared collection.

hits = qdrant.search(
    collection_name=f"leptonx_memory_{patient_id}_v1",
    query_vector=bge_m3_embed(user_question),
    limit=10,
    score_threshold=0.65,
    with_payload=True
)

The collection name is constructed from patient identity at the application layer. There is no shared collection. There is no path by which one patient's documents could be returned to a query running in another patient's session — and per-patient isolation has been confirmed bidirectionally across every collection in the system.

Step 4 — Reranking and synthesis

reranked = bge_reranker.rank(
    query=user_question,
    documents=[h.payload["text"] for h in hits],
    top_n=3
)

context = build_context(reranked, max_chars=8000)

# Maya is invoked with a system prompt that requires
# every claim to be grounded in `context`. If `context`
# is empty, Maya is required to say so.

A navigator, not a chatbot.

This is not a model trained to sound knowledgeable about your records. It is a structured navigator over your own data, operating entirely on hardware you control.

The architecture rests on three concepts we have built the platform around:

You do not trust Maya because we said so. You trust Maya because you can read the queries she runs.