Hi Kevin and Quinn, Thank you for the clarifications about subtree retention, kernel fork/exec coverage, configuring before launch, sync callbacks during client destruction, and audit-token cleanup. We also understand your answers that loss cannot precede the first received message and that a sync callback does not detect a dropped tail. We have narrowed the remaining design question to two alternative closure arguments, plus the event/identity mapping they both need. This remains a design inquiry; we have not tested an entitled prototype. The proposed client would establish subscriptions and required event visibility before launch, register the initial workload before considering completion, and carry each registered process's outstanding obligation across exec identity transitions. It would check every received subscribed event type in the same global sequence before filtering, reject gaps or ambiguous identities, and remove a registered process only on its matching exit. Default and per-event muting must be accounted for separately: we would not assume that an event suppressed before numbering produces a sequence gap. Sync validation would require the same live client and completed state application, excluding destruction-triggered callbacks. 1. Can creation-before-creator-exit ordering make notification loss fail closed? Is there a supported relationship in which a child's creation notification is assigned a position in the client's global sequence before its creator's exit notification, including a whole-process exit racing creation on another thread and the vfork/posix_spawn paths? Given that ordering relationship, our conditional reasoning is: if a registered creator's child-creation notification is lost, a later delivered creator exit exposes that missing sequence position and forces failure; if the creator exit is also lost, its registry entry prevents success. Longer missing chains reduce to the first missing creation below a registered ancestor. This depends on complete visibility, registration of the initial workload before any completion check, correct linkage across exec identity transitions, dropped notifications consuming sequence positions, and processing consistent with that sequence. For the start of the stream, we rely on your answer that loss cannot precede the first received message; we do not assume an initial counter value. It is our reasoning, not a claim about Darwin. Under those premises, a sync marker adds at most a processing barrier, not a separate causal guarantee. Does this identify a supported basis for the ordering alternative, or is that relationship something applications must not rely on? We are not asking for every child event to arrive after its creation event; unmatched events can conservatively fail the run. 2. Alternatively, what configuration and sync boundary support closure without that ordering premise? You advised that deadline configuration can prevent dropped messages. We understand your guidance that baseline delivery is intended to deliver all messages, that clients must process events fast enough, and that multiple clients can help with critical messages. We are trying to distinguish that throughput guidance from a supported safeguard for NOTIFY-only delivery. The header provisions we found describe AUTH deadlines and denial when an AUTH queue is full, while fork and exit are NOTIFY-only. For a descendants client subscribed only to NOTIFY fork/exec/exit, what configuration, if any, prevents required notification loss beyond keeping the handler fast enough or adding parallel clients, including when the queue fills or the workload forks without exec or another AUTH-producing action? If there is no such safeguard, is a sequence gap the supported loss signal to rely on, subject to the first-message and undetectable-tail limits already discussed? We credit the sync guidance for actions completed before marker placement. The remaining frontier is concurrent or in-flight creation when the last registered creator's exit has been applied and the closing marker is placed. What supported boundary excludes an unregistered surviving child whose creation notification falls beyond that marker? We are not treating waiting or callback arrival alone as proof of completeness. 3. Which notification records and identities link vfork/posix_spawn children? Given your explanation that creation passes through kernel fork/exec, which notification records and identity fields should register and link a child across vfork or posix_spawn and any exec transition, including a child that exits without successful exec? How do those records relate to child start and any vfork parent suspension/resumption where relevant to registration? We are not assuming a particular notification sequence or unchanged execution identity from the fork/exec explanation alone; the ordering question is in (1). Questions (1) and (2) are alternatives; (3) is shared. A documented reference, applicable macOS/SDK versions, or a clear indication that an application must not rely on a premise would help us bound the design. We would continue to report failure where completeness cannot be established. Thank you.

Hi Kevin, Thank you. I checked ESClient.h, ESMessage.h and ESTypes.h. The caller-notification scope answers my initial-launch question: I meant the observer creating its first workload after subscribing. I also understand your clarification about client destruction; we would retain the same live client through the drain and invalidate our run on shutdown. The remaining question is whether we can soundly conclude that no workload descendant remains alive, rather than relying on likely delivery timing. This is still a design inquiry; we have not tested an entitled prototype. 1. Notify ordering and an empty registry The headers mark fork and exit as notify-only. ESClient.h documents synchronous enqueueing before a syscall returns and serial handler delivery. We would configure visibility before launch, process fork/exec/exit notifications serially, account for exec identity transitions, and reject sequence gaps or unmatched events. We would not test for completion until the initial launch had been registered and drained. For a tracked parent P that creates C and exits, is C's fork notification guaranteed to be enqueued and delivered before P's exit notification and before any notification from C, including when C exits without exec? Or is additional ordering logic required? Specifically, with the same live client, can an empty registry followed by a completed es_sync_client drain and no detected loss still coexist with an unregistered live descendant? We would not treat an AUTH event as a substitute for a missing fork notification. 2. Sequence boundaries I understand the counters detect gaps between delivered messages. What initial counter value should a newly subscribed client expect, so loss before its first received message is detectable? Does a sync marker provide any way to detect dropped messages after the last delivered message? If not, is the registry argument sufficient because a missing exit leaves a registered process outstanding, or can a missing creation notification defeat that argument? 3. Exit and timeout cleanup The linked XNU revision calls mac_proc_notify_exit at line 2488. To disambiguate my earlier two-part question: once NOTIFY_EXIT is delivered, can that process still execute user code or initiate new writes? We are excluding storage durability and previously delegated work from this claim. On timeout, we want to terminate any surviving descendant without accidentally signalling an unrelated process that reused its PID. A descendant might have been reparented, so the observer cannot necessarily wait on it. Is there a supported public way to signal that process using a stable lifetime identity? If not, we would report cleanup as unconfirmed rather than claim closure. Please identify the applicable macOS/SDK versions for these guarantees. We understand that signing requires a bundle; this is not an entitlement application. Thank you.