Query the DataGraph
fix(how-to): add dated Correction callouts to 20 of 28 how-to/ articles, worst ratio of any category — two systemic defects (wrong Doorman A/B/C tier semantics across 5 articles; fictional 4-tier pairing model + /v1/tokens API across 4 articles, real model is 3-role User/Admin/Interface via /v1/invite+/v1/pair), plus fictional CLI commands/routes across 11 more articles for fleet nodes, GIS API, exports, ledger reading, deployment, key rotation, and binary-download auth; several already-self-corrected articles independently re-confirmed accurate
@@ -60,6 +60,8 @@ The DataGraph understands the platform's entity taxonomy: persons, organisations ## Handle a closed Tier A circuit **Correction (2026-08-02, verified against canonical `origin/main`):** DataGraph availability is not a Doorman tier. Real Tier A/B/C (`app-console-slm/src/health.rs`, the Doorman systemd unit) are local model / Yo-Yo GPU burst / external API fallback — DataGraph availability is a separate, unrelated status field (`entity_count`). Same systemic defect found across several `how-to/` articles this sweep. **Flagged, not resolved** — needs rewriting around the real, separate DataGraph-availability signal. If Doorman's Tier A circuit is `OPEN`, the DataGraph is unavailable. The inference stack falls back to Tier B (SLM only) or Tier C (local fallback), but `query_datagraph` calls will fail. Proceed with the following caveat in any content you are drafting: *"DataGraph unavailable — verified from session memory; check current state before committing."* Do not commit entity-dependent content during a Tier A outage without the caveat.