The safety gate stopped the experiment
EXP-071 tests whether disabling Microsoft Edge background mode improves demand-launch behavior. Before touching the Edge policy, its provider checks the machine, Edge identity, policy ownership, startup-folder state, elevation, and management state.
On the physical HP lab machine, almost every eligibility check passed: Windows 11, HP hardware, administrator elevation, Edge detection, supported Edge version, Microsoft signature, no existing mandatory ownership of the target policy, no existing recommended value, and no Edge Startup-folder entry.
The failing line was management. The diagnostic showed DomainJoined = False, ConfigMgr = False, PolicyManager = True, and MdmEnrollments = 36. That 36 was a raw registry-child count. It was not evidence of 36 active MDM enrollments.
The detector was too broad
The original EXP-071 logic treated the existence of Windows PolicyManager state or enrollment-container children as enough to classify the machine as managed. That is a conservative safety rule, but it collapses several different conditions into one answer: active external management, self-created registration, and residual enrollment artifacts.
The target Edge setting itself had no detected mandatory or recommended owner. The experiment therefore exposed a product defect before it changed Windows: the management gate could refuse a self-managed lab machine based on historical or generic state that did not own the candidate policy.
That refusal is useful evidence. We preserved it and created EXP-137 rather than deleting random registry keys or weakening the EXP-071 guard.
EXP-137 turns cleanup into an explicit workflow
UX-ROM now has a dedicated self-managed enrollment maintenance path. It captures the current registration state first, classifies GUID-scoped enrollment records, makes the operator-authorized cleanup, reboots, verifies the later state, and resumes EXP-071 automatically.
The workflow captures dsregcmd /status, enrollment and OMADM registry state, Workplace registration, MDM auto-enrollment policy state, and Microsoft Windows EnterpriseMgmt scheduled-task XML. It keeps structured JSONL logs plus local registry and task backups before mutation.
For this workflow, self-managed enrollment state is operator-controlled. The cleanup can disconnect self-created Workplace registration, remove captured residual or correlated enrollment artifacts, remove their EnterpriseMgmt enrollment tasks, and clear captured self-managed MDM auto-enrollment values. It refuses a domain-joined, Microsoft Entra joined, or Enterprise-joined device because removing a full device identity belongs to a different workflow.
Windows Update, Defender and Firewall, Edge Update, and Microsoft Edge user data are outside the cleanup mutation boundary. Passwords, profiles, cookies, favorites, history, and extensions are not cleanup targets.
After cleanup, UX-ROM runs EXP-071 through its configuration lifecycle, registers a one-shot elevated continuation, reboots, verifies dsregcmd and protected configuration, then checks EXP-071 reboot persistence. The evidence stays under the UX-ROM data root for review.
We also introduced a UX regression, then fixed it
The first EXP-137 integration moved the original controller behind a bootstrap entrypoint and exposed enrollment cleanup mainly as a direct command. The ASCII UX-ROM controller still existed in the repository, but the new workflow felt detached from the interface we had already built.
That was the wrong product shape. The correction restores the normal ASCII splash and twelve-layer UX-ROM experience and adds E. Self-managed enrollment cleanup inside the same main menu. Diagnostics, all twelve layers, the synergy batch, status, maintenance tools, direct automation, and the EXP-137 path now coexist in one interface.
A regression test now requires the ASCII UX-ROM surface and integrated enrollment choice to remain present. We also kept a short engineering note about the regression rather than erasing it from project history.
What is measured, what is implemented, and what remains unknown
Physical observations
- The EXP-071 machine check passed every displayed eligibility condition except the old management gate.
- The old diagnostic observed 36 enrollment-container children, PolicyManager state, no domain join, and no ConfigMgr service.
- The target Edge background-mode policy showed no existing mandatory owner and no existing recommended value.
Engineering now merged
- EXP-137 captures and classifies self-managed enrollment state before cleanup.
- EXP-071 now distinguishes active correlated MDM evidence from generic PolicyManager or historical enrollment-container presence.
- The cleanup resumes EXP-071 across a reboot and retains structured evidence.
- The UX-ROM ASCII menu now exposes EXP-137 as an integrated menu action.
Still requires physical evidence
- Which of the captured enrollment records are active versus residual on the lab machine?
- Does the cleanup make EXP-071 physically eligible after reboot?
- Does rollback restore the intended captured local state without collision or drift?
- Do five matched baseline and five treatment Edge launches show a repeatable benefit?
Performance claim
- None yet.
- The management-gate failure is a validation result, not a speed result.
- EXP-071 needs repeated launch timing, medians, reboot persistence, regression checks, and rollback evidence before a release decision.
What comes next
The physical lab run now has one job: execute the integrated EXP-137 workflow on the same HP machine, preserve the before state, reboot through the one-shot continuation, and see whether EXP-071 becomes eligible.
If it does, the Edge benchmark proceeds with five matched baseline runs and five treatment runs. The decision uses repeated measurements and medians. If cleanup changes nothing useful, the result stays in the record as inconclusive or rejected instead of being converted into a performance claim.