Space Data Module SDK

Space Data Network

Harness families

One uniform WASM plugin contract per kind of scenario behavior. Point an LLM at your codebase and at this site, build a module, host it on the SDN, and any consumer loads it — with no modification to the rendering engine.

Build a module Read a shipped ABI GitHub

The matrix

Nineteen families, one spine

Every family is documented against the same thirteen-section spine. Status is stated honestly: only families marked Shipped have a ratified generated header, a conformance kit, and a reference module.

Dynamics

How a vehicle's state evolves: propagation, maneuvers, thrust, orientation, and closed-loop control.

Propagator

shipped

Advance a vehicle state to a requested epoch. The reference family: generated header, conformance kit, reference module.

Maneuver

experimental

Apply an impulsive or finite burn to a state and report the resulting trajectory change.

Propulsion

planned

Model thrust production and propellant consumption as a supplier to the maneuver family.

Attitude

planned

Produce body orientation over time, independent of translational state.

GNC

planned

Closed-loop guidance, navigation and control that commands the maneuver and attitude families.

Environment and interaction

How a vehicle interacts with its surroundings: radio frequency, sensing, observable signature, environment models, and line-of-sight obstruction.

RF

designed

Link budgets, coverage and interference. Records-in/records-out RF needs no harness; the harness exists for RF that writes scene state.

Sensor

planned

Detection geometry and sensor tasking: what an instrument can see, when.

Signature

planned

Observable signature models — radar cross section, optical magnitude, thermal.

Environment

planned

Atmosphere, gravity field, magnetic field, and radiation environment models consumed by other families.

Obstruction

designed

Line-of-sight occlusion against arbitrary 3D geometry with per-material electromagnetic properties.

Event physics

Discrete events that create or destroy state: fragmentation, atmospheric reentry, close approaches, and their visual effects.

Breakup

planned

Fragmentation events producing a debris population that must match the standard breakup model.

Reentry

planned

Atmospheric reentry survivability, ablation, and ground footprint.

Conjunction

designed

Close-approach screening and probability of collision over a catalog.

Effects

planned

Visual and volumetric effects driven by an event physics family.

Estimation, data and logic

Turning observations into state, bringing data in, and deciding what happens next.

Estimation

experimental

Orbit determination and filtering: observations in, estimated state and covariance out.

Data source

shipped

Fetch, parse and normalize external provider data into standards records inside the module.

Analytics

planned

Derived figures of merit computed over a scenario.

Scheduler

planned

Ordering and tasking of activities across a scenario timeline.

Behavior

planned

Scripted or reactive decision logic that drives other families.

Doctrine

How the taxonomy works

The Space Data Module SDK exposes one harness family per kind of scenario behavior. A harness family is a uniform WASM ABI: a named export set, a generated wire layout, declared units and frames, named error codes, and a conformance kit that proves an implementation satisfies it. A third party implements the exports, compiles to WebAssembly, and the module is loadable by any consumer of that family — with no modification to the consuming engine.

A family port that cannot absorb a legitimate module without an engine edit is itself the defect.

The uniform spine

Every family is specified and documented against the same spine, in the same order. The propagator family is the reference implementation of the spine; read Propagator first, whichever family you are building for.

SectionWhat it fixes
DoctrineWhy this family exists and what it is explicitly not
CapabilityWhat a module of this family is allowed to compute and to touch
Import / export setThe exact symbols the guest must export and may import
Wire layoutByte-exact structs, generated from a single .fbs source
Units and framesThe unit of every field and the reference frame of every vector
SentinelsThe reserved values that mean "absent", "unknown", "refused"
IdentityHow an entity is addressed across calls
ThreadingThe threading model and the shard-write discipline
Error codesThe named negative codes; never a generic -1
LifetimeInit, reuse, and a real idempotent teardown
Parity envelopeWhat must be byte-identical across browser, WasmEdge and Docker WasmEdge
Consumer seamHow a consuming surface takes the module as a pluggable port
Guest C++ exampleA compilable starting point

How a family is built

  1. A single .fbs schema is the source of the wire layout. Nothing is hand-written twice.
  2. A generator emits the ABI header (and the JS/TS bindings) from that schema, and a drift gate byte-diffs the generated output against what is committed. A schema edit that is not regenerated fails the gate.
  3. Modules are compiled wasm32-wasip1-threads. This is isomorphic by construction: the same artifact runs in the browser, under WasmEdge, and under Docker WasmEdge.
  4. Data in and out of a module is Space Data Standards records, never a bespoke JSON shape.
  5. A conformance kit and a reference module ship with the family. The kit carries its own negative control, so a kit that cannot catch a planted defect fails itself.
  6. The artifact is protected, signed, published and listed. See the integrator path below.
  7. Exactly one generic consumer port exists per family.

Status vocabulary

Status on this site is literal, and is taken from the ratified harness-family taxonomy of 2026-08-14. It is not aspirational.

StatusMeaning
ShippedRatified .fbs single source, generated header with a drift gate, conformance kit, reference module. Build against it.
ExperimentalReal code exists and the shape is taking form, but it is not frozen and known defects are open. Do not ship a commercial module against it.
DesignedAn ABI has been drafted against a real consumer. No generated header, no conformance kit, no reference module has landed.
PlannedA ratified entry in the taxonomy whose individual shape has not been ratified. Nothing is implemented.

Only propagator and data-source are Shipped. Only maneuver and estimation are Experimental. Only rf, obstruction and conjunction are Designed. Every other family is Planned, and its status has not been ratified individually — a Planned page states scope and nothing more.

Where a family page says a thing does not exist, that is a checked statement about the tree today, not a placeholder.

Vehicle domains are not a harness family

Space, air, ground and naval vehicles do not each get a harness. The vehicle domain is a declaration in the module manifest — state space, frames, and degrees of freedom — consumed by whichever family the module implements. A ground-vehicle propagator and a spacecraft propagator implement the same propagator export set and differ in the manifest.

Harness families are not the runtime PluginFamily enum

Two vocabularies exist and they are not the same list.

  • The harness-family taxonomy on this site is the owner-ratified list of ABI-bearing plugin kinds: propagator, maneuver, propulsion, attitude, gnc, rf, sensor, signature, environment, obstruction, breakup, reentry, conjunction, effects, estimation, data-source, analytics, scheduler, behavior.
  • The PluginFamily enum in schemas/PluginManifest.fbs is the SDK's internal manifest classification (SENSOR, PROPAGATOR, RENDERER, ANALYSIS, DATA_SOURCE, COMMS, SHADER, SDF, INFRASTRUCTURE, FLOW, BRIDGE, MANEUVER, ORBIT_DETERMINATION, FOUNDATION, PARSER, VALIDATOR, EXPORTER, PUBLISHER, BASILISK). It is what a manifest declares today.

They overlap but do not correspond one-to-one, and a family in the taxonomy may project onto a broader PluginFamily member until a dedicated one is minted. Do not file a mismatch between the two lists as a bug; the family pages state which enum member each family projects onto.

Internal plumbing is never a public contract

Two boundaries are permanent rulings, not maturity gaps:

  • JavaScript registries are internal engine plumbing. They are how a consuming engine dispatches to compiled modules. They are never offered as a public extension point. Harness contracts are WASM ABIs only.
  • Scalar kernel-op ABIs behind closed modules are internal. In particular the closed scalar rf_* kernel ABI is never the public RF contract. The public RF surface is the .fbs-defined harness ABI plus the record types a module consumes and emits.

The integrator path

  1. BYO-wasm quickstart — multi-translation-unit C++ against the pinned wasm32-wasip1-threads toolchain, to a loadable artifact.
  2. Conformance kit and the tri-runtime parity gate — prove the ABI, then prove byte-identical behavior in every lane.
  3. Protect and sign — encrypt the payload where the module is closed, attach the manifest, sign the artifact.
  4. Publication and listing — the publication record layout, delivery, and the current state of self-serve listing.

An LLM building a module against this SDK should start at llms.txt.

Integrator path

From your C++ to a listed module

1. BYO-wasm quickstartMulti-TU C++ against the pinned wasm32-wasip1-threads toolchain. 2. Conformance and paritySelf-test the ABI, then prove byte-identical tri-runtime behavior. 3. Protect and signEncrypt the payload, attach the manifest, sign the artifact. 4. Publish and listPublication records, delivery, and the listing submission flow. LLM integrator contractllms.txt — the machine-readable entry point for a coding agent.

SDN Stack

Connected sites

Standards Canonical schemas, record contracts, and generated bindings. FlatBuffers Binary encoding, schema tooling, and runtime documentation. FlatSQL SQL-style queries over FlatBuffer-backed datasets and streams. SDN Distributed publication, discovery, delivery, and marketplace infrastructure. Module SDK WASM module packaging, validation, and host compatibility tooling.