Scheduled install automatically rebooting and installing if a machine comes out of sleep and scheduled time is missed.

[GWSparx]

I’m seeing an issue with scheduled installs and wanted to check whether this is expected behaviour or a bug.
We’re using ScheduledInstallUserChoice so users can pick a specific date and time for a macOS update.
The issue is:
the user gets the update prompt

instead of clicking defer, they click Schedule
they choose a future date/time
when that scheduled time arrives, the Mac is asleep / lid closed / locked
when the user next logs back in, the update is immediately forced rather than giving them the chance to reschedule or defer again
What I was expecting was:

if the scheduled time is missed because the Mac was asleep or unavailable, the user would be prompted again and allowed to choose another time
not go straight into an enforced install as soon as they return
In our case, the device has not yet reached the intended “force now” user experience for a missed scheduled appointment, so this feels more aggressive than expected.
Has anyone else seen this behaviour, and is there a recommended way to make a missed scheduled install fall back to another prompt/reschedule instead of forcing immediately on next login?

I checked the log and the macOS update itself completed successfully.
What happened:

SUPER detected a scheduled update to macOS Tahoe 26.4 for 12:05.
At 11:59 it showed the user a warning/reminder dialog, and the user dismissed that dialog at 11:59:59.
Dismissing the dialog did not cancel the update and the user locked their screen / went for lunch.
When SUPER checked back at 12:59 (they unlocked their device), it saw the scheduled install time had passed and kicked off the update through Jamf/MDM.
The update command was accepted successfully, the Mac rebooted, and it came back up at 13:04:46 on macOS Tahoe 26.4.
So the outcome is: the device did update successfully from 26.3.1(a) to 26.4.
The only error afterward was SUPER failing to parse the post-update mdmclient available-updates listing. That looks like a follow-up status check issue after the machine was already on 26.4, not an installation failure.
One separate thing to note: the log also shows automatic installation of macOS security updates is disabled, which is a policy/configuration risk but not what caused the update flow here.