01Source hierarchy
Primary Microsoft Support, Microsoft Learn, and Sysinternals documentation comes first. Historical archive material is used only to understand old URLs and topic scope, never to support current Windows instructions.
02Normalization
The Atlas turns separate documentation into consistent phase, scope, inspection, reversibility, caution, source, and checked-date fields. If a source does not establish a field, it is not guessed.
03Review and change log
Sources are reviewed quarterly and after material Windows, Task Manager, or Autoruns changes. A record change retains prior value, new value, source, reason, and checked date.
04Controlled tests
A later controlled Windows test may verify a field mapping. It records build, tool version, commands, date, and data removal steps.
05Start with the source that owns the mechanism
The Atlas gives priority to current Microsoft Support, Microsoft Learn, and Sysinternals documentation because those sources describe Windows controls and system mechanisms directly. A secondary explanation can help with context, but it cannot silently replace the primary record for a technical claim. Historical archives are useful for URL continuity and subject framing; they are not treated as current operating instructions without a fresh source check. Every record therefore carries a source, a checked date, and a practical limitation.
06Normalize only what the source supports
The working fields are phase, scope, inspection tool, least destructive move, caution, and source. They give readers a consistent way to compare a Startup folder with a scheduled task without pretending that the mechanisms are interchangeable. If the source does not establish a field, the Atlas leaves it open or describes the limit in plain language. Normalization improves navigation and comparison; it must not create a number, ranking, safety verdict, or timing claim that the source never made.
07Review a change as a change
When documentation or Windows behavior changes, the review should identify the affected record, the old wording, the new source, the reason for the update, and the date. A reader correction is most useful when it includes the exact URL, Windows version, tool version, reproduction steps, and the condition that makes the result repeatable. A single machine can support a carefully bounded observation, but not a prevalence claim or a universal performance ranking. The correction path is part of the publication, not an afterthought.
08Use limitations as navigation
A limitation is not an apology added at the bottom of a page. It tells the reader which next source or test is appropriate. If the record names a location but not the behavior of a particular vendor program, follow the publisher's documentation or design a bounded observation. If a label is only a clue, do not turn it into a ranking. The methodology keeps those boundaries visible so later pages can stay concise without becoming vague.
Continue from here
Sources for this page
- Configure Startup applications in WindowsMicrosoft Support
- AutorunsMicrosoft Learn, Sysinternals
- Windows Performance RecorderMicrosoft Learn