For universities

Mission systems learning on the same Digital Twin

Students take a mission requirement to a bounded engineering conclusion in Mission Studio, on the same accepted Digital Twin schools use. All thirteen runnable pilot missions are available at ML-D depth with quantitative channels, provenance, configuration, evidence-quality, limitation, and verification-and-validation prompts. There is no separate university runtime.

One coherent journey, deeper evidence

  1. 01Mission
  2. 02Preparation
  3. 03Readiness
  4. 04Operate
  5. 05Evidence
  6. 06Complete
  7. 07Recognition

Traceable evidence

Inspect visible channels, their provenance roles, deterministic run hashes, and the claim each artifact can support.

Configuration and V&V

Compare bounded configurations, evaluate evidence sufficiency, and state what a longer or more detailed software run still cannot establish.

Truthful recognition

Local practice has zero measured channels and is not verified recognition. Institutional and Challenge authority remain separate workflows.

Engineering workspace

Mission Studio

Create and revise missions, run the shared model core on bounded spacecraft definitions, compare variants and keep evidence with model and channel provenance visible. Mission Control is the engineering instrument used to inspect runs, telemetry and replays—a capability of the Digital Twin, not a separate product.

Bounded developer access

Local/private Developer API

The versioned Developer API and TypeScript, Python and Jupyter source clients support explicitly enabled local/private evaluation. A stable production-public or browser API is not available, and MissionLab does not host arbitrary learner Python, JavaScript or shell execution.