name: scheduler-validation description: Scheduler validator driven by ValidationHook — read-only static verification of scheduled jobs (schedule correctness, configuration, runtime context already collected by deterministic hook). Does not trigger test runs. tags:

• scheduler
• orchestration
• validation
• data-engineering

version: "2.0.0" user_invocable: false disable_model_invocation: false allowed_agents:

• scheduler

kind: validator severity: blocking mode: llm targets:

• type: scheduler_job

Scheduler Validation

Driven by ValidationHook.on_end for scheduler runs. The hook passes a SessionTarget containing every SchedulerJobTarget the run delivered. Iterate each target and run the checks below.

Target shape

You receive SessionTarget.targets — loop over SchedulerJobTarget entries. Each carries platform + job_id + optional job_name.

Layer A (the builtin hook) has already confirmed each job exists and is not in a failed status. When the scheduler profile exposes runtime tools, ValidationHook has also deterministically triggered the job once, polled list_job_runs, and attached a scheduler_job_trigger_run precheck before this skill runs. Your job is to verify schedule correctness, configuration, and any runtime context already present.

Core workflow

Read-only static verification. Never trigger a test run from this LLM validator. Runtime triggering is deterministic ValidationHook code, not a model decision.

For every SchedulerJobTarget in the session:

1. Verify schedule — call get_scheduler_job(job_id) and confirm the

schedule expression matches the intended cron (e.g. user asked for "daily" but job submitted 0 * * * *).

1. Verify configuration — check other fields returned by

get_scheduler_job (description, SQL path, job_type, connection id) match the intended setup.

1. Inspect most recent run, if any — call list_job_runs(job_id, limit=1).

• No runs yet → advisory note "no runtime history; user-initiated trigger

required to verify runtime health". Not a blocking failure.

• Latest run success → report the success.
• Latest run failed → call get_run_log(job_id, run_id), surface the

error as a blocking finding so the user can fix before the next schedule window hits.

• Latest run running → advisory (in-progress; can't judge yet).

Validation checklist (per job)

Output format

Report a table with these columns:

If the latest run failed, include the error message from get_run_log so the user can diagnose the issue. Never call trigger_scheduler_job.