The Guardian engines explained

Guardian's work is split into small, single-purpose "engines." Each one does exactly one job, and the main cycle runs them in order every 3 minutes. The Guardian page lists all 16 numbered engines on its status card; some run every cycle and the housekeeping ones run on slower schedules. Here's what each one actually does — in plain English.

The detection engines (always run)

• Emulator Detection — scans for the known Android emulators: GameLoop, BlueStacks, LDPlayer, Nox, MEmu and MuMu. This is the gatekeeper. If no emulator (and no native game) is found, the aggressive engines are skipped entirely.
• Memory Monitor — reads how much RAM is free and logs it. If you're not gaming and free RAM drops below roughly 10% of your total, it does a gentle working-set trim (throttled to once every 10 minutes). It will never do this mid-game.
• Game Detection — checks running processes against BRUTAL's built-in game profiles (both Android and native PC games). When it finds a match it can auto-apply that game's profile (Pro) with settings chosen for your hardware tier and GPU vendor. A native PC game launched while an emulator merely sits idle is correctly treated as a PC game — Guardian won't elevate or RAM-lock the idle emulator for it.

The aggressive engines (Pro, only while gaming)

These run only after a game is confirmed in an Android emulator. They target the emulator process, not your whole system, and never a PC game's own process.

• Priority Elevation — raises the emulator to High CPU priority (not Realtime — Realtime can starve the system). Reverted to Normal when gaming ends.
• Native runtime tuning (Pro) — handled by the NativeOptimizer. It activates a 0.5 ms system timer for tighter frame pacing, asks Windows for High I/O priority for the emulator, disables Windows 11 EcoQoS power throttling so it isn't downclocked or shoved onto efficiency cores, and locks a 512 MB minimum working set so its memory stays resident in RAM. The working-set lock only happens when there's at least double the RAM free, as a safety check.
• Process Watchdog — force-closes a curated list of background extras (Widgets, Phone Link, Cortana, the Edge updater, telemetry helpers, animated-wallpaper apps and known crypto miners). It deliberately never kills the Print Spooler, OneDrive or your chat apps — doing so would lose print jobs, sync progress or messages for almost no gaming benefit.
• Service Watchdog — temporarily stops the diagnostics and telemetry services (DiagTrack, DiagSvc and DPS) for the session. The Print Spooler is excluded for the same reason as above. Crucially, every service it stops is restarted automatically when gaming ends.

The App Priority Manager (Engine 12, Pro)

This engine keeps chat and launcher helpers out of your game's way without breaking your chat. While any game runs (PC or emulator) it:

• For apps that can carry a voice call — Discord (Canary and PTB too), Slack and Steam's web helper — lowers only the helpers that are provably not the call: the GPU process, the crash handler and two named utility services, and only their I/O and memory priority, so Windows reclaims their memory first if it needs RAM. The renderer (where Discord's voice runs), the network and audio services and the main process are never touched, and nor is any helper whose role it cannot read.
• Lowers launcher web helpers (Epic, GOG Galaxy, Ubisoft Connect), cloud sync (OneDrive, Dropbox, Google Drive), updaters, the search indexer and Windows extras such as Widgets and Phone Link: lower I/O and memory priority, plus BelowNormal CPU priority where that is safe. Spotify, the touch-keyboard host and RGB-app interfaces get I/O and memory only. Telegram and WhatsApp are left alone, and a Process Rule you set on an app wins. Lowered priority, never closed.

When gaming ends, it gives every app it lowered back the priority it had, recorded before the change (an app whose priority something else has changed since is left as it is). These apps live between sessions, so leaving them throttled would be a bug — Guardian records each change before making it and puts it back, after a crash too.

The slow-cadence housekeeping engines

These don't run every cycle — they're rate-limited so they stay out of your way:

• Driver Check — at most once per 24 hours, queries Windows Update for driver updates and counts how many (and how many are gaming-relevant). It only detects by default; optional Pro auto-update runs on a background task with a system-restore point and a 20-minute safety ceiling. If Windows Update can't be reached, Guardian doesn't falsely claim "0 updates" — it retries next cycle. See reading the log to spot these entries.
• Auto-Clean (free) — opt-in and off by default. When enabled, at most once per 24 hours while idle, it cleans only safe junk categories (never the Recycle Bin, never while gaming).
• Process Rules — applies your per-app priority/affinity/EcoQoS rules from the Process Rules page each cycle, except to games BRUTAL recognises that use, or may use, an anti-cheat, and to any game it recognises while an anti-cheat service is running (those rules are refused, and the Guardian log says so).
• Defender status (free) — a daily, read-only check of Microsoft Defender's posture. It only nudges (e.g. "definitions are old"); it never shows scareware or claims you're infected.
• Persistence baseline (Pro) — a daily, detect-only diff of startup/persistence entries. It records a known-good baseline and tells you about new items to review — it never auto-removes anything.
• App Updates and Junk Measure (free) — a rate-limited check for app updates and a once-a-day, read-only measure of reclaimable space, both skipped while you game. They feed the dashboard's Needs you card.
• Idle Service Restore (free) — restarts the Windows Update services an optimize run paused, once your PC is idle and you're not gaming.
• Unattended Updates — opt-in and off by default: installs app updates only when your PC is idle and no game has run recently, and tells you when it did.

Why "single responsibility" matters here

Each engine is wrapped so that if one fails, it logs a short note and the cycle carries on — one flaky check can never break the whole pass. That's why the log is full of short per-engine lines (e.g. ② Available RAM: 5120 MB). It's a deliberate, auditable design rather than one giant opaque "optimize" button.