Glossary

Product names

Parsimoni Platform

The whole product: four components spanning build, share, and run. Teams can adopt all four or integrate one at a time, because the boundaries between them are open standards.

Space CLI

The build component: the space binary builds application artifacts and signed system compositions, runs them locally, publishes them, and assembles a per-board release for a target.

Space Store

The share component: the marketplace where developers publish applications across architectures and customers order results without running a flight-software project of their own. run.space is its hosted surface.

Space CCSDS

The link component: the OCaml implementation of the CCSDS protocol family that carries signed releases, commands, and results over bandwidth-constrained space links.

SpaceOS

The run component: the on-board runtime. It admits, starts, isolates, and supervises payload workloads on one node, each in its own partition. It does not build software and does not fly the spacecraft.

Platform terms, for space engineers

Partition

The unit of isolation, admission, and supervision: a hardware-isolated micro-VM for a unikernel service, or a kernel-sandboxed container for a Linux service. It is the spatial half of what ARINC 653 calls time and space partitioning: memory and fault isolation between workloads sharing one computer. The temporal half is not provided; SpaceOS assigns CPUs but does not schedule fixed time windows, which is one reason hard-real-time software stays in the flight domain.

Supervision page

A small shared-memory page between the host and each service carrying heartbeat, mission time, health, and the safe-mode command word. The counterpart of health-and-safety monitoring in flight frameworks (the cFS Health and Safety application, F-Prime’s Svc::Health): liveness rides its own channel, separate from the message bus it supervises.

Blue/green rollout

Side-by-side activation with health-gated switchover: the new workload generation starts beside the old, must pass its declared healthchecks, and is promoted atomically or rolled back. The old instance keeps running until the new one proves healthy.

Content store and root flip

Bootable system updates keep any number of verified system images in one content-addressed store rather than two fixed A/B partitions. Three small pointers (confirmed, trial, last known good) select the boot image. An update appends an image and flips a pointer after a healthy trial boot; rollback flips it back.

OCI image

The packaging unit for every workload, the container-image format from the Open Container Initiative. A unikernel binary and a Linux root filesystem ship the same way: content-addressed layers plus a manifest, moved by standard registry tooling. The format is packaging, not execution: what runs is decided by the isolation backend.

Registry

A server that stores and serves OCI images by name and digest, the way a ground archive serves products by identifier. space registry serves the local store; hosted registries bind through a context.

Container (runc)

A Linux process sandboxed by kernel namespaces and resource limits, sharing the host kernel. Linux applications run unmodified, with weaker isolation than a micro-VM.

Unikernel

A single-purpose machine image linking one application with only the operating-system libraries it needs; there is no general-purpose OS inside. Built on MirageOS (OCaml) or Unikraft (C, C++, Rust), run by a Solo5 tender.

Solo5 and tenders

Solo5 is the thin host interface a unikernel is built against: about a dozen calls for a clock, a console, a block device, and a network queue, and nothing else. A tender is the small host-side program that creates the sandbox, loads the unikernel into it, and services those calls. It is the unikernel equivalent of a container runtime. SpaceOS uses two: hvt (hardware virtualized tender) runs the guest as a hardware-isolated micro-VM on KVM; spt (sandboxed process tender) runs it as a seccomp-confined process where KVM is absent.

dom0

The minimal Linux control domain SpaceOS runs on a Linux target: space-init as PID 1, space-runner as the workload supervisor, and the network, key, log, and metric services beside them. The name is borrowed from Xen’s domain 0. Application code never runs in dom0; it runs in partitions that dom0 admits, starts, and watches.

Under static dom0less Xen the hypervisor starts each domain itself from the device tree, and there is no control domain.

Content-addressed

Named by the cryptographic digest of the bytes rather than by a mutable label. A content-addressed reference cannot silently change meaning: the same digest is always the same bytes, so verification is a comparison and needs no trusted directory. Images, target profiles, and system releases are all content-addressed; tags such as :latest are not.

IOMMU

Input-output memory management unit: the hardware that restricts which physical memory a device may reach. Without one, handing a device directly to a guest lets that device read all of memory, so SpaceOS refuses direct passthrough on targets that lack an IOMMU.

TPM

Trusted Platform Module: a discrete security chip that stores keys and counters the main processor cannot forge or rewind. SpaceOS uses its monotonic counter as the anti-rollback floor on locked targets.

dm-verity

Linux kernel block-level integrity: every read from the root filesystem is verified against a hash tree whose root is pinned in the signed boot configuration, so a flipped or tampered block is detected on access, for the whole uptime.

TUF

The Update Framework, the signed-update-metadata model: a pinned root key delegates to timestamp, snapshot, and targets roles with per-role thresholds, monotonic versions against rollback, and offline verification. SpaceOS carries it as COSE-signed CBOR beside the images it authorizes.

CBOR

Concise Binary Object Representation (RFC 8949): a binary encoding with the same data model as JSON (maps, arrays, strings, and numbers) but smaller on the wire and cheaper to parse. SpaceOS uses it wherever bytes cross a link budget or a trust boundary.

COSE

CBOR Object Signing and Encryption (RFC 9052), the binary signing envelope used for trust metadata and signed commands; the CBOR-native equivalent of what JOSE/JWT are for JSON.

Capability envelope

The list, carried inside the signed release, of exactly what one partition may open: which devices, which routes, which APIDs, which storage blocks. The runtime grants nothing the envelope does not name, so adding an accelerator or a route means re-signing the release rather than changing runtime configuration. SpaceOS writes it during deployment.

Measured launch

Recording what is about to run before running it. space build compiles a launch plan with service digests, dm-verity roots, and keystore settings into the signed system image, and space-init refuses to continue if what it finds on disk does not match. The record is what later attestation reports.

SBOM

Software bill of materials: the machine-readable inventory of every package and layer in a build, with versions and content digests (SPDX or CycloneDX). The supply-chain equivalent of a parts list with lot numbers.

Context

A named binding of registry, scheduler, and ground-service endpoints the CLI talks to. The built-in local context works offline; a hosted context points the same verbs at run.space.

Healthcheck

An app-declared liveness probe (TCP, HTTP, or command) the runner evaluates from outside the guest; the service-level analogue of a housekeeping aliveness check, and the gate blue/green promotion waits on.

Spacecraft terms, for software engineers

CCSDS

The Consultative Committee for Space Data Systems, and by extension the family of standards it publishes: how a spacecraft frames packets, secures a link, and transfers files. Nearly every space agency and ground system speaks it. SpaceOS uses CCSDS on the wire rather than a proprietary protocol. APID, SCID/VCID, SDLS, and CFDP are all CCSDS standards.

Telemetry and telecommand (TM/TC)

Downward-flowing measurements and state (telemetry) and upward-flowing instructions (telecommand); the read path and write path of spacecraft operations.

APID

Application Process Identifier, an 11-bit CCSDS label that says which stream a packet belongs to; a topic tag, comparable to a port number or a message-bus topic. In SpaceOS it demultiplexes frames at CCSDS edges; authenticated identity supplies authorization.

Frame bus

The on-board CCSDS-native path carrying fixed-size telemetry, command, event, and parameter frames between partitions, the flight domain, and the ground edge; publish/subscribe by APID, the shape of the cFS Software Bus.

SCID / VCID

Spacecraft Identifier and Virtual Channel Identifier: the CCSDS link-layer fields that select which spacecraft and which quality-of-service lane a transfer frame belongs to, above APID in the multiplexing hierarchy.

SDLS

Space Data Link Security (CCSDS 355.0-B): authentication and optional encryption of each data-link frame with symmetric session keys, terminated and re-keyed per hop. It secures the pipe; end-to-end protection is BPSec’s job.

OTAR and ML-KEM

Over-the-air rekeying: replacing a link’s session keys across the link itself, without a ground visit. SpaceOS establishes the new key material with ML-KEM (NIST FIPS 203), the standardized post-quantum key-encapsulation algorithm, so a recording of today’s traffic cannot be decrypted by a future quantum computer. Its signature-side counterpart is ML-DSA (FIPS 204), the post-quantum signing profile.

DTN

Delay- and disruption-tolerant networking: the design assumption that no end-to-end path exists at any one moment, so each node stores what it holds and forwards when a link appears. BPv7 is the protocol; DTN is the model.

BPv7 / BPSec

Bundle Protocol version 7 (RFC 9171) and its security extension (RFC 9172): the DTN protocol, where nodes store bundles and forward them when a link exists, with integrity and confidentiality that survive untrusted relays end to end.

Endpoint ID and convergence layer

A BPv7 node is named by an endpoint identifier, usually in the ipn: scheme. For example, ipn:7.1 is service 1 on node 7. It is a routing name, not an address: it says nothing about where the node is or how to reach it. The convergence layer is what actually carries bundles between two nodes over some concrete transport, and its convergence-layer adapter address (--cla-address) is the host and port to hand bundles to. space target connect takes both: the --endpoint names the node, the --cla-address reaches it.

CFDP

The CCSDS File Delivery Protocol (727.0-B): reliable file transfer built for links that come and go, with checkpoints, selective retransmission, and resume across contact windows. What rsync-over-TCP is to the data center, CFDP is to a space link.

Contact window

The minutes during which a satellite is in radio range of a ground station. Everything in the deploy pipeline is durable because the next window may be hours away.

TLE

Two-line element set, the standard orbit description; from it and a ground station’s coordinates the platform derives real pass times, which is what space target connect --tle --station consumes.

OBC

On-board computer. SpaceOS runs on the payload or mission computer beside the flight computer.

BSP

Board support package: the vendor’s kernel, bootloader, device tree, and drivers for one specific board. Where a flight computer arrives with a BSP you cannot replace, SpaceOS installs as a daemon on top of it rather than owning the boot path.

RTOS

Real-time operating system: one that guarantees a task runs within a bounded time, which a general-purpose OS does not. Flight software runs on an RTOS because a missed attitude-control deadline is a spacecraft event, not a latency spike. SpaceOS makes no real-time guarantee, which is why control-loop code stays in the flight domain.

Separation kernel

A very small hypervisor whose only job is to keep partitions apart in memory and time, certifiable precisely because it does so little. It is one way the flight and payload domains can share a single physical computer while staying separate trust domains.

Flight software / bus software

The safety-critical, hard-real-time software that flies the spacecraft: attitude control, propulsion, power, command and data handling, typically an RTOS running F-Prime (JPL’s flight-software framework) or cFS (NASA’s core Flight System) components. It forms a separate trust domain observed by SpaceOS over a bus; its own systems retain supervision.

FDIR

Fault detection, isolation, and recovery: the discipline of noticing a fault, containing it to the smallest boundary that explains it, and restoring service. Each domain owns its own; SpaceOS supervision escalation is payload-side FDIR.

SEU

Single-event upset: a bit flip caused by ionizing radiation. Partition boundaries, CRCs, redundant records, and verified reads mitigate its effects.

Ground segment

Everything on Earth: ground stations, mission operations, data processing. CCSDS-compatible ground tools (Yamcs, OpenC3 COSMOS) interoperate at the protocol boundary.