One engine. New trades ship as files.
SimOS is the runtime: a base environment, an interaction system, and a grading pipeline. Playbooks are declarative scenario files: chapters, spawn manifests, triggers, fault injection, scoring rubrics. Adding an occupation means writing a Playbook and building assets. It doesn’t mean building a new product.
That’s the whole architecture argument: the first trade pays for the platform, every trade after that is margin.
One environment running on SimOS. The trades bay, the clinical room, and this control room are the same runtime with different Playbooks.
Three layers, shared by every occupation.
Base environment
Physics, hands, tools, spatial audio, and the shared interaction grammar every scenario inherits. Built once. A welding bay and a submarine bridge use the same one.
Interaction system
Grabbing, actuating, measuring, speaking. Every interaction emits a typed event, which is what makes the session gradable rather than just recordable.
Grading pipeline
Consumes the event stream plus what the trainee saw and said. Emits machine-verified gates and scored judgment dimensions.
An occupation is a file, not a fork.
A Playbook is declarative. It describes what the procedure is and how it is graded; it does not contain engine code. That constraint is deliberate. It is what keeps a second, tenth, or fiftieth occupation from becoming a second codebase to maintain.
Playbook contents
- chapters
- Ordered phases of the procedure, with entry and exit conditions
- spawn manifests
- What exists in the scene, where, and in what state
- triggers
- Conditions that advance, branch, or flag the session
- fault injection
- The things that go wrong, and when they are introduced
- scoring rubrics
- Gate definitions and judgment dimensions with their weights
Where the defensible part lives.
Gates are deterministic and checked in the engine: binary, auditable, with no model in the loop. The judgment layer scores what a gate can’t: sequencing under pressure, diagnosis speed, stop-work decisions, and whether a handoff was honest.
Every graded session produces a Readiness Record with both halves and an expiry date. That record is the thing an employer is actually buying.
Hardware reuse and content leverage.
- Hardware is reused, not re-bought
- The same headsets run every Playbook. A district or an employer buys a fleet once and adds occupations against it, which is why our per-occupation cost is content cost rather than deployment cost.
- The first trade pays for the platform
- Engine work, interaction primitives, and the grading pipeline are amortized across everything that follows. Each additional occupation is a Playbook and an asset build.
- Grading improves across the whole catalog
- Judgment scoring is built at the platform layer, not per title. An improvement to how we score communication under pressure lands in every occupation at once.
Two modes, chosen by the job.
- Browser
- Career exploration. No install, runs on district hardware, no headset required.
- Headset
- Training and qualification. Procedure work needs hands, and grading needs the interaction data a headset produces.
Your records are yours.
Session data and Readiness Records belong to the institution that ran the cohort. You can export them, and you can take them with you if you leave.
Student data is handled under the agreement your district already requires. We do not sell it, and we do not use identifiable learner data to train models.
We use aggregate, de-identified performance data to calibrate scoring, for example to establish the cohort medians a record is compared against.
Book a call
Engineering and diligence questions welcome. We would rather walk you through the grading pipeline than send a deck.
We’ll tell you on the first call if this doesn’t need VR.