Skip to content
Project VELAProject VELA

Data Specification — Project VELA

Everything the demo needs is public. Verify licenses on download; summaries below are working notes, not legal advice.

1. Telemetry datasets

1.1 ESA Anomalies Dataset (ESA-AD) — primary

  • Source: Zenodo DOI 10.5281/zenodo.12528696; benchmark code github.com/kplabs-pl/ESA-ADB.
  • What: Multi-year real telemetry from three ESA missions (two benchmarked), annotated by ESOC spacecraft operations engineers: anomalies, rare nominal events, communication gaps, plus telecommand streams. Irregular timestamps, varying sampling rates — keep them; do not naively resample away reality.
  • Use: Mission 1 = training + demo replay. Mission 2 = held-out generalization check.
  • Preprocessing (vela/ingest/esa_adb.py): channel selection config; forward-fill only within source sampling tolerance; z-score per channel using training split only; persist split manifests (data/manifests/*.json) with sha256 of every file — reproducibility is a selling point.
  • License: check Zenodo record on download; cite the ESA-ADB paper in any public material.

1.2 NASA SMAP / MSL (Hundman et al.)

  • Source: github.com/khundman/telemanom (NASA JPL). Labeled anomalies from Soil Moisture Active Passive satellite and Mars Science Laboratory rover.
  • Use: cross-dataset sanity check for detection layer; classic literature comparison numbers.

1.3 OPS-SAT (ESA)

  • Source: ESA/Zenodo — search “OPS-SAT anomaly dataset” (Kotowski et al. released one via the same KP Labs group). Smaller; nanosatellite-class dynamics.
  • Use: demo variety — shows the pipeline isn’t overfit to one spacecraft class.

2. Knowledge-graph sources (for the demo spacecraft)

The demo needs a plausible, honest knowledge graph. Strategy: build a reference cubesat-class KG from public engineering documents and clearly label it “reference spacecraft” in the UI — never claim it is the ESA mission’s real design (that design is not public).

  • NASA Fault Management Handbook (NASA-HDBK-1002) — failure-mode taxonomy skeleton.
  • Public cubesat FMECA/reliability templates (university mission docs — e.g., published cubesat critical design reviews) — component→failure-mode→signature triples.
  • ECSS standards catalogue (ecss.nl) — subsystem vocabulary and procedure structure conventions (registration may be required; standards are reference material, do not redistribute).
  • Yamcs demo spacecraft (“simulator” mission in Yamcs quickstart) — gives a consistent channel/command namespace to bind the KG to for the live-integration path.
  • Past anomaly cases: seed anomaly_cases with structured summaries of publicly documented smallsat anomalies (peer-reviewed lessons-learned papers, conference proceedings — SmallSat conference digital commons is rich). Store {summary, subsystem, signature, resolution, source_ref}. Paraphrase; store references, not copied text.

2b. Channel binding for anonymized telemetry (the demo’s one approximation — make it explicit, provable, and gated)

ESA-ADB channels and telecommands are anonymized; the real spacecraft design is not public. Therefore:

  1. Reference ontology (VELA-REF-1): the demo KG is a fully-cited reference spacecraft assembled from the public sources in §2. Every node cites its public source. Agents traverse this, never a pretended “real” Mission 1 design.
  2. Binding layer: (:TelemetryChannel {id:"esa-m1:channel_44"})-[:BOUND_TO {basis, confidence, reviewed_by, date}]->(:RefSensor). Bindings are proposed by vela/ingest/bind_channels.py using (a) the dataset’s own structural metadata (channel groups, priorities, telecommand-target relations — use verbatim, cite the dataset), and (b) statistical profiling: value ranges, periodicity, correlation clusters, command-response coupling. Proposals land in a human-review TSV; only approved bindings load, each with confidence ∈ [0,1] and a one-line basis.
  3. Epistemic gating: channels_to_components resolves through BOUND_TO and returns binding metadata so the validator can discount weak paths. Any verdict that rests solely on bindings with confidence < 0.5 must return insufficient — never a confident narrative. Every InvestigationReport includes an “Assumed bindings” appendix listing each binding relied upon, with confidence and basis.
  4. Exact-binding paths: the Yamcs demo-sat / NOS3 sim configuration has bindings exact by construction (we define the spacecraft), and customer pilots bind from their telemetry database + ICDs — no inference. Demo talk-track: “the reference bindings are the only approximation here, and they disappear on your spacecraft.”

3. Data contracts (internal)

class TelemetrySample(BaseModel):
    satellite: str; channel: str; ts: datetime; value: float; quality: str  # raw|derived
class TelecommandRecord(BaseModel):
    satellite: str; command: str; ts: datetime; args: dict; source: str
class AnomalyEvent(BaseModel):
    event_id: UUID; satellite: str; channels: list[str]
    t_start: datetime; t_end: datetime; score: float
    detector: Literal["ecod","gat","ensemble"]
    suppressed_as_command_response: bool
class Citation(BaseModel):
    kind: Literal["doc","kg","case","telemetry"]
    ref: str          # e.g. "manual:eps-guide#4.2.1", "kg:FailureMode/FM-EPS-007"
    sha256: str | None
class InvestigationReport(BaseModel):
    event: AnomalyEvent
    verdict: str; confidence: Literal["low","medium","high"]
    narrative: str                      # every sentence maps to ≥1 citation
    citations: list[Citation]
    procedure_draft: list[ProcStep]     # each step: text + citations, or UNGROUNDED flag
    audit_log_ref: str

4. Storage & hygiene

  • Raw data: data/raw/ (git-ignored, DVC-tracked). Processed: data/processed/ keyed by manifest hash.
  • Nothing customer-derived ever enters the repo, embeddings included. Pilot data lives in a per-customer encrypted volume; contractual default = we keep zero copies post-pilot.
  • make data downloads and verifies all public datasets end-to-end on a clean machine. This is the first thing an AI coding agent should make pass.