AI Schedule & Recurring Missions

Infrastructure work is not only interactive. Health checks, maintenance verification, recurring diagnostics, patch windows and periodic capacity reviews happen on a clock. AI Schedule lets those operations enter the same STRATUM AI Mission path used by interactive requests instead of creating a separate automation product.

A schedule is not a hidden shell command. It becomes a STRATUM AI request, which means the normal planning, DAG execution, resource controls, verification, evidence and approval rules still apply. Scheduling changes when the request begins; it does not bypass the STRATUM AI operating model.

Open the STRATUM AI Mission overlay from Mission Planner. The calendar icon in the upper-right opens AI Schedule. If a VM or other object is already in AI Focus, STRATUM can carry that current focus into the new schedule as a target snapshot.

1. Select + NEW or choose a calendar day.
2. Enter a human-readable Name, such as Check OpenShift cluster health.
3. Write the AI Operation as an outcome-oriented request. Example: Check all Kubernetes nodes, investigate anything NotReady, and tell me what caused it.
4. Review the Target Snapshot. STRATUM captures the selected focus when the schedule is created so later canvas selections do not silently retarget the operation.
5. Choose the Start date and Time in the displayed timezone.
6. Choose the recurrence: Once, Every hour, Every day, or Every week. Weekly schedules select the applicable weekdays.
7. Leave Enabled selected when the schedule should become active immediately, then choose Create Schedule.

Scheduled work feeds the same AI Mission machinery as an interactive request. STRATUM does not need a second automation engine just because the trigger came from a calendar. The request is planned, resolved against the target snapshot, compiled into Mission work, executed through the existing STRATUM APIs/GuestOps/tooling, and verified.

That matters because scheduled automation inherits the same operational boundaries. A diagnostic schedule can run as diagnostics. If a free-form scheduled request determines that a mutation requires human approval, the Mission can wait for approval rather than silently skipping the protection because a clock triggered it.

Recurring schedules also represent recurrence compactly rather than flooding a month view with repeated entries. Hourly, daily and weekly operations remain understandable as operational intent, not as a wall of cron syntax.

Cluster health: every morning, check Kubernetes/OpenShift nodes, operators, failed pods and recent critical events, then report the cause of anything degraded.

Network assurance: periodically inspect a WAN/application path and use STRATUM topology, guest state and packet evidence when something changes.

Maintenance: run pre-window or post-window validation against a fixed set of systems and record the result as normal Mission evidence.

Capacity: review a selected environment on a recurring basis and surface placement/storage/GPU constraints before they become deployment failures.

The important design rule is simple: a schedule says when to ask STRATUM AI to do something. It does not grant new authority. Operator permissions, AI Studio policy, no-go zones, approvals and verification remain part of the Mission.

The target snapshot is captured at schedule creation so an operation configured for one system does not follow a different object merely because the Mission Planner selection changed later.

The calendar shows the active scheduled operation, its captured target, recurrence and next execution context. When it fires, STRATUM creates a normal AI Mission so the operation remains visible, governed and verifiable like manually initiated AI work.