University · Digital Twin Lab

From mission requirement to traceable software evidence.

A guided public workflow for student teams: frame a requirement, run it, compare two supported spacecraft configurations and write a bounded V&V conclusion. Mission Control inspects the practice run; configured Mission Studio persistence requires sign-in.

Run University 3U Mission Control Sign in to Mission Studio University overview

Spacecraft

University 3U teaching definition

Execution

Local software practice

Mission Control

Engineer / Advanced

Truth status

SIMULATED · 0 measured

Technical identifiers

Twin definition: university_3u_engineering
Comparison baseline: school_1u_trainer

Six-step laboratory workflow

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

01
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
02
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
03
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
04
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
05
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
06
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 access

Developer API access is opt-in, local and private, with source examples. It is not a public production API and does not host learner code.

Developer Core API / SDK boundary

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.