Step 4 — Configuration
The configuration step covers the observation-wide settings — identity, scheduling, and how instruments are picked. Anything that applies to the observation as a whole (rather than to a specific request) lives here.
Identity
| Field | What it does |
|---|---|
| Name | Display name. Required before you create the observation — the checklist verifies it |
| Public flag | When true, the observation is visible to all Skynet users; when false, only to the owner and grant holders |
| Priority | The observation's priority within its eligible queues — interpreted by the queue's prioritization model |
Priority is relative to other observations on the same queue and the same prioritization model. Setting it to 10 doesn't mean anything in absolute terms; what matters is how it compares to other observations also competing for the same time.
Scheduling
| Field | What it does |
|---|---|
| Iterations | How many times the observation should be repeated. 0 means repeat indefinitely (until canceled). |
| Iteration interval type | fixed (a constant interval between iterations) or once_per_day (run once per local night). |
| Iteration interval | The interval value, in seconds for fixed |
Start window (start_after) |
The observation isn't eligible to schedule before this time |
Cancel window (cancel_on) |
The observation is auto-canceled if not started by this time — useful for time-sensitive triggers |
Interrupt lower priority (interrupt_lower_priority) |
If true, this observation can preempt an active observation of lower priority on the same instrument. Effective only when the assigned telescope account allows interrupts |
| Observing block policy | How to group this observation's requests into uninterrupted scheduling blocks (request_iteration / request_iteration_across_requests / observation_iteration / entire_observation) |
The observing block policy is the most subtle. It controls how the scheduler decides "what's allowed to interrupt what" within the observation:
request_iteration— each iteration of each request can be scheduled independently.request_iteration_across_requests— same, but requests within a single iteration must stay together.observation_iteration— an entire iteration of the observation (all requests, in order) is one schedulable block.entire_observation— the whole observation, including all iterations, must run uninterrupted.
The default is the most flexible — pick a stricter policy when the science cares about uninterrupted sequencing (transit photometry, spectrophotometric runs across rapid filter cycles, …).
Instruments
These fields decide which instruments are eligible to fulfill the observation.
| Field | What it does |
|---|---|
| Assignment mode | observation (one instrument per observation), request (one per request), parallel (multiple in parallel), parallel_synchronized (multiple in parallel, time-aligned) |
| Lock timeout | If a task isn't completed within this many seconds, reassign the instrument |
| Instrument access mode | none (any instrument from the selected grants is fine), include (only the listed instruments are eligible), exclude (any instrument except the listed ones) |
| Instrument list | Used when access mode is include or exclude. The list is disabled when access mode is none. |
The default — assignment mode observation, access mode none —
lets the scheduler pick the best fit from whatever your grants
reach. Restrict only when you have a specific reason (a specific
camera you trust for high-precision photometry, an instrument with a
filter set the others don't have).
Where this maps in the schema
Most of these fields live directly on the
Observation record —
name, is_public, priority, iterations, iteration_interval,
iteration_interval_type, start_after, cancel_on,
interrupt_lower_priority, instrument_assignment_mode,
instrument_lock_timeout, instrument_mode,
observing_block_policy.
The per-request-type configurations (OpticalImagingConfiguration,
RadioTrackingConfiguration, RadioMappingConfiguration) live as
separate records linked from the observation. They're edited on step
3 inside each request's gear dialog rather than here.