Case Study: Platform Enablement & External SDK Adoption

Context

The Aviation Boatswain’s Mate Handling (ABH) – Conflagration Station trainer marked the first instance of a company outside of Proactive developing a trainer using the MRTS SDK.

Until this point, the SDK had been used exclusively by internal teams. Expanding the platform externally introduced new risks: inconsistent architectural interpretation, fragmentation of usage patterns, and potential erosion of deterministic simulation guarantees.

The SDK was architecturally mature but lacked a formal user manual. Due to government contract allocation models, internal documentation initiatives were not funded. No comprehensive SDK training materials existed, and no official manual had been requested by the program office.

I was responsible for enabling the external team to build correctly on the platform while preserving its architectural integrity.

Problem Framing

The primary risk was not technical implementation, but platform misuse. As the first external adopter of the MRTS SDK, the team needed to understand how to compose training simulations within the framework’s architectural boundaries. While synchronization and messaging operated under the hood, correct component-level usage was essential to preserving the platform’s deterministic guarantees.

Constraints included:

No internally funded documentation effort
No pre-existing structured training materials
Limited long-term architectural oversight
Training artifacts created during the engagement being contractually owned by the external company

The objective was to ensure correct platform adoption without direct implementation control.

Enablement Strategy

Rather than attempting to create exhaustive documentation, I focused on transferring architectural mental models and practical usage patterns.

Training emphasized:

How to compose simulations using the SDK’s component model
Where extension points were safe and where boundaries should be respected
How authority and state propagation were handled implicitly
Proper integration patterns that aligned with the deterministic simulation model
Avoiding coupling to lower-level transport or internal implementation details

I developed structured walkthroughs and targeted materials tailored to how the external team would interact with the SDK in practice.

The goal was durable understanding — not exposure to internal mechanics.

Organizational Impact

The external team successfully developed their trainer using the MRTS SDK while preserving platform guarantees.

This first external adoption:

Validated the SDK’s abstraction maturity
Extended platform usage beyond internal teams
Reduced the risk of architectural drift during expansion
Reinforced consistent component-level usage patterns

Although the training materials created during the engagement were contractually transferred, the architectural alignment established during onboarding strengthened the platform’s long-term coherence.

Lessons Learned

The first external adoption of a platform is a structural moment. When documentation initiatives are constrained, architectural stewardship requires direct enablement and principle-driven teaching. A mature platform should encapsulate its complexity, but correct usage still depends on shared mental models. Enabling others to build correctly is as critical to system integrity as the original design.

Case Study: Platform Enablement & External SDK Adoption