The first of June we shipped langchain-vectorpanda 0.1.0, a LangChain VectorStore wrapper around our Python SDK. The design goal was for it to be boring: a thin adapter with no state of its own, no clever caching, nothing that could disagree with the SDK underneath it. If the wrapper can be wrong about anything, someone's RAG pipeline finds out at retrieval time, which is the worst possible place.
Boring still took real work to prove. The wrapper got the same CI treatment as the SDK itself — unit tests plus a hosted end-to-end that runs against a live cluster with real embeddings, not canned vectors. Add-then-retrieve, metadata round-trips, delete(ids), MMR retrieval, the whole VectorStore contract exercised against actual infrastructure on every push. When a wrapper is this thin, the tests are mostly testing us, and that's the point.
Shipping it also flushed out a default that had been quietly lying. Our cosine scores are raw — the full [-1, 1] range, same convention as FAISS and everyone else — but the SDK's query default was filtering results below a threshold before you ever saw them. Fine for a demo, wrong for a library: LangChain callers asked for k=10 and sometimes got 7 with no explanation. veep 0.5.19 changed the default min_score to -1.0, which is a fancy way of saying "return what I asked for and let me do the filtering." Defaults are API surface. This one had to stop editorializing.
Later in the month the wrapper grew alternative tabs across every code example on the site — anywhere we show you the raw SDK, you can flip to the LangChain version of the same thing. Eleven surfaces, one sweep, so the two ways of using us never drift apart in the docs.