Skip to content

Why spectro-kernel?

This is the page to read first. It answers the obvious question:

"astropy and specutils already exist and do all of this. What is the point of spectro-kernel?"

Short answer: spectro-kernel is not an alternative to astropy or specutils - it is a layer on top of them. It solves a problem those libraries are not meant to solve.

The problem it solves

Picture a handful of spectroscopy applications built over the years - a campaign archive, a Be-star dashboard, an aurora monitor, a CCD-reduction pipeline, a search engine, a toolbox of advanced scripts.

Every one of them needs to:

  • read a FITS spectrum and rebuild its wavelength axis,
  • normalise the continuum,
  • estimate a signal-to-noise ratio,
  • fit a spectral line,
  • query SIMBAD, plot with Plotly, export to CSV…

And every one of them re-coded these from scratch, slightly differently:

  • 6 different FITS readers for the same canonical operation.
  • 5 different continuum normalisations, so a measurement in one app is not comparable to the same measurement in another.
  • 4 different SNR formulas - and no one remembers which is "the right one".

This is not an astropy problem. astropy gives you excellent primitives. It does not, and should not, decide which continuum-normalisation recipe your organisation uses, or make that recipe discoverable, versioned, reproducible and callable by an AI agent. That coordination layer is what was missing - and that is spectro-kernel.

What spectro-kernel adds

flowchart TB
    F["astropy · specutils · scipy<br/>excellent primitives"]
    F --> K["spectro-kernel adds<br/>the coordination layer"]
    K --> K1["one canonical Spectrum1D -<br/>one implementation per operation"]
    K --> K2["a registry discoverable by<br/>humans and AI agents"]
    K --> K3["composable, reproducible<br/>pipelines with an audit trail"]
    K --> K4["three access paths in parity -<br/>library · CLI · MCP"]
    K --> K5["explicit provenance -<br/>backend + references"]

  1. One canonical representation, one implementation per operation. There is exactly one Spectrum1D type and exactly one normalize_polynomial. No more divergent copies.

  2. A discoverable catalogue. list_algorithms() returns every operation with its parameters, version, inputs and outputs. A human - or an AI agent - can discover what exists without reading the source.

  3. Composable, reproducible pipelines. Algorithms chain into a Pipeline; every run records an audit trail (which algorithm, which version, which parameters, input and output hashes). A result can be traced and replayed.

  4. Three access paths with guaranteed parity. The same catalogue is reachable as a Python import, as the spectro command, and as an MCP server for AI agents. They cannot drift apart - the CLI and MCP server are thin shells over the same registry.

  5. Explicit provenance. Every algorithm declares a backend (what it leans on) and references (the literature). Nothing is a black box.

The principle: we do not reinvent

spectro-kernel follows one rule:

Lean on what exists; implement our own only when we must.

When a canonical implementation of an operation already exists in astropy, specutils, scipy or astroquery, spectro-kernel wraps it - it does not rewrite it. spectro-kernel implements an operation itself only when (a) it is a published method not available in those libraries, or (b) it is glue specific to our conventions.

Every algorithm makes this visible through its backend field:

backend Meaning
astropy Wraps the domain-standard astropy implementation.
specutils Wraps the domain-standard specutils implementation.
astroquery Wraps astroquery (Virtual Observatory queries).
scipy Implemented here on top of scipy numerical primitives.
numpy Implemented here on top of numpy numerical primitives.
plotly Renders figures with Plotly.

…and through its references field, which cites the literature. You can see both in spectro describe <name>, in the catalogue, and in every MCP tool description.

Examples

  • read_fits → backend astropy. It wraps astropy.io.fits; we did not write a FITS parser. spectro-kernel only adds WCS reconstruction conventions and a uniform return type.
  • lomb_scargle → backend astropy. It wraps astropy.timeseries.LombScargle (Lomb 1976; Scargle 1982; VanderPlas 2018).
  • snr_der → backend numpy. The DER_SNR algorithm (Stoehr et al. 2008) is a published method not provided by astropy, so spectro-kernel implements it - and cites the paper.
  • air_to_vacuum → backend numpy. The Morton (2000) dispersion relation, implemented directly and cited.

So "shelved in parallel to the pro algorithms" is exactly right: the custom algorithms sit next to the wrapped ones in the same catalogue, each clearly labelled by its provenance.

What spectro-kernel is not

  • ❌ A replacement for astropy or specutils - it depends on them.
  • ❌ A new UI or dashboard - applications keep their own front-ends.
  • ❌ A spectrum database - each project keeps its own storage.

It is the shared engine room: the place every spectroscopy operation lives, exactly once, callable by anyone - and any agent.