Three sources, three failure modes
Settings app
Hides blocked-by-policy or managed states; may reflect group intent after host reload
Registry direct
Shows bytes; ignores who wrote them (user, tool, or policy) and whether an agent will overwrite at next refresh
Windows Runtime API
Caveated by the caller's context; a per-user read different from service-context reads
Documented-safe auditing order
- Registry first for current bytes — never filtered, never refreshing silently;
- API second for effective behavior — ties bytes to live answer;
- UI third for validation of end-to-end user experience — shows what your login revision refused to load.
Machine-archeology technique: the combination catches every class of tool — the ones that claim persistence without writing (registry vs. API disagree), the ones that write but lack any effect (UI mismatch), and the policy-managed blocked state (API wins over both). Read-then-trust beats trust-and-guess again.
ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.