Add Inspeximus document store integration

[DanceNitra]

Adds a Document Store integration page for Inspeximus (MIT, on PyPI as inspeximus).

InspeximusDocumentStore implements Haystack's DocumentStore protocol as a drop-in for InMemoryDocumentStore, with two differences that matter for long-running or regulated pipelines: it persists to a file, and its delete_documents removes the value from disk (with receipts enabled, leaving a signed, content-free tombstone so a deletion is provable).

It is a faithful drop-in — the duplicate policies (SKIP, OVERWRITE, NONE, FAIL) match InMemoryDocumentStore exactly (captured from the reference, not guessed), and filtering reuses Haystack's own document_matches_filter, so FilterRetriever and pipeline serialization work unchanged. Parity is verified in CI against InMemoryDocumentStore, operation by operation, with a falsification control that must fail.

The usage example in the page was run end to end against haystack-ai 3.0.0 and inspeximus 1.29.0, and produces the output shown.

No logo included for now; happy to add one if you'd like it before merge.

This page was drafted with AI assistance; a human reviewed it and ran the example.

[vercel]

Someone is attempting to deploy a commit to the deepset Team on Vercel.

A member of the Team first needs to authorize it.

[Copilot]

Pull request overview

• Adds a new integration documentation page for the inspeximus Python package, describing InspeximusDocumentStore as a persistent, file-backed Haystack DocumentStore with provable deletion semantics.

Changes:

• Adds integrations/inspeximus.md with overview, install instructions, and end-to-end usage snippets.
• Documents persistence + receipted erasure behavior and positions it as a drop-in alternative to InMemoryDocumentStore.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[kacperlukawski]

Thank you, @DanceNitra Could you please help me understand if the integration comes from an actual need of any user? I would like to know if that's going to be helpful for broader audience.

[DanceNitra]

Honest answer: no, this didn't come from a user request. I built the adapter because inspeximus ships a document store and Haystack was a natural target, and I wanted the "drop-in" claim to be tested rather than asserted — so it runs against your own InMemoryDocumentStore in CI, with a control that deliberately breaks ours and requires the comparison to fail.

But that's an answer about correctness, not about demand, and demand is what you asked about. I don't have a user to point to. If your bar for the integrations catalogue is demonstrated need, this doesn't clear it, and I'd rather you close or park it than have it sit there implying an adoption that doesn't exist.

For what it's worth on the "broader audience" question: the thing inspeximus does differently from an in-memory store is deletion — delete_documents removes the value from disk, not just from the index — plus provenance on writes. That matters to people with a retention or erasure obligation and is irrelevant to everyone else, so it's a narrow audience by design.

Happy either way. Thanks for looking at it.

[DanceNitra]

@kacperlukawski Thanks for the commit. The error was mine, and the autofix corrects it. Copilot
flagged it on 29 July: the paragraph describes a signed tombstone and a provable data-subject
deletion, which is erase_documents(request_id=...) returning an erasure record. The protocol's
delete_documents returns None and takes no request id, so the sentence named the wrong method for
what it described.

The same mix-up does not appear anywhere else on the page. erase_documents is the only method of
ours it calls, and InspeximusDocumentStore the only class. add_component and run are Pipeline
methods.

I could not check one of the page's claims by reading it, so I ran the examples at 5ed457a on
Haystack 3.0.0. Both Python blocks execute:

• the indexing and retrieval example prints ['the invoice is due in March']
• erase_documents returns a dict with coverage, forgotten, ids, residue_in_store,
  scrubbed_links and tombstones
• the erased document's text is no longer in the bytes of documents.json, and the other document
  still is

That last one asserts the text is in the file before the erase, and it requires the second document
to survive, so an empty or truncated file fails it.

Copilot's other finding is still open. It flags version: Haystack 2.0 as conflicting with a 3.0
example. I left the front matter alone: 179 of the 181 pages in integrations/ on main carry exactly
version: Haystack 2.0, one has 2.0+, one has 3.0, and the adapter requires haystack-ai>=2
with no upper bound. If you read the field differently, change it.

On your July question, the answer has not changed. No user asked for this. Since July the page has
been checked against running code rather than my memory of the API, and that is the only difference.
If demand is the bar, closing it is the right call.

Written with AI assistance. I maintain inspeximus, so treat the framing as interested. Everything
above is reproducible from the page at 5ed457a with Haystack 3.0.0.

Rastislav