4. Method

4.1 Suite composition

Twelve suites, 4,668 checks: framework authentication, console dashboard,
security, capacity and cap enforcement, licence API, console UI behaviour, gated
local-AAA admission, simulated CPE (onboarding, traffic, QoS, churn), DORA
in-rush, dataplane, forwarding performance, and unauthenticated admission.

4.2 Pre-flight gate

The run does not start until twelve conditions hold. This is quoted verbatim
from the launch output because reproducibility depends on it:

===== 1/3 licence unit =====
  License state: VALID  (valid: true, 36500 days remaining)
===== 2/3 drain sessions to zero =====
  start: 0        final: 0
===== 3/3 launch gate =====
  OK   licence VALID          OK   grant 25000
  OK   cap 25000              OK   0 sessions
  OK   vpp connected          OK   status ok
  OK   aaa open               OK   Bronze shaped
  OK   pool /17               OK   captive portal set
  OK   access iface           OK   uplink iface
GATE: PASS
  BUNDLE_VERSION=1.4.0-13
  sha=9a12835 dirty=False

Two of these deserve explanation. Sessions are drained to zero explicitly
because a reboot does not clear them — the controller persists sessions and
restores them with their original timestamps, so a previous run's fleet would
silently become this run's starting condition. And the Bronze plan's rates are
verified because a cancelled run can leave the plan unshaped, which would make
every QoS result in §5.6 meaningless while still looking plausible.

4.3 Parameters

4.4 Reproducibility

The platform ran bundle 1.4.0-13 from commit 9a12835 with a clean working
tree. Run 699 used identical parameters to runs 696 and 698 on the same
hardware, which is what makes the three-run comparison in §3.1 meaningful.