Skip to content

ILLUSTRATIVE · NASA / SVS · NOT ADITYA-L1 DATA

Engineering · architecture

Archive to rendered number

Six views of the same system. Every stage names a real path in the repository, because a diagram whose boxes are abstract nouns explains nothing its heading did not.

What is this?

The system drawn end to end: how archive products become a frozen dataset, how that dataset becomes a number on screen, and what stops a wrong number reaching the page.

Why should I trust it?

Every stage below corresponds to a file that exists in the repository and runs in CI. The counts in the diagrams are read from the generated payloads rather than written into the captions.

Where can I verify it?

View 1

The scientific pipeline

Archive products in, a frozen benchmark out.

  1. 1

    ISSDC archive

    Public Aditya-L1 products for SoLEXS and HEL1OS, downloaded as published.

    .lc · .pi · .gti · housekeeping

  2. 2

    Parse

    Archive products read under a written parser specification, with two PHA channel families reconciled.

    per-file records + source digests

  3. 3

    Canonicalise

    Everything resampled onto a 1-minute UTC grid. Missing stays missing — never imputed.

    7 canonical tables

  4. 4

    Freeze

    Every one of the 1,985 files hashed, rolled up to one dataset digest.

    freeze_manifest.json

  5. 5

    Benchmark

    Eight detectors on a frozen chronological split under a protocol fixed in advance.

    benchmark_results.json

The freeze is the hinge. Everything upstream of it can be re-run; everything downstream is addressed by the digest it produces, which is why a figure on this site can be tied to a specific set of bytes.

View 2

Data flow into the page

The narrow bridge between the science and the website — and the reason no number on this site is typed by a person.

  1. 1

    Committed artifacts

    JSON written by the science pipeline. Read-only from here on.

    artifacts/v2/**

  2. 2

    derive.py

    Resolves each displayed quantity to an RFC-6901 pointer inside the artifact that produced it, and re-verifies the input digests after writing.

    generated/data/**

  3. 3

    derive_metrics.py

    Computes curve geometry from the 21 MB prediction arrays so the browser never sees them.

    findings/metrics.json

  4. 4

    Astro build

    Pages import the JSON directly. Every rendered value carries its measurement key in the markup.

    static HTML

  5. 5

    postbuild.ts

    Hashes every inline script and writes the host-native header config.

    render.yaml · vercel.json

derive.py is the only path from artifacts to the web layer, and it is read-only: inputs are opened O_RDONLY and re-hashed after the run to prove nothing was modified. A developer cannot type a measured value into a page — they reference a measurement, and the reference must resolve.

View 3

The validation chain

Five gates, all of which run on every push to main.

  1. 1

    generate --check

    Regenerates design tokens into memory and diffs against disk. A hand-edited generated file cannot land.

    pass / fail

  2. 2

    astro check · tsc

    TypeScript at strictest, including unchecked index access and exact optional properties.

    pass / fail

  3. 3

    eslint boundaries

    The architecture graph is a lint rule: the artistic and evidence domains cannot import each other.

    pass / fail

  4. 4

    pnpm budget

    Re-reads the artifacts from disk and compares them against every rendered value in the built HTML. 6 measurements checked.

    evidence consistency

  5. 5

    per-route byte budget

    Fails the build if an evidence route grows a JavaScript payload.

    0 KB JS on evidence surfaces

The fourth gate is the one that matters most: it re-reads the committed artifacts from disk and compares them against the values actually present in the built HTML. A figure that drifts from its source does not render incorrectly — it fails the build.

View 4

Deployment

Static files, and nothing else.

  1. 1

    Push to main

    No path filter — GitHub truncates path lists on large diffs, so a gate could be skipped silently.

    CI run

  2. 2

    GitHub Actions

    Two workflows: the Python pipeline, and the web verify + build.

    green or red

  3. 3

    Render build

    pnpm install from the committed lockfile, then astro build with the root set to web/.

    dist/

  4. 4

    Static hosting

    Plain files. No server runtime, no database, no origin the page can reach at runtime.

    the live site

There is no application server, no database and no runtime dependency on any external origin — which is what allows the served Content-Security-Policy to forbid external origins outright rather than allow-listing them.

View 5

Repository layout

Seven top-level concerns, each with one owner.

  • web/

    The Astro site. Pages compose; they never implement. See it →

  • web/scripts/

    The four sanctioned generators: derive.py, derive_metrics.py, generate.ts, check.ts.

  • web/src/generated/

    28 JSON payloads plus the typed measurement map. Never hand-edited. See it →

  • research/

    The Python science pipeline, its tests, and the container configuration. See it →

  • artifacts/

    The frozen scientific record. Read-only to everything else in the repository.

  • docs/

    Written specifications, deployment notes and the architecture record.

  • .github/

    The gates. Both workflows run unconditionally on push to main.

The direction of dependency is enforced, not merely intended: artifacts/ is read-only to everything, web/src/generated/ is written only by the generators, and the artistic and evidence domains inside the site are forbidden by lint from importing each other — so a total failure of the opening scene cannot affect a single evidence surface.


View 6

How a visitor moves through it

The site is not a set of pages. It is one descent, from an impression you cannot verify to the command that reproduces it.

  1. 0

    The scene

    A held shot, labelled as illustrative. Nothing here is evidence and it says so.

    an impression

  2. 1

    Overview

    What the project is and why it exists.

    orientation

  3. 2

    Validation

    The evidence, before the claim that rests on it.

    grounds for trust

  4. 3

    Findings

    The conclusion, including the negative result.

    the claim

  5. 4

    Pipeline · Data

    The machinery, then the measurements themselves.

    the raw record

  6. 5

    Build

    The digest and the commands to rebuild all of it.

    your own copy

Validation sits before Findings deliberately. The platform's central claim is that its evidence is checkable, and putting the proof ahead of the conclusion is the strongest available way to say so.