The baseline: is the district's physical and logical network documented in a maintained diagram? “Outdated” is acceptable but flagged for follow-up; “No” is a hard finding.

Review/refresh discipline for the topology diagram. Documentation that isn't periodically validated drifts into shelfware — the diagram described last year's network.

Who can actually pull up the diagram when it's needed during an incident. Documentation locked to a single person's laptop or to a vendor portal doesn't help during a 2 a.m. outage.

Logical separation of traffic across functional roles. A flat single-broadcast-domain network is a hard finding — student devices, staff devices, building automation, and management traffic should not share a broadcast domain.

Which functional zones are present as discrete VLANs / subnets. More zones ≠ better — but the absence of an expected zone (e.g. no dedicated guest, no separate management VLAN) is itself useful signal.

How traffic crosses VLAN boundaries. Layer-3 switching scales; firewall-routed inter-VLAN concentrates policy but adds a chokepoint; flat is the absence of segmentation in practice regardless of F4's answer.

Whether guest traffic is isolated from the internal network at both the wireless and the VLAN layer. “Guest = student network” is a category error worth flagging.

Whether the network core can survive a single device failure. Districts often run a single core with a cold spare; the question is whether the failover path is documented and rehearsed (see Monitoring & Management).

Whether end-of-life / end-of-support dates are tracked for the network fleet. Companion to the TSI lifecycle posture surface — but network-specific because firmware-EOL devices can't receive security patches.

Cadence and last completed end-to-end validation of the documented topology against the running network. Different from F2 (review of the document) — this is rack-walking to verify the doc matches reality.