ADR 0036 — HyperBridge.Art — Inline Bypass-Capable NIC Tap

• Status: Accepted (2026-05-24) — full HB wave (HB-1 + HB-2 + HB-3 + HB-4 + HB-5) materialized; T1 Silicom HW-FTW, T2 Mellanox SW-FTW, T3 linuxbridge lab tier, plus dashboard hash-chain viewer and Family D provisional draft all shipped to main in PRs #705 / #1025 / #1026 / #1027 / this PR.
• Original proposal date: 2026-05-13
• Acceptance date: 2026-05-24
• Deciders: TLSStress.Art project
• Targets: v4.x (delivered)
• Patent claim families:
• NEW Family D — Inline DUT Validation Tap via Bypass-Capable NIC with Integrated Effectiveness Measurement — provisional draft at docs/patents/provisional-hyperbridge-inline-tap.md; FTO scan budget 6–8h; filing target 2026-Q4 (sequenced after Families B + C)
• Extends Family A (SPAN tiered ingest + cross-correlator — ADR 0024 + 0034) by adding a 6th tier (T6 — inline bypass NIC) below the existing T1–T5 SPAN-port tiers
• Builds on: ADR 0024 (SPAN.Art line-rate capture), ADR 0034 (3-way fusion correlator), ADR 0035 (6-pillar Inspection Effectiveness Validation)

Context

The SPAN.Art module (ADR 0024 + ADR 0034 + ADR 0035) is materially complete: line-rate capture, cross-correlator, 8-verdict matrix, decryption posture, fast-path detection, IES scoring. All of it depends on the operator providing packet-capture input to SPAN-1 (pkg/span-collector/) — typically via a switch SPAN port mirroring the DUT's traffic.

This dependency creates deployment blockers in a large fraction of customer environments:

1. Switch lacks SPAN capability: SOHO / MSP-managed customers often run prosumer or fan-out switches without configurable port mirroring.
2. SPAN ports exhausted: enterprise customers with DC-grade switches frequently have all SPAN session slots already consumed by SIEM / DLP / vendor monitoring agents.
3. Switch CPU/ASIC budget saturated: enabling SPAN consumes significant ASIC bandwidth on Cisco Nexus / Arista 7050X / Juniper QFX. Customers operating near platform limits cannot add a SPAN session without performance impact on production traffic.
4. Compliance restrictions on switch configuration: regulated environments (financial, government, healthcare) prohibit modification of production switch configuration without a change-control window measured in months. SPAN sessions count.
5. No DC-grade switch in the path at all: SMB customers running unmanaged switches have zero SPAN options.

Today's only alternatives are: - (a) Commercial network packet brokers (Gigamon GigaVUE, Ixia Vision Edge, cPacket cBroker) — $30k-100k+; deployed by enterprise customers, prohibitively expensive for SMB / mid- market. - (b) Inline TAP-only appliances (Garland INT1G/INT10G, Profitap ProfiShark) — passive tap; does not generate copies of packets for analysis, only physical T-junction.

There is no production-grade open-source / commodity inline tap with the operator-side software flexibility we need. A significant TAM segment is unreachable until we close this gap.

Decision

Introduce MÓDULO HyperBridge.Art as a 6th tier (T6) of the SPAN.Art ingest hierarchy. HyperBridge.Art is NOT a replacement for SPAN.Art; it is a new ingest path that, when deployed, feeds the existing SPAN-1 (pkg/span-collector/) with PacketBatch JSON that downstream modules consume identically to a switch-SPAN-fed deployment.

The module deploys on a commodity server with a dual-port (or higher) Network Interface Card. The NIC operates as a transparent Layer 2 bridge between an upstream device and the DUT, with hardware or software fail-to-wire bypass: if the bridge service fails, the NIC's relay (or kernel fallback) maintains physical link continuity so the DUT's production traffic is not interrupted.

Three hardware tiers serve different deployment scales:

Tier	Hardware	Failover	Throughput	Cost target
T1 — production HW-FTW	Silicom PE2G6BPI / Napatech / Endace	hardware relay, sub-ms	up to 100 Gbps	$1k-15k/NIC
T2 — software FTW + commodity NIC	Mellanox ConnectX / Intel / Broadcom + watchdog	software, ~100ms-1s	up to 100 Gbps	$400-2k/NIC
T3 — software bridge, no FTW	Any dual-port NIC	none	up to 10 Gbps	$50-500/NIC

T1 is production-grade for critical paths. T2 is acceptable for high-availability deployments where ~1s of outage during a service crash is tolerable. T3 is lab / test-bench only.

Architectural overview

        Upstream switch / router                           DUT (NGFW/IDS/IPS)
              │                                                  ▲
              │                                                  │
              ▼                                                  │
   ┌───────────────────────────────────────────────────────────────┐
   │                  HyperBridge.Art server                        │
   │                                                                │
   │   ┌──────────────┐                       ┌──────────────┐     │
   │   │  NIC port A  │ ←─── HW bypass relay ──→ │  NIC port B  │     │
   │   │ (upstream)   │      (engaged when     │ (to DUT)     │     │
   │   │              │       service crashes; │              │     │
   │   │              │       transparent      │              │     │
   │   │              │       wire-rate path)  │              │     │
   │   └──────┬───────┘                       └──────▲───────┘     │
   │          │                                       │              │
   │          ↓ packets in            packets out ↑    │              │
   │   ┌──────────────────────────────────────────────────────┐     │
   │   │  L2 forwarder (DPDK PMD / AF_XDP / Linux bridge)      │     │
   │   │  ├ Layer 2 transparent forwarding A↔B at line-rate   │     │
   │   │  ├ Preserves VLAN tags, MTU, MAC table, BPDUs        │     │
   │   │  └ XDP_COPY duplicates packets ───┐                  │     │
   │   └────────────────────────────────────│──────────────────┘     │
   │                                        ↓                         │
   │                          ┌──────────────────────────┐            │
   │                          │ packet copy → ring buffer│            │
   │                          └────────────┬─────────────┘            │
   │                                       ↓                          │
   │   ┌──────────────────────────────────────────────────────┐     │
   │   │  Sink emit → SPAN-1 (pkg/span-collector/) endpoint   │     │
   │   │  ├ POST /batch (PacketBatch JSON)                    │     │
   │   │  └ Same wire-format SPAN-1 already consumes from     │     │
   │   │    libpcap T1 ingress on a SPAN-port host            │     │
   │   └──────────────────────────────────────────────────────┘     │
   │                                                                │
   │   ┌──────────────────────────────────────────────────────┐     │
   │   │  Watchdog daemon (systemd + sidecar)                  │     │
   │   │  ├ Heartbeats forwarder every 100ms                  │     │
   │   │  ├ On consecutive misses: invokes vendor bypass API  │     │
   │   │  │  (Silicom IPMI / Napatech NTAPI / ethtool ioctl)  │     │
   │   │  ├ On recovery: re-engages forwarder + clears bypass │     │
   │   │  └ Bypass-event audit log                            │     │
   │   └──────────────────────────────────────────────────────┘     │
   └────────────────────────────────────────────────────────────────┘

Critical design decision: reuse SPAN-1 as the ingestion endpoint

HyperBridge.Art does NOT replace any module in the SPAN.Art pipeline. The forwarder copies packets into the existing PacketBatch JSON format that SPAN-1 (pkg/span-collector/) already consumes from libpcap. From SPAN-1's perspective, packets from a HyperBridge.Art tap are indistinguishable from packets captured via switch-SPAN libpcap — same schema, same downstream behavior.

This means:

• Zero downstream changes. SPAN-2/3/4/5, pkg/decryption-posture/, pkg/canary-injector/, pkg/fast-path-passive/, and pkg/dut-annex/ all work unchanged.
• Operator can mix-and-match: some flows captured via switch-SPAN, others via HyperBridge.Art tap. Single SPAN-1 consumes both.
• All 6 pillars of ADR 0035 become available to customers without switch SPAN. This is the commercial unlock.

Hardware abstraction layer (HAL)

The forwarder must work with multiple NIC vendors. The HAL defines a Go interface that vendor-specific drivers implement:

package hyperbridge

// Driver abstracts vendor-specific NIC capabilities behind a
// uniform interface. Concrete implementations live in
// `internal/drivers/<vendor>/`.
type Driver interface {
    // Identify returns vendor + model + capabilities for
    // /metrics + Dashboard display.
    Identify() (DriverInfo, error)

    // OpenBridge configures port A and port B to operate as a
    // transparent L2 bridge with packet copy enabled. Must be
    // idempotent.
    OpenBridge(cfg BridgeConfig) error

    // CloseBridge releases the bridge configuration. Optional:
    // implementation may engage HW bypass mode automatically
    // on close.
    CloseBridge() error

    // ReceivePackets returns the next batch of packets from the
    // configured tap. Blocks up to BatchTimeout.
    ReceivePackets() ([]Packet, error)

    // EnableBypass forces the NIC into hardware bypass mode
    // (relay engaged; bridge inactive; traffic flows at wire
    // rate through the bypass path). Returns immediately;
    // bypass status is reported via Status().
    EnableBypass() error

    // DisableBypass returns the NIC to bridge mode. Forwarder
    // takes over again. May briefly interrupt traffic during
    // re-engagement (vendor-specific; documented per driver).
    DisableBypass() error

    // Status reports current driver + NIC state. Polled by the
    // watchdog and surfaced on the Dashboard.
    Status() (Status, error)

    // SupportsFailToWire reports whether this NIC has HW relay
    // capability. False → forwarder uses software fallback.
    SupportsFailToWire() bool
}

type DriverInfo struct {
    Vendor      string // "silicom" / "napatech" / "mellanox" / "intel"
    Model       string
    PortCount   int
    FormFactor  string // "utp" / "sfp+" / "qsfp+" / "qsfp28"
    MaxThroughputGbps int
    HWFailToWire bool
}

type BridgeConfig struct {
    PortA, PortB int // hardware port indices
    PreserveVLAN bool
    MTU          int
    PromiscMode  bool
    PacketCopy   bool // duplicate packets to userspace (true for tap usage)
}

type Status struct {
    BridgeActive   bool
    BypassEngaged  bool
    PortALinkUp    bool
    PortBLinkUp    bool
    PacketsRxA     uint64
    PacketsRxB     uint64
    PacketsCopied  uint64
    DroppedCopies  uint64 // packets seen on wire but not delivered to userspace
}

Concrete drivers planned:

Driver	NIC examples	Tier	HW FTW	Notes
internal/drivers/silicom	PE2G6BPI / PE3G6BPI / PE4-bypass	T1	✅	Primary production target. PCIe register-based bypass.
internal/drivers/napatech	NT40A01 / NT100A01 SmartNIC	T1	✅	NTAPI; expensive ($5-15k); lossless capture.
internal/drivers/endace	DAG 10X4-S / DAG 100X	T1	✅	Premium ($10-25k); forensic-grade.
internal/drivers/mellanox	ConnectX-5 / 6 / 6 Dx	T2	❌ (SW)	Common in customer environments. Software watchdog only.
internal/drivers/bluefield	NVIDIA BlueField-2 / BlueField-3	T2+	⚠️ (FW-custom)	DPU; can host the forwarder ON the NIC; requires NVIDIA NDA for firmware mods.
internal/drivers/intel	Niantic / Fortville / Columbiaville	T2	❌ (SW)	Some models have limited bypass via firmware (X550).
internal/drivers/linuxbridge	Any NIC	T3	❌	Pure Linux bridge / OVS — lab only.

Three detailed embodiments

Embodiment 1 — Production HW-FTW (T1, Silicom-priority)

System comprises: - Silicom PE2G6BPI 6-port bypass NIC (4× SFP+ data + 2× RJ45 mgmt) installed in a 1U commodity server (Dell R650 / Supermicro X11SDV / similar). - Linux distro with kernel ≥ 5.15 (for AF_XDP support). - DPDK 23.11+ with Silicom PMD enabled, OR AF_XDP-based forwarder for kernel-integrated deployment. - A hyperbridge-forwarder Go binary that: - Initializes the Silicom PMD via DPDK rte_eth_dev_configure. - Configures ports A and B as a transparent L2 bridge with promiscuous mode and packet-copy enabled. - Runs the main forwarding loop on a dedicated CPU core (DPDK poll-mode driver pattern). - On every packet, calls rte_pktmbuf_clone() to duplicate into a separate ring buffer destined for the SPAN-1 sink. - A hyperbridge-watchdog Go binary that: - Heartbeats hyperbridge-forwarder via a Unix domain socket every 100ms. - On 3 consecutive missed heartbeats (300ms), invokes the Silicom bypass API: bp_set_bypass_state(NIC_HANDLE, BP_STATE_BYPASS) (or equivalent ioctl on the bypass control device /dev/silicom_bp). - Bypass activation latency: 5-50ms (per Silicom datasheet); typical TCP retransmit recovery is invisible to upper layers. - On forwarder recovery + healthy heartbeats for 10s, invokes bp_set_bypass_state(BP_STATE_NORMAL) and re-engages. - All bypass-state transitions logged via the existing Sealed Audit Log (ADR 0029) for ZTP-prem compliance.

Performance envelope: - Sustained line-rate at 10 Gbps per port pair on a 4-core Xeon Silver. - Per-packet added latency: 2-5 µs (DPDK PMD). - Jitter: < 1 µs P99 under controlled load. - Burst tolerance: 16 MB ring buffer per direction.

Embodiment 2 — Software FTW with commodity NIC (T2, Mellanox)

System comprises Embodiment 1's software architecture, but with: - Mellanox ConnectX-5 / 6 NIC (no HW bypass relay). - AF_XDP-based forwarder (avoids DPDK dependency). - Watchdog uses a software bypass strategy when the forwarder fails: 1. On forwarder process death detected, the watchdog removes the AF_XDP socket binding. 2. It then activates a Linux bridge between port A and port B using the standard kernel bridge module (brctl addif br0 eth0; brctl addif br0 eth1). 3. The kernel bridge forwards traffic at ~5 Gbps with no SPAN copy (best-effort survival mode). 4. When the forwarder recovers, the watchdog removes the bridge interfaces from br0 and the forwarder reclaims them via AF_XDP. - Failover time: 200ms-1s (kernel bridge module insertion + link state transitions). - Suitable for: enterprise where ~1s outage during a service crash is acceptable. - Critical limitation: if the SERVER itself loses power or hangs, the kernel bridge does not protect the link. T2 is NOT a substitute for HW relay in critical-path deployments. Document prominently.

Embodiment 3 — Software bridge, no FTW (T3, lab only)

System comprises: - Any dual-port NIC (no vendor-specific dependency). - Standard Linux bridge (brctl) or Open vSwitch (ovs-vsctl) configured permanently at boot. - Packet copy via libpcap on the bridge interface OR tc-mirred redirection to a dummy0 interface. - No watchdog; no bypass mechanism. - If forwarder or server fails, the link goes down. Customer TCP connections reset. - Lab / test-bench only. Production deployment is forbidden by clear warning in the operator runbook.

Performance envelope per tier

Metric	T1 (HW-FTW)	T2 (SW-FTW)	T3 (no FTW)
Sustained throughput	up to 100 Gbps	up to 40 Gbps	up to 10 Gbps
Per-packet added latency (P50)	2-5 µs	10-50 µs	50-200 µs
Per-packet added latency (P99)	< 10 µs	< 100 µs	< 1 ms
Failover latency on service crash	5-50 ms (HW relay)	200-1000 ms (kernel bridge)	none — link drops
Failover latency on server hard fault	< 50 ms (relay engages on power-loss)	link drops until reboot	link drops until reboot
Packet drop under sustained 100% load	< 0.01 %	< 0.5 %	< 5 %

Integration with SPAN.Art ecosystem

Where HyperBridge.Art slots into ADR 0024's 5-tier hierarchy

ADR 0024 documents a 5-tier ingest hierarchy:

Tier	Backend	Capable bandwidth	Source
T1	libpcap	up to 1 Gbps	SPAN port + dev tap
T2	AF_XDP	1-10 Gbps	SPAN port + Linux capture
T3	DPDK	10-40 Gbps	SPAN port + DPDK capture
T4	SmartNIC offload	40-100 Gbps	SPAN port + SmartNIC
T5	external SPAN port	100+ Gbps	physical broker collector

HyperBridge.Art adds a T6 (inline tap) tier that operates at T1-T5-equivalent bandwidth depending on the underlying NIC, but does NOT depend on a switch SPAN port. T6 is orthogonal to T1-T5: some flows can be tapped via T6 (HyperBridge.Art) while others are tapped via T1-T5 (switch SPAN).

ADR 0024 will be updated to reflect this once ADR 0036 is accepted.

Wire-format compatibility

The forwarder emits PacketBatch JSON in the exact format defined by pkg/span-collector/internal/types.PacketBatch:

type PacketBatch struct {
    Batch     []CapturedPacket `json:"batch"`
    FlushedAt time.Time        `json:"flushed_at"`
    BatchID   uint64           `json:"batch_id"`
}

type CapturedPacket struct {
    CapturedAt       time.Time `json:"captured_at"`
    IngressInterface string    `json:"ingress_interface,omitempty"`
    Tuple            FiveTuple `json:"tuple"`
    PayloadLength    int       `json:"payload_length"`
    PayloadFragment  []byte    `json:"payload_fragment"`
    Direction        string    `json:"direction,omitempty"`
    SequenceID       uint64    `json:"sequence_id"`
}

HyperBridge.Art adds two optional fields specific to inline tap context:

type CapturedPacket struct {
    // ... existing fields ...

    // SPAN-10a / SPAN.Art compatibility — already in v3.9
    // ...

    // HyperBridge-specific additions (omitempty for back-compat):
    TapSource     string `json:"tap_source,omitempty"`     // "ftw_inline" / "span_port" / "tee"
    PortDirection string `json:"port_direction,omitempty"` // "A_to_B" / "B_to_A"
}

SPAN-1 ignores unknown fields (Go encoding/json default), so this is fully backward-compatible with v3.9 deployments.

Hardware vendor matrix (commercial reference)

For customer-facing collateral. Updated as vendors are validated:

Vendor / Model	Tier	Throughput	HW FTW	Form factor	Notes
Silicom PE2G6BPI	T1	6× 1 Gbps	✅	RJ45	Entry-level production; ~$1k
Silicom PE3G6BPI	T1	6× 1 Gbps	✅	RJ45	PCIe 3.0; volume target
Silicom PE310G2BPI71	T1	2× 10 Gbps	✅	SFP+	10G edge / mid-market
Silicom PE325G2BPI	T1	2× 25 Gbps	✅	SFP28	DC mid-rate
Napatech NT40A01	T1	4× 10 Gbps	✅	SFP+	Premium; ~$5k
Napatech NT100A01	T1	1× 100 Gbps	✅	QSFP28	Premium; ~$15k
Endace DAG 10X4-S	T1	4× 10 Gbps	✅	SFP+	Forensic-grade; ~$10k
Mellanox ConnectX-5	T2	2× 25 Gbps	❌ (SW)	SFP28	Common in DC; ~$500
Mellanox ConnectX-6 Dx	T2	2× 100 Gbps	❌ (SW)	QSFP28	DC; ~$1.5k
NVIDIA BlueField-2	T2+	2× 100 Gbps	⚠️ (FW)	QSFP28	DPU; firmware-custom FTW possible
Intel Niantic X540	T2	2× 10 Gbps	⚠️ (limited HW FTW)	RJ45	Some models; older platform
Intel Fortville XL710	T2	2× 40 Gbps	❌ (SW)	QSFP+	Common; ~$800

Failure modes + bypass behavior

The watchdog's bypass decision must be conservative: false positives (engaging bypass when forwarder is healthy) lose the SPAN copy; false negatives (failing to engage when forwarder crashes) drop production traffic. Design choices:

1. Heartbeat interval: 100ms (10 Hz). Lower would catch faster failures but waste CPU; higher misses brief stalls.
2. Consecutive miss threshold: 3 (300ms grace). Single-miss triggers from CPU scheduling jitter under high load are common; 3 misses indicate a real fault.
3. Recovery hysteresis: 10s of healthy heartbeats required before bypass disengages. Prevents flapping under intermittent issues (e.g., transient backpressure recovery).
4. Bypass-on-shutdown: SIGTERM to the forwarder triggers EnableBypass() BEFORE process exit. Ensures clean upgrades don't drop traffic.
5. Bypass audit log: every bypass state transition emits a structured event to the ZTP-prem sealed audit log (ADR 0029) for compliance review: {timestamp, vendor_driver, trigger_reason, prior_state, new_state, recovery_time_ms}.
6. External monitoring webhook: optional Slack / PagerDuty webhook on bypass activation. Operator's monitoring stack can alert on extended bypass durations (>5 minutes = forwarder service genuinely broken).

Patent angle — potential Family D

Network bypass NICs are well-established prior art (Silicom 2003+, Gigamon GigaTAP, cPacket cBroker, etc.). Inline TAPs likewise. What is novel in HyperBridge.Art is the combination with the ADR 0035 6-pillar Inspection Effectiveness Validation framework:

Proposed independent claim

A network appliance for measuring the effectiveness of a TLS-inspecting network middlebox without dependency on switch port mirroring, the appliance comprising:

(a) a network interface card configured as a transparent Layer 2 bridge between an upstream device and the middlebox;

(b) a hardware or software fail-to-wire bypass mechanism that maintains physical link continuity when the bridge service fails;

(c) a packet-copy plane that duplicates traffic traversing the bridge into a structured PacketBatch data stream;

(d) a coupling to a multi-pillar inspection effectiveness measurement framework comprising: - a wire-side cross-correlator that pairs the observed packet stream against device-under-test syslog and NetFlow records to identify per-flow disagreements; - a decryption coverage measurement engine operating on observed certificate-issuer evidence; - a fast-path detection engine operating on per-packet latency bimodality; and - a composite effectiveness score derived from the foregoing measurements;

such that the same physical hardware tap delivers both line-rate transparent forwarding and complete effectiveness measurement of the middlebox in production traffic, without requiring switch SPAN configuration.

Dependent claims (planned)

1. Hardware fail-to-wire via PCIe register write or relay.
2. Software fail-to-wire via Linux kernel bridge fallback with recovery hysteresis.
3. Bypass-state audit log with cryptographic chain to a sealed audit log.
4. Integration of bypass-state events into the operator inspection-effectiveness dashboard.

FTO scan plan

Density of prior art in network packet brokers + bypass NICs is HIGH. Prior art to investigate before drafting:

• Silicom bypass NIC patents (US 7,142,539; US 7,433,956)
• Gigamon GigaTAP patents (multiple)
• cPacket Networks (US 8,953,439)
• Apcon (US 8,289,985)
• Ixia / Keysight Network Visibility line
• Academic literature on inline middlebox monitoring
• Recent NVIDIA BlueField DPU patents

The novelty lever is the combination with the 6-pillar framework, not the bypass NIC itself. FTO scan budget: 6-8 hours of legal/IP work (heavier than ADR 0035's families because the bypass-NIC space is more crowded).

Filing target: 2026-Q4 (after Family B + C provisionals already in flight from ADR 0035). Sequencing the filings spreads filing fees + counsel bandwidth.

Open questions (parking lot — settle before HB-1 begins)

1. Initial hardware scope: Silicom-priority V1 (production-grade, higher cost) vs Mellanox-priority V1 (cheaper, customer- commonality, but software-FTW only)? Recommendation: dual driver V1 — Silicom for production demos, Mellanox for lab + customer-trial.
2. Throughput target V1: 1 Gbps (lab) / 10 Gbps (enterprise edge) / 40 Gbps (DC) / 100 Gbps (core)? Recommendation: 10 Gbps (SFP+ sweet spot; covers 80% of enterprise middlebox deployments).
3. Form factor V1: UTP / SFP+ / QSFP+ / QSFP28? Recommendation: SFP+ (matches the 10 Gbps target).
4. Deployment model: standalone 1U appliance (we ship a server) / sidecar to customer's existing server / K8s DaemonSet on customer node? Recommendation: standalone 1U appliance for V1 to control hardware variance; sidecar / DaemonSet in V2+.
5. Bypass behavior on partial failure: forwarder healthy but packet-copy buffer overflowing → continue forwarding (drop the SPAN copies) or engage bypass? Recommendation: continue forwarding (production traffic priority); emit drop-counter metric for operator awareness.
6. Packet copy compliance: customer's DPI policy may forbid payload capture beyond N bytes. Make the payload-length cap configurable in PacketCopy.MaxBytes field (default 256, matching SPAN-1 PayloadFragmentBytes).
7. Pricing / licensing: per-NIC license / per-throughput- tier / per-tap-session? Recommendation: per-NIC license key with throughput tier identified at install time.
8. Hot-plug / hot-swap: can the operator add/remove bypass NICs without rebooting? Recommendation: Yes via PCIe hot-plug if hardware supports; document server-platform constraints.
9. VLAN / Q-in-Q transparency: must preserve all dot1q/dot1ad tags. Confirm via lab test with realistic trunk configurations.
10. PoE pass-through: if upstream cable carries PoE to a PoE-powered DUT, the HyperBridge server must either be in the PoE path (with power injector workaround) or use a fiber form factor (SFP+/QSFP+) that's electrically isolated. Document for UTP deployments.

Rollout plan — HB wave (5 PRs, ~3-4 weeks)

PR	Scope	Effort
HB-0 (this ADR)	Design + HAL spec + vendor matrix + claim draft outline	1 day (this PR)
HB-1	pkg/hyperbridge-art/ MVP — Linux bridge backend (T3) + AF_XDP packet copy + systemd watchdog. Target: 1 Gbps, no HW FTW. Goal: end-to-end demo against a synthetic test bench.	3-5 days
HB-2	Silicom HAL driver + DPDK PMD integration. Target: 10-40 Gbps, HW FTW. Goal: production-ready Tier 1 hardware support.	1 week
HB-3	Mellanox ConnectX driver + AF_XDP forwarder + software-FTW watchdog (kernel bridge fallback). Goal: Tier 2 commodity-hardware support.	4-5 days
HB-4	Dashboard widget — HyperBridge status (active/bypassed/degraded), bypass-activation history, throughput gauge, vendor diagnostic info. K8s DaemonSet manifest.	3-4 days
HB-5	Provisional patent draft (Family D), FTO scan summary, sample renderings into the Annex showing HyperBridge tap source, customer-trial collateral (one-page datasheet)	2-3 days

Total: ~3-4 weeks. Comparable to SPAN.Art at scale.

Recommended sequence: HB-0 → HB-1 (lab demo) → HB-3 (Mellanox commodity) → HB-4 (Dashboard) → HB-2 (Silicom production) → HB-5 (patent). Rationale: get a working demo fast (Mellanox is what we have in lab), prove the architecture, THEN invest in Silicom production hardware.

Consequences

Pros

• Unlocks an unreachable TAM segment — customers without SPAN access on their switches can now deploy the entire ADR 0035 6-pillar framework
• Reuses 100% of the SPAN.Art downstream pipeline — span-collector, span-tls-extractor, span-correlator, decryption-posture, canary-injector, fast-path-passive, dut-annex all work unchanged
• 3-tier hardware strategy matches customer budget reality: Silicom for production, Mellanox for trials, any dual-NIC for labs
• Potential 4th patent claim family with novel combination (inline tap + ADR 0035 effectiveness framework)
• Customer-trial enabler: a 1U HyperBridge.Art appliance is cheap enough to leave at customer site for a 30-day proof-of- value (vs $30k+ Gigamon)
• Operator-friendly fail-to-wire preserves production traffic during service upgrades / crashes / hardware faults

Cons / risks

• Production HW requires Silicom-class NICs ($1k-15k vs $400 commodity Mellanox). Document the tier matrix prominently so customers don't deploy T2 in critical paths.
• Per-packet added latency is non-zero even with DPDK (~2-5µs). For ultra-low-latency workloads (HFT, RDMA, voice/video) this may be unacceptable. Document fitness envelope.
• PoE pass-through complications for UTP deployments. Recommend SFP+/QSFP+ for production.
• Inline failure mode: if the HyperBridge.Art server itself loses power AND the NIC doesn't have HW relay, production traffic drops. T1 (HW-FTW NICs) protects against this; T2/T3 do not.
• Patent FTO is denser than ADR 0035's families. Bypass NICs are well-trodden. Novelty leverages on the combination, not the bypass primitive.
• Vendor SDK licensing: Silicom and Napatech SDKs have redistribution restrictions. Driver code must be carefully segregated; license terms must be reviewed by counsel before shipping public Docker images.

Compatibility

• v3.9 deployments: HyperBridge.Art is purely additive. Existing SPAN-port-fed deployments continue to work; HyperBridge.Art is an alternative ingest path, not a replacement.
• Mixed deployments: an operator can run BOTH a switch-SPAN-fed SPAN-1 instance AND a HyperBridge.Art tap into the same downstream pipeline. SPAN-1's batch handler accepts packets from any source — they're just PacketBatch JSON.
• Hardware lifecycle: NIC firmware upgrades, driver upgrades, and bypass-relay calibration are out of scope for the software stack but must be documented in operator runbooks.

References

• ADR 0024 — SPAN.Art line-rate capture (parent ADR; 5-tier ingest hierarchy that this ADR extends with T6)
• ADR 0034 — 3-way fusion correlator
• ADR 0035 — DUT Inspection Effectiveness Validation (6-pillar framework that HyperBridge.Art feeds into)
• ADR 0029 — Sealed Audit Log (used for bypass-state events)
• docs/patents/provisional-fast-path-detection.md — Family C draft (precedent for HyperBridge.Art's Family D)
• docs/patents/provisional-decryption-posture.md — Family B draft
• Silicom Bypass NIC product brief — https://www.silicom-usa.com/
• Napatech SmartNIC documentation
• Endace DAG card documentation
• NVIDIA BlueField DPU programming guide
• DPDK Programmer's Guide (https://doc.dpdk.org)
• AF_XDP Linux documentation (kernel ≥ 5.4)
• IEEE 802.1Q VLAN tagging (preservation requirement)
• RFC 2544 — benchmarking methodology (for V1 acceptance tests)
• Memory companion: discuss_fail_to_wire_2026_05_13.md