A framework, not a ready-made mission
A mission-control screen can look convincing before it explains a single measurement correctly. Open MCT is interesting because its documented model goes deeper than arranging plots. It provides a framework for organizing meaningful objects and extending their behavior, while leaving the application builder responsible for the actual system being represented.
The reviewed Open MCT README describes Open Mission Control Technologies as a data-visualization framework for desktop and mobile devices. It identifies NASA Ames as its development origin and describes use in spacecraft data analysis and experimental rover planning and operations. Those are project-level statements from the documentation, not evidence that any particular FLLC screen has been validated for mission operations.
Start with the project's vocabulary
The README defines a domain object as a meaningful object in the user's work. Objects appearing in the navigation tree are domain objects. An identifier combines a namespace and a key; a model is the persistent, JSON-compatible state associated with an object. Composition describes the objects contained beneath another object.
These definitions are more useful than a screenshot when deciding how to structure an application. A measurement channel, a payload assembly and an analyst's view do not have to be treated as the same kind of thing merely because they appear on one screen. The framework's terminology gives an application team a way to discuss identity, organization and persistent state explicitly.
The documentation describes plugins as removable, reusable groups of components and resources. It also notes that much of Open MCT itself is implemented through plugins. The extension mechanism is therefore central to the documented architecture rather than an incidental customization feature.
A proposed telemetry contract for FLLC
The following is an integration design proposal, not a description of an existing Open MCT deployment. Before building a new visualization, specify what one observation means. Record its channel identifier, measurement unit, observation time, receipt time, provenance and validity state. Decide which of those fields the source actually supplies and which would be calculated by the application.
Consider a synthetic balloon payload with a temperature channel and a position channel. A display needs to distinguish a missing temperature sample from a measured zero. It also needs to distinguish an older position from a current one. Merely drawing both channels on the same page does not resolve either issue.
For this proposal, channel identities would stay stable across view changes, while presentation labels could change without rewriting the underlying observations. A payload object could organize its channels through composition. The source adapter would document its timestamp interpretation instead of letting each view invent one. These are application design choices inspired by the framework's documented concepts; the README does not supply a complete adapter for this example.
Do not confuse a demonstration with a deployment
The README provides a local development workflow and points to tutorials and API documentation. It also explicitly characterizes Open MCT as an extensible framework intended to be used as a dependency with an application's own plugins and packaging. Its related-project section discusses hosting behind an HTTP server.
For FLLC, that means a successful starter screen would establish only that the starter screen runs in that environment. It would not establish the correctness of imported telemetry, persistence, access policy, operational alerting or failure recovery. Each of those needs its own evidence.
A useful first integration milestone would be a small, clearly labeled synthetic dataset displayed consistently across the chosen views. A second milestone would be controlled playback of a permitted historical dataset. A live source would come only after the team has specified how delays, missing observations and reconnection are represented. These are proposed milestones, not claims of completed testing.
Test the representation, not only the launch command
The reviewed README describes unit, end-to-end, visual, performance and security testing. It identifies Jasmine and Karma for unit tests and Playwright for several browser-oriented suites. It also points to CodeQL analysis. The presence of those test systems in the project does not transfer a passing result to a downstream application.
For the proposed FLLC adapter, a test record should describe the supplied observations, expected units, selected time range and expected display state. A delayed sample should not become a new observation simply because it arrived later. A reconnect should not make a gap disappear from the record without explanation.
Mobile support is similarly a project goal documented by the README, not a device-specific acceptance report. The current iPad workflow should be checked for touch navigation, legible labels, orientation changes and the behavior of the actual dataset. No iPad performance results are asserted here.
Version boundaries are part of the design
The README notes the removal of the legacy bundle-based API and identifies a separate compatibility plugin whose long-term maintenance and future testing are not promised. It also directs developers to package metadata for supported environments.
The practical lesson is to record the exact version and extension API used by an integration. An older example may explain a concept without being an appropriate implementation template for the selected release. This review does not infer that the user's fork is synchronized with the latest upstream release.
Sources and review scope
Personfu/openmct README, reviewed September 22, 2026. The repository is listed in FLLC's curated Starred Repositories catalog; live GitHub star membership was not independently checked. The telemetry contract and milestones in this article are proposed FLLC engineering work, not a completed mission-control integration.