Yes — the manifest requests no network access, and every check reads local scene/disk data only.

Yes — bake state is read directly from the domain's has_cache_baked_data / _noise / _mesh / _particles / _guide properties.

To stay fast on long simulations. It checks start, end, and several interior frames rather than every file — a gap between sampled frames could theoretically still be missing, which is why this is documented as a known limitation, not hidden.

Cache Guardian will flag issues on linked data, but won't trigger a re-bake on objects it doesn't locally own — you'll need to re-bake those from their source file.

There's no historical fingerprint yet, so Cache Guardian records the current settings as the new baseline the first time it scans that object, then checks for drift from there.

Blender has no single built-in flag for "this cache is outdated." Cache Guardian fingerprints the relevant settings (mass, stiffness, resolution, frame range, etc.) at bake time and compares them on every scan. A mismatch means settings changed since the last bake — it's a heuristic, not a guarantee the cache is invalid.

No. The pre-render check (if enabled) runs once before rendering starts and only shows a warning popup — it never blocks, cancels, or delays the render itself.

No. Everything runs locally against scene data and local disk files.