A merged mailbox log that reads A1, B1, B2, A2 tells you less than it seems to.
Plain Erlang messages, no priority reception, one receiver matching all four events with the same pattern. A sends A1, then A2. B sends B1, then B2. Signals from one sender keep that sender's order, and that is the only ordering on offer. The log above respects both senders.
Now move B1 one step earlier, ahead of A1. Both orders still hold. So seeing B1 after A1 doesn't mean B acted because A1 was processed. B may never have known about A1.
If B1 really depends on A1 being handled, the protocol has to carry that link. A log reader shouldn't have to guess it. Per-source sequence tags plus an explicit reference to the triggering event would do it, with arrival order read as arrival order and nothing more.