---
name: feedback_no_inferred_topology_as_fact
description: Never present an inferred network link as an observed fact; private-IP overlap is not evidence of a shared fabric, and a failed reachability test disproves a link rather than needing to be explained away.
metadata:
  type: feedback
---

On 2026-06-12, investigating VWP-ROSE (Valley Wide Plastering), I concluded Valley
Wide was "Local" to the ACG office via a site-to-site VPN. Mike: there is NO
site-to-site between VWP and the office. I had fabricated the link.

**Why it was wrong:**
- I asserted "VWP-ROSE reached the office RMM server (172.16.3.30) by its real
  private IP with no NAT" — I never observed that. Field agents connect to
  `rmm-api.azcomputerguru.com` (PUBLIC IP), like ~199/200 of the fleet. `172.16.3.30`
  is only *my* office-side base URL; the agent never uses it.
- I read a `172.16.x` overlap (office `172.16.3.x` vs VWP `172.16.9.x`) as a shared
  fabric. It is coincidence — `172.16.0.0/12` is RFC1918 space countless unrelated
  LANs reuse. Overlapping private ranges prove nothing.
- My own test (force `172.16.3.30` over the corp NIC) FAILED — that disproved the
  link. I rationalized it as "asymmetric routing" to preserve my conclusion.

**How to apply:**
- State only what was observed; label inferences as inferences. Never narrate an
  unobserved packet/path as if it happened.
- Private-IP overlap is NOT evidence two networks are connected. Require positive
  proof (a tunnel config, a successful end-to-end reach with the real source IP).
- When a test contradicts the hypothesis, update the hypothesis — do not invent a
  mechanism to dismiss the failure.
- To test "can this adapter reach RMM," use the EXTERNAL endpoint
  (`rmm-api.azcomputerguru.com` / its public IP), not the internal `172.16.3.30`.
  Nearly every agent is external. See [[reference_gururmm]].
