The Skynet data model¶

Skynet operates a highly heterogeneous fleet of optical and radio telescopes as a single, coordinated instrument. Making that work requires a common way to describe astronomical data requests, instruments, and observations — so a request can be matched to any suitable hardware in the network, no matter how differently each telescope is designed or controlled.

This page is an overview of that model: how Skynet represents targets, observation configurations, data requests, and results. By describing observations in terms of what data is needed rather than how a particular instrument obtains it, Skynet can schedule one request across instruments that vary widely in capability and control system — and store the results in a consistent, comparable form.

Target Definitions: Specifying Astronomical Objects¶

Observations require precise definitions of targets, which are represented in a unified model applicable to all observation types.

Each target includes a position that can be one of several forms:

Fixed Position – Defined by equatorial (RA/Dec) or galactic coordinates.
Catalog Position – Retrieved from an astronomical catalog.
Ephemeral Position – Time-dependent coordinates for moving objects (e.g., asteroids, comets).
Orbital Position – Derived from Keplerian elements for solar system objects.

Targets may also include models describing the target’s photometric and dynamic properties:

Brightness Model – Defines the target’s brightness and is referenced when calculating exposure times from an optical imaging data request’s target signal-to-noise ratio (SNR). Brightness models can optionally include temporal and spectral components that describe how the target’s brightness evolves as a function of time and frequency.
Saturation Model – Sets upper limits on exposure times to help prevent overexposure and saturation of sources during optical imaging.

Observation Configurations¶

Observation configurations define environmental and operational constraints that apply to specific types of data requests.

Optical Imaging Configuration¶

The optical imaging configuration specifies environmental and field constraints used for all optical imaging data requests. It includes:

Field of View (FOV) constraints
Moon phase and moon separation requirements
Sun elevation and target elevation limits
Tiling and coverage strategy

These parameters ensure that optical imaging observations are scheduled under suitable conditions and maintain consistent image quality across the network.

Radio Tracking Configuration¶

The radio tracking configuration defines parameters for tracking observations, including:

Whether data should be collected on-source and off-source
The separation distance between on- and off-source positions

Radio tracking data requests consist of the following properties:

Spectroscopy windows
Minimum spectral resolution
Polarization requirements
Maximum integration time
Observation duration
Continuum requirement

Radio Mapping Configuration¶

The radio mapping configuration defines how data are collected across multiple pointings to construct a map of a sky region. It includes properties describing the offset pattern used during observation:

Daisy Pattern – Optimized for compact or point-like sources.
Raster Map – Used for larger or extended regions of the sky.

Radio mapping data requests include:

Spectroscopy windows
Minimum spectral resolution
Polarization requirements

These configurations ensure that both optical and radio observations can be defined consistently while remaining flexible enough to accommodate the unique requirements of each observation type.

Observation Requests: A Unified Way to Define Data Needs¶

Skynet defines a unified data request format that lets users specify what kind of data they need rather than how to obtain it.
This separation allows Skynet’s scheduling system to determine which instruments and configurations can fulfill the request, no matter how different those instruments may be.

Optical Imaging Data Requests¶

Can be defined by fixed exposure time or target signal-to-noise ratio (SNR).
When using SNR-based exposure, a brightness model is required.

Radio Tracking Data Requests¶

Include band selection, number of channels, frequency range, and integration time.
Support both high-resolution and low-resolution spectral observations.
Provide configurable options for auto-peaking and auto-focusing.

Observation Results: Consistent, Comparable Data Output¶

Once an observation is completed, Skynet stores results in a consistent structure, so data from different instruments and observatories can be compared and combined.

Observation results may include:

Captured exposures – Raw and processed image files for optical observations.
Spectral data – Spectrograms and calibrated data for radio spectroscopy.
Final result files – Combined or stacked data products after post-processing.

Because results share a common definition, data collected from one observatory can be compared, combined, or analyzed alongside data from another—without translation or reformatting.

Why it matters¶

This model exists to solve one of the most fundamental challenges in modern astronomy: how to make a globally distributed, diverse set of instruments behave as a single coherent observatory.

Without a shared model, every telescope and control system would remain siloed—each speaking its own language, with its own data structures and observation formats. That would make it impossible to automatically coordinate or distribute observations across the network.

By giving observations, instruments, and data requests a shared vocabulary, Skynet’s data model is the foundation that lets a network of heterogeneous observatories act as one agile, adaptive, and globally aware instrument.

This page is a conceptual overview of the data model. For a field-level breakdown of every record — schema models, observation types, and data formats — see the schema reference.

Auto-generated schema reference¶

The schema reference is produced automatically from the SQLAlchemy models in packages/py/skynet_db/models, so it stays synchronized with the code behind the Skynet API — new fields or tables appear in the docs as soon as the models change.