claudetools/.claude/memory/feedback_no_inferred_topology_as_fact.md

name, description, metadata

name	description	metadata
feedback_no_inferred_topology_as_fact	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.	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.