What oscillation looks like
You connect a feed. The booking shows checkout on the 20th. Five minutes later, the 27th. Five minutes after that, the 20th. Nothing changed on the platform — the export itself is inconsistent, most often because two platforms are syncing each other's calendars and each export reflects a different moment of that loop.
Without protection, every flip is a "date change": the job is rescheduled, the cleaner gets a message, the job is rescheduled back, the cleaner gets another message. Lemon's own history includes an SMS storm caused by exactly this before the guard existed.
The guard
When Lemon commits a checkout change it records the previous and new dates in a database table (booking_oscillation_events), so every server in the cluster sees the same history. On the next sync, if the incoming change reverts the previous one or repeats it within 48 hours, Lemon marks it OSCILLATION DETECTED: the stored checkout is still updated so the record loosely tracks the feed, but the cleaning job is not reset and the cleaner is not notified. Once the record is older than 48 hours the feed is trusted again.
Why it lives in the database
Lemon runs on more than one machine. A guard that remembered "the last change" in memory would forget on restart and would not see changes another machine committed. Anything that has to be true across the whole system lives in Postgres.
What to do
If a booking oscillates for more than a day, check whether two platforms are importing each other's calendars in a loop. Connect each platform's own feed to Lemon and remove the cross-import if you can; a direct PMS connection avoids the problem entirely.