The source write being committed, the search index seeing it, and the assistant answering with it are three separate events. A successful edit response is not evidence that every search representation is ready. “Immediately” needs a scope. Does this editor need to read their own changed document, do all authorized users need the new policy, or must a query over the whole corpus reflect a coherent release? Those are different guarantees.

For a read-your-writes experience, the source returns an immutable revision token. The query carries at least that revision requirement for the edited object. If lexical, vector, extracted text and citation mapping for that revision are ready within a bounded wait, answer from it. If not, fetch the authoritative source revision and build a scoped, permitted evidence path for that user's question. If this path cannot parse the edit within the promised deadline, the UI must say it is still processing. If product insists that a success response means an immediately answerable edit, the write flow must wait for a supported synchronous evidence path before returning that status. Do not mix a new source snippet with an old exception table and call the result current. A stale indexed revision should be ineligible once the query knows a newer revision is required, even if its embedding is the nearest neighbor.

An Elasticsearch index write can use refresh=wait_for to wait until that write is search-visible. That applies to the specified index operation. It does not wait for an upstream connector, parser, vector generation, second index, or source authorization update. Forcing refresh on every edit can also create costly small segments. I would use a generation or readiness record across the actual stages and only promise the scope that record proves. The overlay path must check current permissions and cite the source revision it read, not a future index URL guessed from the old one.

Now the rule and its exception change together. Per-document read-your-writes is insufficient. The source needs a release or manifest that declares the coherent pair. The query pins that release and waits for both documents, or reports that the new release is not ready. DKS-011 covers that cross-document invariant. For the immediate-edit promise, measure time from source commit to eligible answer, old-revision disclosures after a user's token, overlay usage, and failures that honestly report pending work.