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¶
These settings control how your observation repeats, how its measurements are grouped in time, and when it runs. For what each one means and exactly how Skynet schedules it, see Scheduling & repetition.
| Field | What it does |
|---|---|
| Epochs (visits) | How many times to revisit the whole target. 0 repeats indefinitely until you cancel. |
| Keep together | The largest unit that must run without interruption — one capture, one measurement, a segment (all of one request, or one sample of every request), the whole visit, or the whole observation. |
| Sample ordering | Finish each request before the next, or take one sample of every request and repeat. Also sets the shape of a segment. |
| Cadence | How far apart repeats run: as soon as possible, once per calendar night/day, or a recorded minimum gap / fixed period. |
| Start window | The observation isn't eligible to schedule before this time. |
| Cancel window | The observation is auto-canceled if not started by this time — useful for time-sensitive triggers. |
| Interrupt lower priority | Lets this observation preempt a running observation of lower priority on the same instrument — only when the telescope account allows interrupts. |
| On interruption | Resume from where an interrupted unit stopped, or restart it. |
The default keeps each whole visit together while allowing gaps between visits — choose a coarser unit when the science needs an unbroken run, or a finer one for more scheduling flexibility. The editor keeps your choices consistent and won't let you build a contradiction (such as requiring the whole observation to run uninterrupted while also asking for one visit per night).
Instruments¶
These fields decide which instruments are eligible to fulfill the observation and how copies are produced.
| Field | What it does |
|---|---|
| Copies | One dataset, a copy on every eligible instrument, or a fixed number of instruments. |
| Coordination | Only when copies > 1: schedule each copy independently, or record that they should start together. |
| Instrument may change | Keep one instrument for the whole observation, or let it vary per request/visit. A recorded handoff timeout governs when an interrupted unit may move to another instrument. |
| Instrument access mode | Any instrument from the selected grants (none), only the listed instruments (include), or any except the listed ones (exclude). |
| Instrument list | Used when access mode is include or exclude. Disabled when access mode is any. |
The default — copies = single, affinity = observation, access mode
none — lets the scheduler pick one best-fit instrument from whatever
your grants reach. Restrict only when you have a specific reason (a
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, epoch_count, cohesion_level,
sample_ordering, cadence_kind (+ cadence_level / cadence_gap_sec
/ cadence_period_sec / cadence_calendar_unit), start_after,
cancel_on, interrupt_lower_priority, interrupt_recovery,
copies_mode (+ copies_count), coordination_kind (+
coordination_start_tolerance_sec), affinity_migrate_at (+
affinity_handoff_after_sec), instrument_mode. The per-request
sample count (sample_count) lives on each request.
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.