Shared Engine and Pilot Acceptance
The OEM runtime imports the same backend/module implementations used by the desktop product. It has a separate entry point, state profile, transport and packaging target. It does not maintain a second copy of the cleanup or AI engine.
How engine improvements reach OEM
| Shared area | OEM applicability |
|---|---|
| Signed licensing, clock compatibility, device and expiry checks | Required; OEM also checks signed partner/protocol and feature permission |
| Cleanup, memory, protected paths, quarantine and job evidence | Shared for explicitly requested optimization |
| Optimization policy/guards and progress | Shared manual-job behavior |
| Local AI model/policy protection and model progress | Shared modules; isolated OEM data |
| Continuous autonomous AI scheduling | Lifecycle/stop/pause acceptance still required; not enabled in the pilot |
| Desktop UI, tray, carousel and browser sign-in | Partner supplies its own UI/workflow |
| Desktop installer/update and privileged Windows controls | Separate OEM delivery/permission acceptance; no general IPC forwarding |
OEM builds check a reviewed manifest of canonical core files. When those files change, the build stops until the applicability review and tests are updated. Relevant fixes are taken through shared imports rather than copied into a parallel engine fork.
State, credentials, model data and operation history are separated by Windows user, partner and protocol. The pilot does not import the standard application's existing customer cache or model data. Per-user process ownership and normal-desktop conflict checks reduce duplicate maintenance; co-installation/race coordination remains an acceptance gate.
Before a partner customer rollout
- Complete the partner's C++ ABI, threading and UI lifecycle tests with the exact x64 package.
- Verify normal-user/admin permissions, install/update/uninstall ownership and behavior alongside the partner's antivirus scans.
- Use the agreed OEM entitlement and protected secret storage. Verify wrong partner/protocol, expired license and offline behavior.
- Validate cancellation, interrupted jobs, duplicate requests and callback replay/dead-letter handling.
- Complete clean Windows 10/11 and antivirus compatibility checks, publisher signing and runtime/package integrity acceptance.
- Decide whether autonomous scheduling is needed, then finish its stop/pause/revocation and single-owner contract before enabling it.
The pilot provides an integration contract and testable components. It does not promise a single-file native AI engine, absolute resistance to local reverse engineering, a production-signed installer, or a tested integration with a partner application that has not been supplied.