University · Digital Twin Lab

From mission requirement to traceable software evidence.

A guided ML-D workflow over the accepted MissionLab runtime. Use the university teaching definition, engineer Mission Control, synchronized comparison, local replay, and Evidence V2 export without creating a second simulator.

Launch engineer Mission Control University overview

Twin definition

university_3u_engineering

Execution

Local software practice

Mission Control

Engineer / Advanced

Truth status

SIMULATED · 0 measured

Six-step laboratory workflow

Each step is a presentation route into existing MissionLab ownership. No model equation or runtime contract is duplicated here.

01mission
Frame a requirement
Start with an ML-D mission, a bounded configuration, and a claim the accepted runtime can actually test.
Evidence checkpoint
Mission objective · success criterion · declared limitation
Open the reference ML-D mission
02configuration
Inspect configuration identity
Use the university 3U teaching definition and inspect the selected model bindings before interpreting results.
Evidence checkpoint
Spacecraft definition · model/version identity · configuration hashes
Inspect advanced identity
03operate
Run Mission Control
Execute one deterministic software-only practice run, then inspect units, channel roles, source models, and freshness.
Evidence checkpoint
Immutable local replay · simulated and derived channels · zero measured channels
Enter engineer Mission Control
04compare
Compare and replay
Use the existing same-seed comparison to study how the school 1U and university 3U teaching definitions change the run.
Evidence checkpoint
Shared seed · synchronized replay cursor · baseline/variant deltas
Open synchronized comparison
05evidence
Review evidence quality
Separate availability, provenance, fidelity, calibration, validation, and parameter source instead of collapsing them into one quality label.
Evidence checkpoint
Independent fidelity axes · lineage · limitations · Evidence V2 export
Review fidelity and lineage
06course
Map to the course
Faculty can map MissionLab outcomes and evidence into their own approved CLOs without transferring accreditation authority to CubeSTEM.
Evidence checkpoint
Illustrative CLO label · MLO trace · mission evidence · assessment method
Review mapping examples

Mission Control is the engineering instrument

The lab reuses the accepted workbench instead of rendering a university-only telemetry dashboard.

Inspect advanced disclosure

Existing Mission Control capabilities used by the university workflow.
Engineering layer	Accepted presentation
Configuration	University 3U teaching definition and bounded scenario selection
Model identity	Component/model IDs, versions, provider context, and hashes
Channels	Units, roles, source fields, freshness, and explicit availability
Provenance	Simulated, derived, reference, estimated, and measured remain distinct
Fidelity	Representation, fidelity, calibration, validation, and parameter source stay independent
Lineage	Definition, execution, compile, run, frame, and evidence identities where provided
Evidence	Same-seed compare, immutable local replay, limitations, JSON and Markdown exports
V&V boundary	Software evidence supports bounded conclusions, not flight qualification

Open engineer view Compare school 1U and university 3U

Illustrative course and CLO mapping

Faculty own official CLO wording, approval, rubrics, and grading. These examples show the presentation pattern only.

KFU · Attitude-to-power verification studio

Mapped in framework

Illustrative · non-officialMLX-15

Space systems · controls · electrical power

A student team traces a declared attitude change into modeled solar-energy evidence, checks reproducibility, and writes a bounded V&V conclusion.

Open ML-D mission Open Mission Control

KFU illustrative programme scenario

Illustrative CLO-A: assess a coupled spacecraft energy claim using configuration-controlled simulation evidence.

Presentation example only. It has not been reviewed or approved by KFU and is not an official CLO.

MissionLab outcomes: MLO-01 · MLO-02 · MLO-06 · MLO-09 · MLO-10
Evidence: Configuration identity, attitude/energy channels, same-seed replay, assumptions, and a V&V-style conclusion.
Assessment ownership: Faculty-reviewed technical memo using the institution's own rubric.

UMP · Orbit-to-contact evidence review

Mapped in framework

Illustrative · non-officialMLX-07 · MLX-06

Mission operations · communications · systems engineering

A student team distinguishes modeled visibility from reception and decode, then produces a requirements-based contact-plan evidence review.

Open ML-D mission Open Mission Control

UMP illustrative programme scenario

Illustrative CLO-B: evaluate a mission contact plan against declared model provenance, constraints, and evidence gaps.

Presentation example only. It has not been reviewed or approved by UMP and is not an official CLO.

MissionLab outcomes: MLO-05 · MLO-06 · MLO-07 · MLO-09 · MLO-10
Evidence: Modeled pass evidence, declared scheduling context, replay trace, provenance boundary, and measurement plan.
Assessment ownership: Faculty-reviewed V&V matrix and operations briefing using the institution's own criteria.

Developer Core API / SDK boundary

Implemented local/private developer access, source examples, and the production-public limit shown separately.

AVAILABLE LOCAL PRACTICE

Current execution path

local

Mission Control uses the existing database-free /api/v1/missionlab/twins practice route and accepted local runtime ownership.

AVAILABLE OPT IN LOCAL PRIVATE

Core Developer API

cubestem.dt-core.developer.v1@1.0.0 provides version, discovery, curated run, same-input comparison, and bounded export operations under /developer/v1. It is disabled by default, loopback/private, and has no compile or browser credential flow.

AVAILABLE SOURCE EXAMPLES

TypeScript, Python, and Jupyter examples

Server-side and desktop source clients demonstrate reproducibility, provenance, lineage, limitations, comparisons, and in-envelope exports. They are not a hosted learner SDK or BYO-model execution environment.

NOT PRODUCTION PUBLIC

Institutional production access

A5 api_access is a commercial denial capability only: it issues no token, implements no metering, and grants no role or protected authority. Production service operation remains separately gated.

Minimum V&V review

Use this checklist before promoting a simulation result into an engineering conclusion.

Software-only evidence review; institution-specific criteria remain faculty-owned.
Review item	Required trace
Requirement	Name the bounded claim and acceptance criterion before running.
Configuration	Record the spacecraft definition, scenario, seed, and model identities.
Evidence	Cite channel IDs, units, roles, provenance, source models, and replay frame.
Repeatability	Use deterministic reconstruction or same-seed compare; do not imply persistence.
Validity	Keep representation, fidelity, calibration, validation, and parameter source independent.
Conclusion	State what the software supports and what requires calibration or authorized measurement.