diff --git a/docs/README.md b/docs/README.md
index 5db464c..f4a3e13 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -8,5 +8,6 @@ Project knowledge that moves and versions with the repo.
 - [transports.md](transports.md) — how to reach module-PHY diagnostics, why the NIC choice governs it, and the register-level protocols.
 - [modules.md](modules.md) — per-module diagnostics, register maps, cable-length physics, and the Marvell brick hazard.
 - [measurement.md](measurement.md) — how to measure correctly; performance results and dead ends.
+- [open-questions.md](open-questions.md) — genuinely open problems worth deeper thinking before the X520 hardware arrives.
 
 Vendor PDFs (BCM84891L transport + command handler, Marvell 88E151x datasheet) live alongside these.
diff --git a/docs/open-questions.md b/docs/open-questions.md
new file mode 100644
index 0000000..5516ee9
--- /dev/null
+++ b/docs/open-questions.md
@@ -0,0 +1,30 @@
+# Open questions
+
+The genuinely open, thinking-worthy problems — not mechanical tasks. Read the rest of `docs/` first (`state.md`, `transports.md`, `modules.md`, `measurement.md`); this assumes that context.
+
+Short framing: cabletest stresses 10GBASE-T copper cables at full-duplex 10G and attributes loss/errors to the cable. We're swapping the E810 out for an Intel X520-DA2 (82599, `ixgbe`) so the host can bit-bang the SFP module I2C bus (the E810/i40e firmware blocked or couldn't frame it). Diagnostics clients and a raw-i2c kernel patch are prebuilt but untested. Test modules: FS SFP-10G-T-100 (Broadcom BCM84891L, fully documented) and replacement Wiiteks (Marvell CUX3610, brick-prone). All modules are copper lying as fiber.
+
+## 1. Raw-L2 RX steering on 82599 (gates whether cabletest runs on the X520 at all)
+The tool steers raw ethertype 0x88b5 to per-queue NAPI contexts via Flow Director; ixgbe rejects ETHER_FLOW. But `FDIRCTRL_FLEX_SHIFT` is already set to 0x6 = byte offset 12 = the ethertype field, so the hardware samples it. Open: will a non-IP frame classify into an fdir flow_type the rule engine matches, and does pairing `flex_bytes` with a permissive base flow type need a driver change? Alternative: MAC→VMDq-pool steering (distinct dest MACs → queues, fully raw). Think through both against the 82599 datasheet before committing; UDP/bare-IP encap is the last resort we want to avoid. See the steering section of state.md.
+
+## 2. Can 82599 sustain zero-baseline-loss 2×10G full duplex, and what happens to timestamping?
+It's older/Gen2 silicon. The whole tool depends on *exactly zero* host-side loss (see measurement.md). Separately: the cable-length-via-timestamp idea assumed two ports on one NIC sharing a PHC with usable TX+RX hardware timestamps — 82599's PTP is limited (largely PTP-only, sparse). Re-examine whether the timestamp path-delay length measurement is even viable on this NIC, or whether it dies with the E810.
+
+## 3. Consolidate the cable-length strategy — currently three partial paths
+- **BCM ECD/DSP register** — real, but the ECD chapter is missing from FS's docs. What's the fallback if FS doesn't deliver: mine the Broadcom SDK/patents, or lean on the QCA/Marvell CDT analogy?
+- **Marvell VCT/DSP** — undocumented, and gated behind a firmware trap that permanently bricks the module on certain reads (`*.0x??64`, high window; see modules.md). Is there *any* safe route, or is it strictly vendor-docs-or-sacrificial-unit?
+- **Timestamp path-delay** — see item 2.
+
+Decide which is the product path vs. nice-to-have.
+
+## 4. Two-master I2C safety + correctness of the untested clients
+The `ixgbe` driver polls the SFP EEPROM (DOM/qualification) on its own; our `sff_i2c` transactions share the bus. The swfw semaphore *should* serialize us, but verify the reasoning. Also scrutinize framing assumptions we couldn't test:
+- the BCM SMI read's >1 ms inter-transaction delay adequacy;
+- the EEPROM-read assumption that the word-address pointer persists across STOP;
+- whether RollBall's mailbox read (set-pointer-then-read as two separate transactions) matches what the module expects vs. the kernel `mdio-i2c` combined-transfer form.
+
+## 5. Pre-FEC error visibility — design the experiment
+No module exposes a pre-FEC counter in reachable space; the Aquantia `3.e820` clear-on-read counter is the best candidate but is unclassified (pre- vs post-FEC) because it won't move on a healthy short link. cabletest's own noise pair can create a marginal channel — design the correlation (module counter vs. host CRC/loss under graded noise) that would classify it and turn it into a real leading indicator.
+
+## 6. Architecture sanity check
+Is putting *both* test traffic and module diagnostics on the X520 right, given its steering/timestamp weaknesses, or is there a cleaner split (traffic on a NIC that steers well, diagnostics on the X520)? The tension: the modules under test are where the traffic physically flows, so splitting is awkward — but worth pressure-testing the assumption.