Skip to content

Search Endpoints

Valter exposes four main retrieval surfaces for jurisprudence work. The important architectural point is that these endpoints belong to a graph-led retrieval system, not a search-first pipeline with a small knowledge-graph boost.

EndpointPurpose
POST /v1/retrieveGeneral jurisprudence retrieval through Valter’s current pipeline
POST /v1/similar_casesSimilar-case retrieval with structural and semantic signals
POST /v1/search/featuresFiltered retrieval over extracted legal metadata
POST /v1/factual/dual-searchSeparate factual and thesis-oriented retrieval views

Use this endpoint when you need the main jurisprudence retrieval experience.

Conceptually, it:

  • discovers relevant material through graph-aware retrieval logic
  • uses search signals as complementary evidence and fallback
  • returns structured results suitable for downstream reasoning, verification, or UI rendering

If you are integrating a strict client, prefer the current runtime schema or generated OpenAPI surface for exact request and response fields.

Use this endpoint when you start from one decision and want nearby jurisprudence. Similarity is no longer just “text looks alike”; it can also incorporate structural evidence from the graph-backed knowledge layer.

Use this endpoint when you need filtered retrieval over extracted metadata such as categories, result labels, or other structured legal attributes.

Use this endpoint when you need to separate factual similarity from thesis-oriented similarity. This is useful for contrastive analysis and for understanding whether two decisions are close because of their facts, their legal framing, or both.

  • Treat POST /v1/retrieve as the primary entry point for jurisprudence retrieval.
  • Treat the other endpoints as specialized retrieval tools built around the same knowledge layer.
  • Avoid describing the whole search surface as “BM25 + semantic + KG boost”; that is no longer the right system narrative.