mining.notify not as expected

Not sure if this is the right forum, first post. Please redirect if necessary.

I have used tcpdump to look at the rpc traffic from 2 different BTC pools to one of my S9's and find that the mining.notify data is not what I expected.

mining.notify contains the following fields

job ID
previous block hash
coinbase 1
etc...

coinbase 1 has embeded within it the current block number being mined.

So... I have captured the mining.notify from 2 different pools, 3 different blocks as show below. The previous block hash sent in the mining.notify string. The actual previous block hash found using the blockchain.com block explorer.

In each case, there were no blocks found between the time the sample was taken and when the next block was found. The third sample actually overlapped the finding of the block and the block was found by the sampled pool (Viabtc)

Note: mining.notify string is bytewise reversed for comparison to block explorer value

562087
mining.notify 00000000000000009e941400689b3885952ddf6f748976d233878a1791bb6a58
block explore 00000000000000000014949e85389b686fdf2d95d2768974178a8733586abb91

568798
mining.notify 000000000000000014b83e00dde48af647d5c4c9a8a42b3dad157be5d6103f12
block explore 0000000000000000000a90fd6cf2c6796756bbfd224475cf24ca9bfd6b183dc1

584034
mining.notify 0000000000000000ad5601009f6dccd0feb624bb7f2389326f17decfe3aedec4
block explore 0000000000000000000156add0cc6d9fbb24b6fe3289237fcfde176fc4deaee3

It was my assumption that the previous block hash (a block already found) would be immutable.
In addition, the block explorer says that the mining.notify values are "not found" in any blockchain.
What am I missing? Can someone shed some light on this for me? I do not see how it is possible
for the miner to calculate a valid hash solution when the PBH is not the value that is in the final block
hash solution.