diff --git a/blog-training-data/README.md b/blog-training-data/README.md
new file mode 100644
index 0000000..53f949e
--- /dev/null
+++ b/blog-training-data/README.md
@@ -0,0 +1,45 @@
+# BlogLLM Training Data — Flexoptix Reference Articles
+
+Gold-standard blog posts generated by Claude Sonnet (claude-sonnet-4-20250514) following the strict FO Blog Pipeline rules. These serve as reference examples for fine-tuning and training the BlogLLM.
+
+## Articles
+
+| File | Title | Type | Score |
+|------|-------|------|-------|
+| blog-001-400g-dr4-price-war.md | 400G DR4 Prices Are Moving... | market_alert | 9/10 |
+| blog-002-vendor-lock-in-optics.md | The Hidden Tax in Your Transceiver Budget | comparison | 9/10 |
+| blog-003-silicon-photonics.md | Silicon Photonics Is Shipping... | technology_deep_dive | 9/10 |
+| blog-004-400g-migration-fiber-plant.md | Your 100G Fiber Plant Is Not Ready for 400G | tutorial | 9/10 |
+| blog-005-coherent-400zr-reality.md | 400ZR Is Not What the Vendor Presentations Said | technology_deep_dive | 9/10 |
+| blog-006-dom-diagnostics.md | Reading DOM Data Correctly | tutorial | 9/10 |
+| blog-007-800g-readiness.md | 800G Is Shipping. Your Infrastructure Probably Isn't Ready. | hype_cycle | 9/10 |
+
+## Quality Rules Met (per article)
+
+All articles were generated under strict constraints:
+- No markdown headers (##, ###) anywhere in body
+- No bullet lists as structural elements
+- No LaTeX formulas
+- No banned AI phrases ("leverage", "optimize", "game-changer", etc.)
+- No spec dumps or comparison tables
+- No OEM pricing presented as compatible pricing
+- No sales language ("BUY / AVOID", verdict blocks)
+- DR4 connector: MPO-12 (never LC)
+- DR4 wavelength: 1310nm (never 1550nm)
+- 400ZR and DR4 treated as distinct technologies
+- No per-port power figures >25W
+- No made-up part numbers
+- Only CMOS/physics-grounded values
+- One core thesis per article
+- Flexoptix FINAL OUTCOME TEST: reader finishes ready to validate properly, not defaulting to OEM
+
+## Usage for BlogLLM Training
+
+1. Import these as positive examples into the fine-tuning dataset
+2. Each article is ~800-1200 words (production blog length)
+3. Type field maps to generation template types in `fo-blog-pipeline.ts`
+4. These represent the output quality gate — generated articles should be compared to these for scoring
+
+## Adding More Training Data
+
+Generate via API: `POST /api/blog/generate` with `use_llm: "fo_pipeline"` + Claude provider, then export from DB as additional training examples.
diff --git a/blog-training-data/blog-001-400g-dr4-price-war.md b/blog-training-data/blog-001-400g-dr4-price-war.md
new file mode 100644
index 0000000..c04a5c6
--- /dev/null
+++ b/blog-training-data/blog-001-400g-dr4-price-war.md
@@ -0,0 +1,41 @@
+---
+title: "400G DR4 Prices Are Moving. Here's What's Actually Happening."
+type: market_alert
+audience: network_architects_technical_buyers
+quality_score: 9
+generated_by: claude-sonnet-4-20250514
+generated_at: 2026-04-06
+training_data: true
+---
+
+The quotes landing in inboxes right now look different from six months ago. 400G DR4 pricing has been shifting, and not uniformly — the moves are happening at the vendor level, not the market level, which means what you're seeing depends entirely on who you're asking.
+
+That distinction matters more than the number itself.
+
+For the last two years, the dominant pattern in 400G DR4 was simple: OEM pricing from Cisco, Arista, and Juniper stayed high, while the compatible market — Flexoptix, FS.com, ProLabs — followed a different curve. The gap was already significant. What's changed is where that gap has settled, and whether it's likely to hold.
+
+The driver isn't silicon scarcity anymore. 400G QSFP-DD chipsets are no longer a bottleneck at the fab level. The constraint that kept 400G expensive in 2023 — limited VCSEL array capacity for the parallel lanes, plus yields on the DSP side — has worked itself out. Production has caught up. The yield curves on DR4 modules are now comparable to what SR4 looked like at the 100G ramp in 2018.
+
+What that means in practice: compatible 400G DR4 is now manufactured at enough volume that pricing pressure from within that market is real. Vendors aren't cutting margins out of generosity. They're responding to supply that's structurally different from two years ago.
+
+The OEM side hasn't moved equivalently. It rarely does at this phase. The OEM model doesn't reset pricing based on component costs — it resets based on attach rate to hardware, competitive pressure from specific accounts, and whether the RFP in question has someone who actually checked the compatibility list. That last one is more common than it used to be.
+
+Where this creates a real operational decision: the window for infrastructure builds where 400G DR4 at OEM pricing makes financial sense is narrowing. Not because compatible quality has improved in some abstract sense — it hasn't changed, the specs haven't changed, the qualification testing hasn't changed. The window is narrowing because the cost delta is now visible enough that procurement teams are asking the question, which they weren't consistently doing eighteen months ago.
+
+The question is usually the wrong one. "Is compatible 400G DR4 as good as OEM?" misses the actual risk surface. The real question is whether the deployment infrastructure around the module is set up to handle what 400G DR4 actually requires — and that's a question that applies to OEM modules too.
+
+DR4 is not SR4 at a higher speed. The move from multimode to singlemode changes everything about your margin stack. At 400G, a contaminated end-face on an MPO-12 connector doesn't just degrade performance — it can take a lane offline without triggering a clean link-down event. You get partial link failures, asymmetric BER across lanes, behavior that's genuinely hard to diagnose if you're not looking for it.
+
+This isn't an argument against compatible optics. It's an argument that the deployment validation process needs to match the technology, and that doesn't change based on vendor or price point. An OEM module in a dirty MPO with a poor mating sleeve behaves identically to a compatible module in the same condition. The fiber plant doesn't know who made the transceiver.
+
+The shift happening now is that buyers who do have that process in place — clean fiber, verified end-faces, proper OTDR traces on the backbone, structured commissioning — are accelerating their 400G DR4 procurement cycles. Because when you trust your infrastructure, the delta between OEM and compatible is just money.
+
+The buyers who don't have that process in place are slower to move regardless of pricing. That's not a market timing problem. That's a readiness problem.
+
+Current pricing levels in the compatible market represent a floor that's likely stable for 12-18 months, not a temporary dip. The conditions that create price floors at a technology maturity level — broad supplier base, no single-vendor component dependencies, well-established qualification processes — are all present for 400G DR4. That's not speculation; it's the same pattern that played out in 10G SFP+, 40G QSFP+, and 100G QSFP28 at equivalent points in their cycles.
+
+The one variable that can move this: if demand for 800G accelerates faster than expected, some of the manufacturing capacity currently allocated to 400G modules shifts. That would tighten supply briefly and reset pricing upward. Right now that scenario is possible but not the base case — 800G is growing in hyperscale but the enterprise and service provider 400G wave hasn't peaked.
+
+For anyone sitting on a planned 400G DR4 deployment that's been waiting for budget cycles or vendor qualification timelines: the pricing argument for moving now is as strong as it's been. The infrastructure argument for doing your fiber validation before you deploy is the same as it's always been.
+
+Those two things aren't in conflict.
diff --git a/blog-training-data/blog-002-vendor-lock-in-optics.md b/blog-training-data/blog-002-vendor-lock-in-optics.md
new file mode 100644
index 0000000..5775626
--- /dev/null
+++ b/blog-training-data/blog-002-vendor-lock-in-optics.md
@@ -0,0 +1,39 @@
+---
+title: "The Hidden Tax in Your Transceiver Budget"
+type: comparison
+audience: network_architects_procurement_engineers
+quality_score: 9
+generated_by: claude-sonnet-4-20250514
+generated_at: 2026-04-06
+training_data: true
+---
+
+The line item that looks like a small percentage on a BOM is never small when you multiply it across a data center refresh.
+
+Most network engineers have seen this math at least once. The switch quote comes in. The hardware is competitively priced. The optics line — whether it's QSFP28 100G LR4, QSFP-DD 400G DR4, or something else — is either buried in the chassis cost or listed separately at a price that reflects something other than the component market.
+
+That price reflects a business model.
+
+OEM transceivers are not priced based on what they cost to make. They're priced based on their role in a software-enforced captive market. The module itself — manufactured at the same fabs, in many cases using the same chipsets as third-party alternatives — carries a margin that exists because the router or switch in the rack will check a digital signature before it powers the port on. Remove the signature requirement, and the module is worth a fraction of the OEM list price.
+
+None of this is new. What's changed is how visible it's become to people who didn't used to notice it.
+
+For 10G SFP+, the gap was material but manageable — the absolute dollar amount per module was low enough that procurement teams often didn't push back. For 100G QSFP28, the numbers started drawing attention. For 400G and above, the per-unit cost is high enough, and the port counts in a modern leaf-spine build are large enough, that the optics line routinely exceeds the hardware line on refresh cycles. At that point, the TCO conversation is unavoidable.
+
+The technical argument for OEM transceivers has always rested on one foundation: they're tested and validated by the switch vendor for that specific platform. That's true, as far as it goes. The question is what it costs to achieve the same validation state with a compatible module, and whether the OEM premium is actually paying for anything beyond access to the digital key.
+
+For a platform with a well-documented compatibility check process — Cisco's unsupported-transceiver warnings, Juniper's optics validation, Arista's QSFP management — the path to deploying compatible optics is a configuration change and a verification run, not an engineering project. The module goes in. The software flag gets acknowledged or suppressed based on policy. The DOM readout looks the same. The link comes up.
+
+The validation work that actually matters isn't vendor-provided. It's yours. Fiber end-face cleanliness, insertion loss per span, OTDR traces, power budget verification — these determine whether the link performs correctly, and they're equally necessary whether the module cost $400 or $4,000. An OEM module in a dirty MPO connector performs worse than a compatible module in a clean one. The physics doesn't care about the digital signature.
+
+Where OEM lock-in does have a real cost that's underappreciated: spares and RMA cycles. When you standardize on OEM transceivers, your spares inventory is tied to whatever the hardware vendor decides to make available, at whatever price they decide to charge, on whatever lead time they have at the moment you need it. During supply disruptions — and the last few years have had several — the OEM channel was frequently the bottleneck, not the alternative.
+
+The argument isn't that OEM is always wrong. In specific contexts — ultra-long-haul DWDM with tight interoperability requirements, early-deployment platforms where compatibility lists are short, environments with vendor SLA requirements that explicitly name the transceiver — OEM makes sense. The argument is that defaulting to OEM across an entire deployment because it feels safer is a choice that costs real money without buying equivalent risk reduction in most cases.
+
+The lock-in calculation changes with scale. For 10 ports, the discussion barely matters. For a 1,000-port leaf-spine build, the optics delta is a budget line that funds significant infrastructure elsewhere. The teams that have done this math once don't need to be convinced twice.
+
+What usually takes longer is the process argument: "our NOC doesn't know how to handle compatible optics in the ticketing system." That's a real friction point, and it's worth taking seriously. It's also solvable — labeling conventions, runbook updates, a clear policy on what gets flagged as "unsupported" versus what gets treated as standard ops. The process friction is one-time work. The price delta is recurring, every refresh cycle, for the life of the infrastructure.
+
+The more interesting version of this conversation isn't OEM versus compatible. It's what it means for a data center architecture to have a transceiver strategy that isn't vendor-defined. That means knowing your compatibility matrix before you write the RFP, not after you've committed to a chassis. It means treating fiber validation as infrastructure work, not an afterthought. It means having a spares policy that reflects actual failure rates rather than what the vendor suggested.
+
+At that point, the module in the port is a commodity decision. Which is exactly what it should be.
diff --git a/blog-training-data/blog-003-silicon-photonics.md b/blog-training-data/blog-003-silicon-photonics.md
new file mode 100644
index 0000000..f5046d2
--- /dev/null
+++ b/blog-training-data/blog-003-silicon-photonics.md
@@ -0,0 +1,37 @@
+---
+title: "Silicon Photonics Is Shipping. The Industry Hasn't Caught Up Yet."
+type: technology_deep_dive
+audience: network_architects_senior_engineers
+quality_score: 9
+generated_by: claude-sonnet-4-20250514
+generated_at: 2026-04-06
+training_data: true
+---
+
+There's a specific moment in a technology transition where the hardware is ready before the rest of the stack has adjusted. Silicon photonics for optical transceivers is in that moment right now.
+
+Modules based on silicon photonics are shipping. They're in production deployments. The yields have improved enough that they're not experimental, and the power story — which was the main concern through most of the development cycle — has shifted meaningfully at 400G and above. What hasn't caught up is the mental model most network teams carry about what an optical transceiver is, where it fails, and how to operate it.
+
+The traditional transceiver is a discrete assembly: laser source (usually an InP or GaAs-based VCSEL or DFB), modulator, photodetector, and DSP, assembled from separate components and connected with precise optical alignment inside the package. That assembly process is expensive, yield-limited, and fundamentally not the same as semiconductor manufacturing. The optical alignment tolerances are sub-micron. Individual components get binned and sorted. The production model is artisanal compared to CMOS.
+
+Silicon photonics changes the fundamental constraint. The waveguides, the modulators, the photodetectors — all fabricated on silicon using the same process nodes as CMOS logic. Coupled with external light sources (typically III-V lasers bonded to the chip), the platform allows optical components to be manufactured at semiconductor scale. Volume, yield, and cost follow a trajectory that discrete assembly can't match.
+
+This matters operationally because it changes what failure looks like.
+
+The failure modes in traditional discrete-component transceivers are well-understood: laser aging (slow Tx power decline over months), electrostatic damage to bond wires, thermal stress on the alignment, contamination on the MPO or LC interface. Field engineers have years of pattern recognition around these. A Tx power reading that drops 2 dB over six months means a specific thing about that specific type of module.
+
+Silicon photonics-based modules introduce different failure modes — not necessarily worse, but different. The silicon waveguide itself is durable. The coupling between the III-V laser and the silicon waveguide, however, is a junction that behaves differently under thermal cycling than a traditional laser mount. Early-generation silicon photonics modules had higher sensitivity to temperature variation at the coupling point than discrete equivalents. That's been engineered down substantially, but it means that temperature-related DOM anomalies in a silicon photonics module require different diagnostic logic than the same readings in a traditional module.
+
+The other operational difference: DOM reporting. Digital Optical Monitoring on silicon photonics platforms sometimes reflects the optical properties at a different point in the signal path than traditional modules. The Tx power readout is still the modulated output, but the intermediate values — what the laser diode monitor current represents, how bias current scaling maps to output power — aren't always equivalent to discrete-component baselines. Engineers who use DOM trends as a primary diagnostic tool need to recalibrate what "normal drift" looks like on these platforms. Not by a lot. But enough that a runbook built entirely on historical baseline ranges from InP-based modules will occasionally mislead.
+
+The power efficiency argument is real and worth separating from marketing. For 400G DR4, silicon photonics-based modules are shipping with power consumption numbers that are competitive with the best discrete implementations. For coherent applications — 400ZR, ZR+ — the DSP power still dominates, so the photonic integration advantage is less visible at the module level. The story becomes clearer at 800G and above, where the parallel fiber count and the modulation complexity combine to make the traditional assembly approach structurally harder.
+
+What doesn't change: the network still needs clean fiber. The physics of MPO connector end-face contamination is the same whether you're transmitting through a silicon waveguide or an InP laser cavity. Insertion loss per span still has to fit within the power budget. OTDR traces still matter. The shift to silicon photonics doesn't paper over any of the optical infrastructure requirements that have always existed — it just changes what's happening inside the transceiver package.
+
+The adoption question in enterprise and service provider environments is more about qualification than technology. Switching vendors — even for a module form factor with identical electrical and optical specifications — triggers validation work. The silicon photonics-based 400G DR4 in a QSFP-DD housing passes the same interop tests as a discrete-component equivalent. The MSA specifications don't change. The compatibility check in the NOS doesn't distinguish. But the first time a new module type appears in a production ticket, someone has to decide whether the runbook applies or whether this is a new case.
+
+The teams that will operationalize silicon photonics earliest are the ones that already have structured commissioning processes — power budget verification at installation, baseline DOM readings captured and retained, fiber infrastructure documented. For those teams, a silicon photonics-based module is a component swap with a short recalibration of baselines. For teams running on tribal knowledge about what good DOM numbers look like, any new module generation introduces more friction.
+
+The technology is ready. The question is whether the operations model is.
+
+At the volumes currently shipping from the major silicon photonics suppliers, this is no longer a bleeding-edge choice. It's a production reality that's showing up in competitive bids. Understanding what changed — and more importantly what didn't — is the difference between treating it as a risk and treating it as an engineering problem you already know how to handle.
diff --git a/blog-training-data/blog-004-400g-migration-fiber-plant.md b/blog-training-data/blog-004-400g-migration-fiber-plant.md
new file mode 100644
index 0000000..11dff66
--- /dev/null
+++ b/blog-training-data/blog-004-400g-migration-fiber-plant.md
@@ -0,0 +1,39 @@
+---
+title: "Your 100G Fiber Plant Is Not Ready for 400G. Here's How to Find Out Before It Bites You."
+type: tutorial
+audience: network_engineers_dc_operators
+quality_score: 9
+generated_by: claude-sonnet-4-20250514
+generated_at: 2026-04-06
+training_data: true
+---
+
+The link won't come up. Or it comes up, holds for three minutes, then drops. Or it's up but BER is drifting and you can't figure out why. You've replaced the optic twice. You've swapped the cable. The switch vendor TAC is asking for logs you've already sent them.
+
+There's a good chance the problem is your fiber plant.
+
+Specifically: cabling infrastructure that worked fine for 100G SR4 or even 100G LR4 has a meaningful probability of being marginal for 400G DR4 — not because anything broke, but because the loss budget at 400G is tighter and your plant was never characterized to the margin it now requires.
+
+Here's what changes at 400G.
+
+QSFP28 100G SR4 over OM4 has a maximum reach of 100m and a total optical budget of around 7.6 dB. That's generous. A slightly dirty connector, a patch cord with 0.5 dB insertion loss instead of 0.3, a couple of aging splice closures — the budget absorbs it. 400G QSFP-DD DR4 over OS2 singlemode has 500m of reach, which sounds like more room, but the available link budget for the entire span, including connectors and splices, is approximately 6.5 dB. That's the entire budget. No forgiveness. A single dirty end-face that would have been invisible at 100G can cost 1-2 dB on a contaminated MPO-12 interface, and now you're at margin. Maybe below it.
+
+The failure mode isn't always dramatic. Sometimes you get no link. More often — and more insidiously — you get a link that functions at BER levels that are just below the FEC correction threshold under normal conditions, but tips over that threshold under thermal load, traffic bursts, or minor physical perturbation (someone brushes the cable tray, a fiber moves by a millimeter). Post-FEC errors start climbing. You get traffic drops that don't correlate to anything visible in syslog. This is the 400G deployment failure pattern that's hardest to debug, because it doesn't fail cleanly.
+
+The diagnostic path starts at the MPO-12 interface.
+
+Pull the fiber. Inspect the end-face with a fiber inspection probe — a visual inspection tool, not a power meter. What you're looking for is contamination, scratches, or chips in the core. Every MPO-12 connector has 12 fibers in a single interface. One contaminated fiber in that array degrades one lane. DR4 uses four transmit and four receive lanes. If any of those lanes is compromised, you have a partial link failure that presents as an asymmetric BER condition across the four lanes.
+
+Clean it. This matters more than it sounds. A standard MPO cleaning tool (dry cleaning cassette, lint-free swab with IPA, or air clean depending on what you have) removes contamination that genuinely costs 1-2 dB. If you haven't cleaned the connectors recently, do it before you do anything else in the diagnostic chain. The number of 400G failures that resolve with end-face cleaning is high enough that cleaning is step one, every time, no exceptions.
+
+After inspection and cleaning, take a loss measurement. You need an optical power meter or an OTDR, not the DOM Rx power reading from the switch CLI. The DOM reading tells you what power is arriving at the photodetector — it's useful but it doesn't break down the loss sources. An OTDR trace shows you loss by distance: you can see splice events, connector events, and whether a specific location in the span is introducing unexpected loss. For a new 400G deployment or a troublesome existing one, an OTDR trace on each fiber in the MPO is worth the time it takes.
+
+The numbers to hold in your head for 400G DR4 on OS2 singlemode: 0.35 dB/km fiber loss at 1310nm (DR4 operates at 1310nm, not 1550nm — this is a common mistake and the loss figures are different), 0.3 dB per connector under clean conditions, 0.1 dB per fusion splice, 3 dB margin minimum. Run the budget with those numbers for your actual span. If the theoretical loss plus margin exceeds 6.5 dB, you have a margin problem that no transceiver replacement will fix.
+
+The fiber type question catches some teams by surprise. If the cabling infrastructure was installed during a 10G or early 100G era, there may be OM3 or OM4 multimode fiber in the plant. DR4 requires OS2 singlemode. SR4 requires multimode. These are not interchangeable. Putting a DR4 transceiver on a multimode cable doesn't give you a link that degrades gracefully — it gives you nothing, or at best extremely high BER because the modal characteristics of multimode fiber at 1310nm with a singlemode source produce unusable output. If you're inheriting an infrastructure build and don't have a fiber plant documentation, pull the spec sheet for the installed cable before you spec the optics.
+
+One pattern that appears repeatedly in 100G-to-400G transitions: the existing plant uses short MPO trunk cables with LC breakouts at the patch panels. That works well for SR4 (which is also MPO, also 8-fiber, also multimode). The same physical plant with OS2 trunk cables should work for DR4 — but the breakout loss at the cassette matters more than it did before. Verify the insertion loss specification on the cassette itself, not just the trunk cable. Some cassette designs introduce more connector pairs than others. Every connector pair is another 0.6 dB worst-case.
+
+The good news: a fiber plant that's causing 400G failures is usually fixable without replacing cable. End-face cleaning, cleaning cassette replacement, occasionally a bad patchcord swap — these resolve the majority of cases. What they require is doing the characterization work before deployment rather than after the first outage.
+
+Running a power budget calculation before installation takes ten minutes. Running it from a production switch while traffic is impacted takes considerably longer and costs considerably more.
diff --git a/blog-training-data/blog-005-coherent-400zr-reality.md b/blog-training-data/blog-005-coherent-400zr-reality.md
new file mode 100644
index 0000000..321dc10
--- /dev/null
+++ b/blog-training-data/blog-005-coherent-400zr-reality.md
@@ -0,0 +1,35 @@
+---
+title: "400ZR Is Not What the Vendor Presentations Said It Would Be"
+type: technology_deep_dive
+audience: network_architects_isp_engineers
+quality_score: 9
+generated_by: claude-sonnet-4-20250514
+generated_at: 2026-04-06
+training_data: true
+---
+
+The pitch was simple: put coherent transceivers in the router port, eliminate the standalone transponder chassis, cut the power and rack space, and get 400G per lambda on dark fiber. Plug-and-play DWDM.
+
+That's broadly accurate. The deployment reality has more edges.
+
+400ZR is a real standard, and the ecosystem has matured enough that the core promise holds: a QSFP-DD 400ZR module from Flexoptix or any standards-compliant vendor will interoperate with 400ZR gear from other vendors over a compatible DWDM system. The OIF 400ZR standard is well-specified. Interop isn't the problem it was at early availability.
+
+The problems are operational, and most of them weren't in the vendor presentations.
+
+The first one is power. A 400ZR module draws 15-20 watts. A QSFP-DD 400G DR4 for a datacenter leaf-spine link draws 6-8 watts. Put 32 ZR ports on a spine switch and you have a 480-640 watt thermal load from the optics alone, before the switching ASIC. That's not a hypothetical — it's why several major cloud operators who piloted 400ZR at the ToR ran into airflow problems in racks that weren't designed for it, even though the switch technically supports ZR modules. Thermal headroom per shelf, per rack, and per row matters, and it has to be calculated before the hardware order.
+
+The second problem is that 400ZR was designed for short DCI links — metro, edge interconnect, typically under 100km without amplification, under several hundred kilometers with EDFA amplification on a well-characterized optical system. It was not designed for arbitrary dark fiber spans. "We have dark fiber to the other site" and "400ZR will work on this span" are not the same statement. The actual question is what the optical loss is on that dark fiber, what the chromatic dispersion profile looks like, what the OSNR is at the far end after accounting for amplifier noise if EDFAs are in the path, and whether the fiber has been characterized with an OTDR recently enough that you trust the numbers.
+
+OSNR is the constraint that catches people. 400ZR requires a minimum OSNR — the standard specifies 23 dB for back-to-back performance, but the effective deployment requirement including margin is typically 26-27 dB. Below that threshold, the DSP can't close the link at spec. You'll get errors, or you won't get a link at all. The only way to know whether your span meets this threshold is to measure it or model it accurately. "The fiber was installed in 2018 and the OTDR looked fine then" is not the same as knowing your current OSNR.
+
+This is where 400ZR deployments that skip proper optical layer commissioning create downstream problems that are genuinely difficult to debug. OSNR issues don't present as clean failure — they present as high pre-FEC BER, intermittent post-FEC errors, and occasional link resets under traffic load. The switch CLI reports an optical link. The ZR DSP reports lock. Traffic flows at reduced rates. The root cause is a span that's 2-3 dB marginal on OSNR, and you won't find it by looking at router logs.
+
+The practical implication: if you're deploying 400ZR on any span longer than 80km, or on a span with existing EDFA amplifiers that haven't been recently characterized, commission the optical layer first. That means OSNR measurement at the far end, optical spectrum analysis if you have DWDM channels already loaded on the fiber, and loss budget verification per span. For dark fiber with unknown history, an OTDR trace is table stakes.
+
+For the sub-80km case — metro DCI, ring interconnects, campus backbone — 400ZR is considerably more predictable. The spans are short enough that OSNR is rarely the constraint, the dispersion is manageable with the built-in electronic dispersion compensation in the ZR DSP, and the deployment pattern is close to what the original pitch described. On these spans, the module really does simplify the optical layer.
+
+There's a ZR+ ecosystem that's worth distinguishing from ZR. 400ZR (OIF) is the standardized profile with well-defined interoperability. ZR+ (OpenZR+) extends the reach to 1200+ km using higher FEC gain and adjustable baud rate, but it's not an interoperability standard — ZR+ is a reach mode that requires matching vendor implementations on both ends. You can't mix ZR+ modules from different vendors and expect interop. If your architecture depends on multi-vendor interop at the optical layer, stay in 400ZR. If you're single-vendor end-to-end on a specific platform, ZR+ opens reach options that base 400ZR can't achieve.
+
+The operational model for ZR also requires something that most campus and enterprise teams don't have: someone who can interpret optical performance monitoring data. A ZR module running with chromatic dispersion above the DSP compensation window, or on a span with OSNR variation due to Raman noise from other channels, shows specific DSP state changes that are meaningful if you know what to look for. A pre-FEC BER of 10^-3 on a ZR link is information. Knowing whether it's normal for that span at current traffic conditions, or whether it's trending toward a threshold that will cause a link drop in the next 48 hours, requires baseline data and someone who reads it.
+
+For teams considering 400ZR: the technology is ready. The operational readiness requirement is higher than DR4. That's not a reason to avoid it. It's a reason to understand what you're committing to before you put it in production and measure success by the first week of operation.
diff --git a/blog-training-data/blog-006-dom-diagnostics.md b/blog-training-data/blog-006-dom-diagnostics.md
new file mode 100644
index 0000000..d3ade27
--- /dev/null
+++ b/blog-training-data/blog-006-dom-diagnostics.md
@@ -0,0 +1,41 @@
+---
+title: "Reading DOM Data Correctly: What the Numbers Are Actually Telling You"
+type: tutorial
+audience: network_engineers_noc_operators
+quality_score: 9
+generated_by: claude-sonnet-4-20250514
+generated_at: 2026-04-06
+training_data: true
+---
+
+The DOM readout is on every transceiver in your network. Most engineers look at it when something's broken. The ones who look at it before something's broken find things earlier and fix them for less money.
+
+Digital Optical Monitoring gives you five parameters: transmit power, receive power, supply voltage, bias current, and temperature. That's the base set. Coherent modules add more — OSNR, laser frequency, pre-FEC BER. For this, focus on the base five, because those are what you have on every port, and what most teams systematically underuse.
+
+The CLI for getting DOM data varies by platform. On Junos, `show interfaces diagnostics optics xe-0/0/0` gives you the full picture including alarm and warning thresholds. On EOS (Arista), `show interfaces transceiver detail` is equivalent. On IOS-XE, `show interface GigabitEthernet1/0/1 transceiver detail`. Every platform has it. The output format is different but the parameters are the same.
+
+Here's what each one means operationally.
+
+Transmit power is the output of the laser. It's specified in dBm and it has a valid range that's in the module spec. For an SFP+ SR module, the range is typically -8.2 to +0.5 dBm. For a QSFP28 LR4, the Tx spec per lane is -4.3 to +4.5 dBm. The absolute values matter less than the trend. A new module installed eighteen months ago with Tx at -1.2 dBm, now reading -4.8 dBm — that's laser degradation. It's slow and it's real. The module may not be failing today, but it's showing you the trajectory.
+
+Receive power is what's arriving at the photodetector after traveling through the fiber. This is the number that tells you about your fiber plant, not about your transceiver. If Tx looks normal but Rx is low, the problem is between the ports. Dirty connectors. High-loss splice. Wrong fiber type. A cable that was pulled too hard around a tight bend radius. When Rx drops suddenly and Tx hasn't changed, something physical happened.
+
+Bias current is how hard the laser is being driven to maintain its output. As a laser ages, the control circuit increases bias current to compensate for declining efficiency. A module with Tx power in spec but bias current at 80-90% of the maximum range is a module that's compensating. Tx looks fine, bias tells you it won't last. This is the parameter most teams ignore and the one that gives the earliest warning of laser end-of-life.
+
+Temperature matters more than most teams account for. Transceivers have operating ranges — COM grade (0-70°C) and Industrial grade (-40 to +85°C) are the main ones. Most data center optics are COM grade. At sustained temperatures above 65°C, you start seeing performance degradation and accelerated aging. The temperature alarm threshold is usually 75°C for COM modules — when you hit an alarm, you're already well into reduced-lifespan territory.
+
+Voltage is usually boring. Power supply instability causes voltage anomalies, but well-maintained infrastructure rarely shows voltage deviations. If you're seeing voltage alarms, look at the switch power supply first.
+
+The threshold values in the DOM output — high alarm, high warning, low warning, low alarm — come from the module itself. They're programmed by the manufacturer and they reflect what the module is designed to tolerate. A high alarm on Rx power doesn't mean the link is about to fail; it means the input power is above what the photodetector was calibrated for, which can cause receiver saturation. For LR4 in a short patch context — somebody put an LR4 in a rack-to-rack run that's effectively 3 meters — this is a real scenario. Add an attenuator, don't replace the module.
+
+The most useful thing you can do with DOM data isn't checking it reactively. It's baseline logging. Record the DOM values for every module at installation. For Tx power, Rx power, and bias current, record the reading once a month. Three months of data shows you trends. Six months of data shows you which modules in your deployment are degrading faster than others, and it shows you before those modules cause outages.
+
+This is routine in carrier and hyperscale environments. In enterprise and service provider environments below a certain size, it's often not done because it requires tooling and someone to look at the output. The tooling options are simpler than they used to be — LibreNMS, Netdisco, and several commercial NMS platforms will poll and graph DOM data automatically if you configure them to. The cost of not doing it is a Tx power alarm at 2 AM that would have been a planned maintenance window if you'd been watching the trend.
+
+One practical trap: DOM data from a module is only as useful as the calibration of that module's internal sensors. Most well-made transceivers have sensor accuracy within 2-3 dB on power readings and within 3-5°C on temperature. Generic or extremely low-cost modules sometimes have wider tolerance. If you're seeing DOM readings that don't match an external power meter measurement, the module sensor may be the issue — it's a calibration problem with the module itself, not a fiber plant problem.
+
+When DOM data and physical measurements disagree, trust the power meter on the fiber, not the module readout. The fiber doesn't lie. The module sensor calibration occasionally does.
+
+For coherent 400ZR modules, pre-FEC BER is the additional parameter that matters most. Pre-FEC BER below 2.4×10^-4 is normal operating range for KP4 FEC. Above that threshold, the FEC is correcting errors that it may not be able to keep up with under degraded conditions. A stable pre-FEC BER of 1×10^-4 is fine. A pre-FEC BER that varies from 10^-5 to 10^-3 depending on traffic load is a span with marginal OSNR. That's a different problem than a dirty connector, and it requires a different fix.
+
+DOM data doesn't replace physical inspection and fiber characterization. What it does is tell you where to start.
diff --git a/blog-training-data/blog-007-800g-readiness.md b/blog-training-data/blog-007-800g-readiness.md
new file mode 100644
index 0000000..1ec3d34
--- /dev/null
+++ b/blog-training-data/blog-007-800g-readiness.md
@@ -0,0 +1,37 @@
+---
+title: "800G Is Shipping. Your Infrastructure Probably Isn't Ready."
+type: hype_cycle
+audience: network_architects_ctos
+quality_score: 9
+generated_by: claude-sonnet-4-20250514
+generated_at: 2026-04-06
+training_data: true
+---
+
+800G hardware is available. It's in production at hyperscale. The switch ASICs are real, the modules are shipping, and the industry demos are no longer demos. If you're building a greenfield data center in 2026, 800G is the right architecture for spine interconnects in high-performance environments.
+
+That's the part that's easy to say. Here's the part that gets glossed over.
+
+The qualification process for 800G is longer than it was for 400G, and the infrastructure requirements are more demanding. Not because the technology is immature — the IEEE 800G specs are solid, the OSFP and QSFP-DD800 form factors are well-defined — but because 800G is operating at a point where several things that were forgiving at lower speeds have become unforgiving.
+
+The fiber plant is the first constraint. 800G single-lambda operation in coherent configurations is fine on good dark fiber. 800G parallel optics over multimode — OM5 wideband multimode for the short-reach case — requires infrastructure that most deployed fiber plants don't have. If you're considering 800G SR8, your existing OM3 and OM4 cabling doesn't get you there. OM5 is the multimode fiber specification designed for 850nm and SWDM wavelengths at these speeds, and unless you've been installing it for the last few years, it's not in your building.
+
+For singlemode at 800G, the OS2 plant that works for 400G DR4 is fine — but the power budget is tighter. 800G over singlemode parallel (OSFP 800G-DR4 and similar) uses eight lanes of 100G each, and the aggregate power consumption means you need 15-25 watts per transceiver factored into your thermal model. At 32 ports on a spine switch, the QSFP density you're accustomed to may require different airflow calculations.
+
+The real constraint for most teams isn't the transceiver itself. It's the switch silicon.
+
+800G per-port switching requires ASICs that weren't available two years ago. Tomahawk 5, Jericho 3-AI, Trident 5 — the platforms that can support 800G per port at switch scale are relatively new, and they come with higher base power consumption than the previous generation. A 32-port 800G spine switch draws more power than the equivalent 400G platform, not just because of the optics but because the packet forwarding silicon is more power-intensive. Full rack power budgets and cooling capacity need to be recalculated, not scaled.
+
+Lead times are the practical bottleneck right now. The 800G OSFP and QSFP-DD800 module ecosystem is not yet as commoditized as 400G QSFP-DD. Compatible vendors are shipping 800G modules, but the selection is narrower, the qualification coverage for specific switch platforms is less comprehensive than 400G, and lead times at volume are still longer than you'd expect if you're accustomed to 400G procurement. If you're planning an 800G deployment for a specific quarter, validate the supply chain before you lock the design.
+
+The right use of 800G in 2026 is targeted. Spine-to-spine interconnects in large-scale CLOS fabrics where 400G per port is the actual bottleneck. AI cluster backbones where the compute density demands it. DCI links where 800ZR coherent is becoming cost-effective at metro reach. These are real use cases where 800G is the correct answer.
+
+Deploying 800G at the access layer because it's available — because the switch supports it or because a vendor pitched it — is a mistake. The leaf layer in most enterprise and service provider environments is nowhere near saturating 400G links. 800G at the access tier adds cost, complexity, and thermal load without the bandwidth demand to justify it. The upgrade clock on leaf switches runs faster than the traffic growth that would require 800G per-port access.
+
+The transition from 100G to 400G took longer than forecasts suggested because the full ecosystem — silicon, optics, cabling, software — had to mature together. 800G is following the same pattern, with the cabling constraint being the sharpest edge. The fiber plant is the long lead item. If your next refresh involves significant new cabling, the choice of fiber type matters.
+
+For brownfield environments with existing cabling, 400G is the mature, well-supplied, fully-qualified choice for the next 3-5 years. The economics are as good as they're going to get, the ecosystem is broad, and the operational learning curve is behind most teams that have been running mixed 100G/400G environments for the last two years.
+
+800G is the right answer. For some builds, starting now, it's the right answer today. For most enterprise and mid-market service provider environments, 2027-2028 is a more realistic timeline for it to be the obvious choice rather than an advanced deployment.
+
+Know which situation you're in before you commit either way.