Hi Kevin, this is extremely helpful — thank you for the depth here. Two takeaways reshape our design: (1) using DiskArb as the primary volume API with ES as a backstop, and (2) treating "copy" as an inference rather than an observable operation. For an audit product, that pushes us toward separating observed facts (rename, clone, open — things ES reports as "true") from inferred semantics (copy, asset movement) that a correlation layer derives. We'll record and preserve the raw events and treat high-level interpretation as a distinct, clearly-labeled layer. One follow-up on running ES in production at scale. Given the message volume you describe on the notify path, is there a recommended approach for keeping an ES client responsive without dropping events — for example, using es_mute_path or related APIs, early filtering of event types, or offloading correlation from the ES callback thread? I want to make sure we don't design ourselves into a position where the client falls behind and events are lost; for an audit product, a dropped event is a gap in the record. Thanks again — this has been genuinely valuable. Kei