Docs gap: calibration guidance (empty-room meaning, duration) + trust/engine-error demotion diagnostics (from #1401)

[ruvnet]

Follow-up from #1401. Two documentation gaps flagged by a real deployment writeup, neither of which is a code bug — both about making existing behavior legible to operators.

1. Calibration/training: what does "empty room" actually mean?

ADR-135 and ADR-151 document the calibration algorithm (empty-room baseline, per-room specialists), but there's no operator-facing answer to:

• How many minutes of empty-room / occupied data are actually needed for a usable calibration?
• Does a pet in the room count as "occupied" or "empty" for calibration purposes — i.e., what will the resulting model actually key off?
• Do HVAC/fans/other stationary interferers need to be running (or not running) during the empty-room baseline capture to match real deployment conditions?

2. Trust / engine-error demotion system: what triggers it, how to diagnose, how to recover

The reporter hit ~20K+ engine errors and trust-demotion on both the shipped wifi-densepose-v1.rvf and a HuggingFace-converted model, with no way to tell from the outside what was actually wrong or how to fix it. Needs:

• What conditions cause a model to be trust-demoted (error types/thresholds).
• Where to look (logs/metrics) to see why a specific run got demoted.
• Whether/how a demoted model can be reset or re-validated, versus being permanently stuck.

Not urgent, not blocking — just tracked separately from #1401 so that issue could close on its actual "doesn't work" root cause without losing this follow-up.

[ruvnet]

Both gaps closed in #1457 (merged 2026-07-28):

• Calibration guidance → docs/calibration-guide.md — covers the hard 600-frame baseline minimum, per-anchor quality gate thresholds, the honest pet/small-motion presence-detection limitation (no size/species discrimination exists in the code), and what the empty-room baseline capture actually needs (steady background conditions, not silence).
• Trust/engine-error demotion diagnostics → docs/trust-and-engine-errors.md — exact trigger conditions for engine_error_count vs. the separate demoted flag, where they're exposed (/api/v1/status), the real diagnostic gap (no per-cause breakdown — the rate-limited log line is the closest thing today), and the WDP_GUARD_INTERVAL_US recovery path for persistent clock-drift demotion (the Make multistatic guard_interval_us configurable (hardcoded 5000 µs causes permanent trust demotion with 2 ESP32-S3 nodes) #1049 case).

Every specific number/threshold in both docs was checked against the real source before merging, not just the design ADRs — a few places where ADR-135's described behavior (drift_score/BaselineDrift staleness) isn't actually implemented in code are flagged explicitly rather than glossed over.

Closing.