Fix wording in IP Fabric documentation

content/documentation/ip-fabric/_index.en.md

@@ -40,7 +40,7 @@ That snapshot model is what makes several of the use cases below possible: becau
 
 This is the use case that started it all for me, and the one referenced directly in the blog series. IP Fabric builds a topology diagram and a set of relational tables (devices, interfaces, neighbors, VLANs, VRFs) from live discovery, not from a manually maintained spreadsheet or a Visio diagram someone forgot to update.
 
-For my EVPN/VXLAN lab, that means I have an always-current answer to "what's connected to what" without trusting my own memory or an out-of-date diagram. This is the layer an AI agent would need to query first, before anything else, if it's going to reason correctly about the network — which is the whole point of the "blind agent" problem from the blog series: an agent working off stale topology data is confidently wrong, not cautiously uncertain.
+For my EVPN/VXLAN lab, that means I have an always-current answer to "what's connected to what" without trusting my own memory or an out-of-date diagram. This is the layer an AI agent would need to query first, before anything else, if it's going to reason correctly about the network — which is the whole point of the "blind agent" problem from the blog series: an agent working off stale topology data answers with confidence even when it's wrong.
 
 ![Topology diagram of the EVPN/VXLAN lab, generated by IP Fabric](ipfabric_network_diagram.en.png#center)
 
@@ -48,7 +48,7 @@ For my EVPN/VXLAN lab, that means I have an always-current answer to "what's con
 
 Intent checks are rules you define once, things like "no unused VLANs," "STP root should be on the core switches," "every access port should have BPDU guard" — and IP Fabric evaluates them against every snapshot going forward. Failures show up as color-coded checks you can drill into, all the way down to the specific device and interface that broke the rule.
 
-This is where IP Fabric moves from "descriptive" (what's out there) to "normative" (is what's out there correct). It's a natural fit for the standardization principle I keep coming back to in the blog series: intent checks are a way to enforce naming and configuration consistency automatically, instead of relying on a human to notice drift.
+Here, IP Fabric moves from "descriptive" (what's out there) to "normative" (is what's out there correct). It's a natural fit for the standardization principle I keep coming back to in the blog series: intent checks are a way to enforce naming and configuration consistency automatically, instead of relying on a human to notice drift.
 
 ![Intent check rules and their results, color-coded pass/fail](ipfabric_intent.en.png#center)
 
@@ -64,7 +64,7 @@ This turns "why can't this host reach that host" from a multi-device, multi-`sho
 
 Because every discovery run is preserved as its own snapshot, IP Fabric can diff two of them directly (one from before a change window, one from after, for example) and surface exactly what's different: new or removed devices, VLAN changes, routing table deltas, interface state changes.
 
-This is the practical answer to "what actually changed," which is normally the hardest question to answer after an incident. Instead of reconstructing a timeline from memory or from scattered change tickets, the diff is already sitting there.
+That's the practical answer to "what actually changed," normally the hardest question to answer after an incident. Instead of reconstructing a timeline from memory or from scattered change tickets, the diff is already sitting there.
 
 ![Diff between two snapshots, with added and removed elements highlighted](ipfabric_snapshot_diff.en.png#center)