A path is a location and a useful display name. It is a poor identity when a file can move. The same document can change paths without changing content, and a new document can later reuse the old path. If the connector calls every move a delete plus create, it may duplicate embeddings, lose citation continuity, and carry an ACL snapshot across a boundary where the inherited permissions changed. The cached answer is also an authorization problem if it contains private text, not just a broken link.

I would see what stable identity the source actually provides. Many systems have an object ID and a separate name or parent relationship. The Google Drive files API, for example, exposes a file ID, name, parent and metadata as separate properties. The connector should key a source object by tenant, source instance, and source object ID, with a source revision or observed content hash for its version. A chunk gets that object identity plus content version, parser version, and local span identity. Path and display title become versioned metadata, not primary keys.

A move may leave content bytes unchanged while changing the authorization context. I would update the parent relationship, effective permission reference, and current display path together in the document registry. Search can use the new path for navigation and filters after that update. Serving must check the permission that applies now before a snippet, citation preview, or cached answer is shown. Do not assume the old chunk's inherited ACL is still safe while an index update catches up. The canonical source link should resolve through the current object ID and current authorization, not a saved public path string.

Migration needs a mapping, not an optimistic rekey. Build path-to-source-ID correspondence from source metadata or a full crawl, identify collisions and reused paths, and validate the mapping before switching citations and deduplication. Keep an alias from an old citation ID to the same source object only where identity is proven. If an old path was reused by a different file, do not redirect the citation to that file. Purge or re-scope answer caches carrying old text according to their content and permission versions. During the cutover, one active source object should have one active search generation. A partial reindex cannot make both path IDs independently answerable.

What if the source only exposes a path tree and gives us no stable ID? Exact move detection is not generally possible from a before-and-after crawl. A byte-identical file at a new path could be a copy, and a moved file can be edited in the same interval. I would use source change events or an explicit move operation if available. Otherwise treat identity matching as a hypothesis with confidence, keep distinct object incarnations where ambiguous, and avoid silently reusing permissions or citations. A content hash establishes byte equality, not object identity.

Now suppose it was a copy, not a move. The copy has a new object identity even if its bytes match. It may inherit a different parent ACL and have its own deletion and retention lifecycle. Deduplicating storage of identical bytes is an internal optimization, but access checks and citations must still name the correct source object. I would test rename, move across restricted folders, copy, path reuse, and delete immediately after move before calling the migration sound.