On-Site Analysis Pipelines in Astronomy

• On-Site Analysis pipelines are operational data workflows that transform raw observational data at the acquisition site under strict latency and bandwidth constraints.
• They use modular, multi-stage processing—from calibration and reconstruction to quality monitoring and provenance capture—to ensure high fidelity and timely outputs.
• Implementations range from sub-minute real-time alerting to next-day batch processing, exemplifying a balance between speed, sensitivity, and robustness in observatory operations.

Searching arXiv for recent and foundational papers relevant to On-Site Analysis pipelines. arxiv_search query: "On-Site Analysis pipeline observatory ground segment real-time analysis provenance arXiv"

On-Site Analysis (OSA) pipelines are operational data-processing systems that transform incoming observational or infrastructure data into scientifically or operationally useful products at, or tightly coupled to, the site of acquisition under explicit constraints on latency, bandwidth, power, automation, and human intervention. In the literature, OSA is instantiated as daemon-driven orbit processing in the SuperAGILE ground segment, as two-tier real-time and nearline analysis in the Cherenkov Telescope Array (CTA), as rapid archive-integrated spectroscopic reduction for SOXS, and as next-day automated processing for MAGIC and LST-1 (0911.5113, Bulgarelli et al., 2015, Young et al., 2020, Dinesh et al., 26 Sep 2025). Across these cases, OSA denotes not a single algorithm but a layered architecture combining ingestion, correction or calibration, reconstruction, quality monitoring, alerting or reporting, archiving, and user-facing access.

1. Operational definition and latency regimes

A defining feature of OSA pipelines is that latency is treated as an engineering requirement rather than a secondary performance statistic. In CTA, the On-Site Analysis is the first scientific analysis layer of the observatory and is split into Level-A, or Real-Time Analysis (RTA), and Level-B analysis. The RTA must issue automated science alerts within 30 s from the last acquired Cherenkov event that contributes to the alert, with sensitivity not worse than the final pipeline by more than a factor of 3; Level-B has a maximum latency of 10 h and sensitivity not worse than the final pipeline by a factor of 2 (Bulgarelli et al., 2015). In MAGIC and LST-1, the corresponding “next-day observation processing” systems provide products “just a few hours after observations are completed,” usually before 14:00 local observatory time, and complement faster but less sensitive real-time analyses performed during data taking (Dinesh et al., 26 Sep 2025).

SuperAGILE demonstrates a broader temporal spectrum. Its SASOA pipeline supports orbital data processing (near real-time), daily data set integration, Temporal Data Set (TDS) processing, and TDS processing with source target optimization (TDS_SRC) for days-to-weeks integrations (0911.5113). SOXS adds another operational model: the pipeline is designed to populate Phase 3 compliant products into the ESO Science Archive Facility within 30 minutes, with a 15-minute stretch goal, even though the reduction tier is externalized to the SOXS DRAWER cluster in Belfast rather than running literally at the telescope (Young et al., 2020). This suggests that, in practice, “on-site” can denote functional proximity to observatory operations and low-latency decision loops, not only physical execution in the telescope control building.

A recurrent misconception is therefore that OSA refers only to hard real-time alerting. The documented systems span sub-minute alerting, end-of-observation or next-morning nearline products, per-contact or per-orbit quick-look processing, and archive-backed reprocessing over days and weeks (Bulgarelli et al., 2015, 0911.5113, Dinesh et al., 26 Sep 2025). What unifies them is operational coupling to the data source and the requirement that outputs remain useful for ongoing or immediately subsequent decisions.

2. Pipeline architecture and orchestration

OSA pipelines are typically modular, staged, and product-driven. SuperAGILE’s SASOA is among the clearest explicit examples. Its numbered workflow consists of TRIGGER, DATA_DOWNLOAD, COMMANDS_PARSING, LOCAL_SETTINGS, DATA_FETCH, FILE_NAMING, CORRECTION, ORBIT_REBUILDING, DATA_REDUCTION, PHOTONLIST_BUILDING, ATTITUDE_CORRECTION, IMAGING, and FILING, with the output of one task becoming the input of the next (0911.5113). The implementation is not described as a monolithic executable but as modules, macro-tasks, scripts, and batch programs orchestrated in sequence.

SOXS follows a recipe-based decomposition. Its named recipes separate pre-processing, calibration, rectification, mode-specific sky subtraction, extraction, response generation, merging, and acquisition-camera calibration. The architecture includes soxs_data_organiser, soxs_lingain, soxs_img_mflat, soxs_mbias, soxs_mdark, soxs_disp_solution, soxs_order_centres, soxs_spatial_solution, soxs_spec_mflat, soxs_straighten, soxs_line_check, soxs_nod, soxs_stare, soxs_offset, soxs_extract, soxs_response, soxs_merge, and soxs_astro_phot (Young et al., 2020). This decomposition separates calibration-product generation from fast science reduction, a pattern that directly serves low-latency operation.

Cherenkov-telescope implementations make the orchestration layer even more explicit. LSTOSA begins with a summary of the night’s observations, decomposes them into observation and calibration sequences, submits a sequence-level pilot job to SLURM, and then launches one job per sub-run by means of job arrays; results are later copied to final storage, merged, and exposed through a web interface (Ruiz et al., 2021). MAGIC and LST-1 next-day processing use a simpler but durable control scheme: main scripts launched by crontab jobs, process flow governed by the existence of key files, metadata drawn from DAQ databases and slow-control files, and highly parallel early-stage jobs split to approximately 20 minutes for MAGIC and 10 seconds for LST-1 (Dinesh et al., 26 Sep 2025).

The broader spectroscopic survey literature supports the same architectural interpretation. Automated pipelines were already understood not merely as final parameter-estimation tools, but as systems extending “from target selection to instrumental configuration, to data acquisition, data reduction, and even analysis” (Prieto, 2016). In that sense, OSA pipelines are best understood as operational workflows whose analysis stages are inseparable from upstream acquisition and downstream release logic.

3. Analytical stages and data products

The internal analytical stages of OSA pipelines vary by instrument, but their structure is recurrent: alignment or calibration of raw inputs, event or spectrum reconstruction, higher-level inference, and generation of both science and monitoring products. In SuperAGILE, the core telemetry inputs are Eventlist data: SA TM 3905, Attitude data: SA TM 3914, and Ephemerides data: SA TM 3916. These are time-synchronized in CORRECTION, reorganized in ORBIT_REBUILDING, reduced through “data separation, reconstruction and equalization,” converted into a reduced output eventlist, then into a photon list, corrected for attitude wobbling, and passed to imaging and source extraction, which yield images, source lists, and source position and flux estimates; the system also produces histograms, plots, statistics reports, and archived products (0911.5113).

SOXS shows the analogous spectroscopic pattern. Its goal is to remove instrument signatures, convert data into physical units, and deliver a detrended, wavelength and flux calibrated, telluric corrected 1D spectrum with UV-VIS + NIR arms stitched together, alongside calibrated 2D spectral products per arm and calibrated acquisition-camera images (Young et al., 2020). The 1D spectral FITS binary tables are intended to contain the calibrated spectrum, an additional telluric-corrected spectrum produced using MOLECFIT, a variance array, and a sky-background spectrum. Quality-control metrics are generated in the same execution graph to monitor telescope, instrument, and detector health.

CTA’s OSA emphasizes event streams, alerts, and data quality. The RTA comprises RT Reconstruction, RT Science Alert Monitoring, and RT Data Quality Monitoring, producing science alerts, event lists, RT Science Reports, RT DQ Alerts, and RT DQ Reports; Level-B adds more detailed data-quality evaluation and higher-sensitivity science monitoring (Bulgarelli et al., 2015). MAGIC’s next-day processing already extends this model to detection significance, spectra, light curves, and sky maps, whereas LST-1 currently processes from raw data to DL2 reconstructed events and is incorporating the higher-level MAGIC steps (Dinesh et al., 26 Sep 2025). LSTOSA likewise reports current production of DL1 calibrated data and image parameters, DL2 estimates of the primary particle physical parameters, quality plots, and detailed provenance logs (Ruiz et al., 2021).

Outside astronomy, the same staged logic persists, but with different products. A critical-infrastructure pipeline converts natural-language system descriptions into a source-verified knowledge graph and produces an OSCAL System Security Plan, an OSCAL Security Assessment Report, a CRH-based Risk Assessment (JSON), a Knowledge Graph (JSON), and a BSI-Grundschutz++ Gap-Analysis Report (JSON) (Muth et al., 9 Jul 2026). A plausible implication is that OSA is better characterized by locality, automation, and evidence flow than by any specific scientific data type.

4. Automation, triggering, and user interaction

Most OSA pipelines are arrival-driven rather than purely schedule-driven. SuperAGILE’s SASOA is controlled by a daemon running an endless loop that checks for newly available contact data, issues processing triggers, and supports both a file-based trigger via .ok files such as VC1.002469.009.ok and a database-based trigger at the ASDC Data Center (0911.5113). This design reflects a standard ground-segment pattern in which telemetry arrival units and scientific processing units are different, so the pipeline must detect, stage, and reorganize input before science processing starts.

CTA adopts a streaming model. The RTA receives data from DAQ in streaming mode during acquisition, ingests TECH alarms from ACTL, and supports multiple sub-array configurations with specific RTA pipelines running in parallel (Bulgarelli et al., 2015). The system is tightly integrated with the short-term scheduler and monitoring/control subsystems because its outputs can influence whether observations are continued, interrupted, or rescheduled.

MAGIC and LST-1 next-day processing occupy a different point on the same spectrum. Their pipelines are launched automatically by crontab jobs, monitored on web pages refreshed every few minutes, and include retry logic: failed processes are relaunched a certain number of times, then vetoed if necessary, with non-recoverable failures generating email notifications (Dinesh et al., 26 Sep 2025). LSTOSA is described as semiautomatic, “aiming for a fully automatized version,” but already designed so that all data acquired during one observing night are processed before the next night (Ruiz et al., 2021). The papers repeatedly stress that automation does not eliminate the need for human intervention; rather, the systems are built so that routine execution is automatic while inspection, debugging, and override remain possible.

User-facing access is usually hybrid. SuperAGILE exposes SA data processing Web services, a web graphical user interface (GUI) for TDS/TDS_SRC, and a web-based monitor for automatic processing status (0911.5113). SOXS provides a command-line interface designed to be Esorex-like and plans integration through ESO Reflex (Young et al., 2020). MAGIC and LST-1 expose monitoring web pages and collaboration-visible science plots (Dinesh et al., 26 Sep 2025). This suggests that OSA pipelines tend to converge on a dual access pattern: unattended execution for routine production and thin remote interfaces for operators and analysts.

5. Robustness, provenance, and auditability

Robustness in OSA pipelines is usually implemented as failure isolation rather than complete avoidance of failure. SuperAGILE explicitly states that “many solutions were implemented in order to achieve fault tolerance,” and, crucially, that a failure in one pipeline task may block final output for that specific run but does not stop the daemon from processing future triggers (0911.5113). MAGIC and LST-1 operationalize the same principle through retries, veto states, and web-visible status fields (Dinesh et al., 26 Sep 2025). In CTA, high availability is itself a requirement: the RTA must be available during observations with availability greater than 98% (Bulgarelli et al., 2015).

Provenance and traceability are increasingly treated as first-class products. PRAETOR, a provenance suite for Python pipelines, is explicitly motivated by research infrastructures in which data volumes and rates are rising while direct human inspection becomes less feasible. It captures imported modules, functions, file access, input parameters, datasets, observatory metadata, processing time, memory consumption, function inputs and outputs, and user-defined quality metrics in a PROV-based model, with storage in Neo4j or RDF/fuseki and a UI deployed via Docker (Johnson et al., 2024). The system is designed to support analysis, evaluation, trust, and reproducibility, and to make multi-execution provenance queryable rather than merely archival.

LSTOSA adopts a comparable approach in observatory operations. For each run it stores executed analysis steps, configuration parameters, needed files, and intermediate files in JSON according to the IVOA Provenance Model Recommendation, and also produces PDF provenance graphs (Ruiz et al., 2021). This is notable because the provenance artifacts are generated as part of routine nightly processing rather than as a post hoc reconstruction.

The most explicit discussion of trust boundaries appears in the critical-infrastructure pipeline. There, deterministic MCP-based retrieval from authoritative sources yields a Factual Hallucination Rate = 0% for deterministically sourced knowledge-graph nodes, and the pipeline emits a schema-valid OSCAL SSP and SAR. Yet the same paper shows that grounding does not eliminate errors: the dominant failure mode shifts to the first phase of asset extraction, where the reported Entity Extraction Precision = 87.5%, Entity Extraction Recall = 100%, Semantic Hallucination Rate = 12.5%, and resulting Contextual False Positive Rate = 8.5 ± 0.2% reflect genuine but irrelevant CVEs attached to a falsely extracted entity (Muth et al., 9 Jul 2026). This is a precise statement of a wider OSA principle: provenance and grounding change the location and inspectability of error, even when they do not remove it.

6. Representative implementations and general patterns

The range of implemented OSA systems is broad, but their recurring design patterns are compactly summarized.

System	Operational setting	Distinctive features
SASOA / SuperAGILE	AGILE Ground Segment	Daemon-driven orbit/contact processing; TDS and TDS_SRC; web services (0911.5113)
CTA OSA	Telescope-site streaming analysis	Level-A 30 s alerting; Level-B 10 h; science and data-quality monitoring (Bulgarelli et al., 2015)
SOXS pipeline	Archive-integrated rapid spectroscopic reduction	Recipe-based Python pipeline; Phase 3 products within 30 minutes (Young et al., 2020)
LSTOSA and MAGIC/LST-1 next-day OSA	Observatory-local overnight batch processing	SLURM/Torque orchestration, web monitoring, next-day quality and science products (Ruiz et al., 2021, Dinesh et al., 26 Sep 2025)
PRAETOR / OSCAL-critical-infrastructure pipeline	Research-infrastructure and OT compliance workflows	PROV-based provenance, MCP-grounded retrieval, schema-valid OSCAL artifacts (Johnson et al., 2024, Muth et al., 9 Jul 2026)

Several general patterns emerge from these implementations. First, OSA pipelines are usually layered by latency: fast approximate or quick-look branches coexist with slower, more complete branches. Second, they are modular and product-driven: each stage emits typed intermediate products consumed by later stages. Third, they are operationally embedded: triggering, scheduling, data quality, and user interfaces are part of the same system rather than external concerns. Fourth, they are increasingly audit-oriented: provenance capture, schema validation, and standards-based outputs are treated as integral to the pipeline rather than optional administrative additions.

The spectroscopic-survey literature reinforces the architectural rather than instrument-specific nature of these lessons. Automated analysis pipelines were already being evaluated in terms of throughput, reproducibility, calibration quality, and software governance, with strong emphasis on centralized maintenance, version control, benchmark-driven calibration, and physically informed stage ordering (Prieto, 2016). A plausible implication is that OSA pipelines are best viewed as a general systems pattern for near-data scientific and operational analysis in high-rate infrastructures: modular, latency-constrained, evidence-bearing, and explicitly designed to balance speed, sensitivity, and trust.