The research question
A sender finishes transmitting an update and receives a transport-level success. The receiving process crashes before it persists the event or applies the corresponding business change. If the sender treats the connection result as final completion, it may discard its retry state while the intended update is absent after the receiver restarts. Bayou explores application-specific conflicts and tentative writes in weakly connected systems. Its relevance here is the need to distinguish delivery, convergence and an acceptable business interpretation when independently edited records meet again.
A concrete design choice
The proposed protocol defines receipts for explicit stages such as durable receipt and committed application. A sender retains work until the required stage is confirmed. The receiver persists the event and the relevant receipt under a clear transaction contract, then reports that state. Reconnecting peers compare durable records rather than inferring completion from how much data a previous socket accepted. The user interface should reflect the stage that matters to the action: delivered evidence, pending application and confirmed business state can legitimately differ. A receipt needs a stable identity so a lost response can be queried without repeating an uncertain effect.
What would demonstrate usefulness
Crash the receiver before persistence, after persistence and after business commit but before the response. Verify recovery and the sender’s next step in each case. The acceptance result should show no loss of acknowledged work and no false completed status based solely on successful byte transfer.