Waiting for the Reindex

## Two events, not one The common wrong answer here is that corpus poisoning takes effect when the attacker writes. It does not. Writing puts bytes into a **source system** - a document-management share, a wiki, a ticket queue. Answering uses an **index**: a store of vectors, each built from a chunk of text that some pipeline extracted, split and embedded earlier. A first-stage similarity search compares a query vector against the vectors that exist *right now* in that index. A document that has never been through the pipeline has no vector, occupies no position in that space, and cannot be returned at any rank. So the interesting quantity is the gap between those two events, and who owns it. ## What sits between the write and the answer A typical batch pipeline over a shared drive walks roughly this path: | Stage | What it does | What it can drop | |---|---|---| | Crawl | enumerates files in the folders in scope | anything outside scope | | Extract | turns bytes into text | files it cannot parse | | Chunk | splits text into passages | nothing, but it moves boundaries | | Embed | encodes each chunk into a vector | nothing normally | | Index | writes vectors and metadata into the store | superseded or filtered records | Every one of those stages runs at build time, not at write time. A nightly cadence means the passage's earliest possible activation is the next run of that job; a weekly cadence means up to a week. If the pipeline only rebuilds folders it detects as changed, or only re-embeds when a model or configuration changes, the window can be longer still. None of this is a defence somebody designed against poisoning - it is ordinary batch-pipeline mechanics that happens to govern the attack's delivery date. ## The attacker's clock is not the attacker's The consequence for the person doing the writing is severe and specific: the activation date belongs to an operations schedule they cannot read. They cannot bring it forward, and unless they can query the assistant they cannot tell when it arrived. A plant written on Tuesday afternoon might answer on Wednesday morning, or never - because extraction failed on the file type, because the folder was out of the crawler's scope, because a curation step in front of the corpus discarded it. From outside, **a file that was silently discarded and a file that is merely waiting look exactly the same**: both are still sitting on the share. This is why the write is a bet rather than an operation. The attacker pays up front - a document that exists, is attributable to whatever account uploaded it, and sits in a place people can find - in exchange for a possible effect at an unknown later time. ## The same latency running backwards The second half of the point is the one that surprises people, and it matters more than the first. When somebody finds the planted document and deletes it from the share, they have changed the *source*. The index still holds the chunk and its vector until the next build regenerates the index without it. So for the length of that window, the assistant can keep quoting a passage whose file no longer exists anywhere a person can look at. "We removed the document" is a statement about the share; it is not yet a statement about what retrieval can return. Anyone triaging the incident has to say which of the two they checked. The symmetric framing is the thing to remember: **the index reflects the sources as of the last build, in both directions.** Additions are late; deletions are late by the same amount. ## What each observation actually proves - The document is on the share -> the write landed on the share. Nothing more. - The assistant quoted it -> a chunk from it was in the index and was retrieved for that query. It does not tell you when it was ingested. - The assistant did not quote it -> the current index returned no matching chunk for the query that was tried. It does not prove the document was rejected, and it does not prove it will never be indexed. - The file was deleted -> the source no longer holds it. The index may still. Getting these directions right is most of the value of the topic. A candidate who says "we deleted it, so it is fixed" has skipped a whole build cycle, and a candidate who says "the poisoning starts as soon as you upload" has skipped the pipeline.