The Delta table deleted a customer row. Why does vector search still return it?

“Continuously” is a process mode, not evidence that this delete reached the query. The table and index are two different serving views. Delta can make version 42 visible to its own readers while the search index still contains a representation from 39. Databricks describes Delta table versions and incremental index synchronization as separate mechanisms. Their exact service guarantees depend on configuration. Our application cannot infer atomic publication between them from those descriptions.

I would separate normal freshness from urgent serving denial. Every index hit carries a stable source row ID, source table version or last applied change, tenant and a reference to its content revision. At answer time, before the model receives the text, the evidence gateway checks the current deletion and permission state from an authoritative path or a revocation ledger with a guaranteed effective boundary. A deleted row is denied even while the index is catching up. For a batch of hits, this should be efficient and bounded, but the correctness contract is the same. If that check is unavailable for sensitive data, do not emit the hit. Filtering stale text after it has entered the model context is too late.

The index still needs to converge. Consume table changes with row identity and version, apply updates and tombstones idempotently, and track a durable applied watermark per partition or generation. A global “version 42 applied” flag is misleading if one partition failed. Reconcile against the table and test restore from a snapshot so a stale index copy cannot resurrect the row. Databricks' change data feed documentation describes row-level changes for downstream synchronization. The index design must still handle retries, schema changes and retention of the change stream. A source table deletion can be represented by metadata such as deletion vectors, so scanning old physical files directly is not a valid current-table read.

Now consider a user who asks what the support case said last week. Time travel can be a legitimate product feature if retention, access and the deletion reason permit it. An ordinary update to a row may allow a historical query pinned to version 39. A privacy deletion or access revocation may prohibit showing it even for historical queries. The query plan needs an explicit historical authorization rule, not an index toggle called include_old. Do not assume a past table snapshot grants present access to its contents.

For a report that joins a structured table value at 42 with a retrieved summary from 39, pinning each source to a documented version and checking whether their meanings can coexist is necessary. If the report needs one coherent table version, either wait for the index to reach the required version or retrieve candidate IDs from search and hydrate text from the table snapshot at that version, rejecting rows that are absent. Candidate recall can suffer while the index lags, so this is not a complete substitute for synchronization. It is a way to avoid quoting a deleted or altered row. How do you stop an answer from mixing two document versions? covers two documents in one policy release. This case crosses a transactional table view and an asynchronously maintained semantic index.

The incident response finds every answer that used the stale row, stops new disclosure, and follows the correction and notification path appropriate to those exposures. Test delete, update, permission loss, replayed change, failed partition, index restore, and a historical query after privacy deletion. Measure not just average sync lag but the maximum age of a served hit and the time from deletion acknowledgement to last permitted disclosure.