Defense · Stator Open Labs
Open Source
The OMS Developer Kit is how we make the conformant path the easy path: templates, libraries, CI, and a local stack you can actually run.
Why we publish this
The hardest part of open architecture is not writing a service. It is getting from running code to a defensible, assessed conformance posture. Captive SDKs and one-off pipelines do not scale across programs. A shared kit does.
Stator Open Labs publishes the OMS Developer Kit so a team can scaffold an OMS service in Rust or Python, pin the platform libraries, run the same GitLab CI umbrella, and prove UCI behavior with cucumber-uci. Schemas stay upstream in Open Arsenal. We do not relicense Government Owned XSDs.
What is in the kit
- Service templates. Rust (cargo-generate) and Python (Copier) scaffolds that already publish ServiceStatus, answer data requests, run BIT, and emit a Service Contract.
- Platform libraries. platform-crates and platform-pylib: the OMS Service runtime, UCI types generated at build time, and the LA-CAL / OWP client.
- Conformance harness. cucumber-uci: schema-generic Gherkin steps for UCI and A-GRA so conformance is a runnable spec, not a checklist in a slide.
- Pipelines and local stack. pipelines-oms CI components, Skylark loadout orchestration, and PostMaster for a live source × topic view of the bus.
Schema pin in CI and templates: oms_schema_version: "002.5.0" (UCI v2.5.0 / OMS 2.5).
How to start
The kit site is the getting-started path: pick Rust or Python, generate a service, then bring up Skylark locally and watch traffic in PostMaster. Source lives in the GitLab group; odk.statorco.com is the map.
The group is currently private on GitLab.com. Signed-in members with access can open the repositories. Public release of the group is a separate decision from this page.
Build on the standard
If you are integrating a mission capability as an independently procurable OMS unit, start with the kit, then talk to us about the service itself.