Provisional Patent Application — Draft¶

Title: Multi-Source URL/Traffic Discovery with Privacy-Preserving Aggregation, Two-Phase Validation Architecture, and Defense-in-Depth In-Bench Resource Isolation for Network Security Device Testing

Inventor: André Luiz Gallon Date: 2026-05-24 Application family: DOM/OOBI/GATEWAY/RELAY/PURE — claim #13 of 13 total claims Status: PROVISIONAL DRAFT — not yet filed Related implementations: - pkg/pure-art/internal/{urlcatalog,discoveryhub,server}/ (PURE-1 scaffold) - pkg/pure-art/internal/ingestion/{syslog,vendorapi,pcap,har,curated}/ (PURE-2 5 source adapters) - pkg/pure-art/internal/{pvi,wafsig,tagger,categorizer,redirect}/ (PURE-3 PVI cascade) - pkg/pure-art/internal/{pvp,piepa,audit}/ (PURE-4 PVP + PIE-PA 3-layer) - pkg/pure-art/internal/{testplan,curatedrefresh,hooks}/ (PURE-5 Test Plan) - dashboard/src/app/{admin,api}/pure-art/ (PURE-6 operator UI)

ABSTRACT¶

A system and method for testing network security devices ("DUT") against real public URLs accessed through the customer's production DUT (as opposed to synthetic test fixtures or cloned origin servers). The system comprises a Discovery Hub aggregating URL observations from seven heterogeneous sources (live packet capture / live syslog telemetry / live vendor management-plane API / offline PCAP import / offline HAR import / curated public Top-N lists / cloud-endpoint indirect telemetry) with privacy-preserving aggregation, k-anonymity, automated PII scrubbing across formats, and capability tagging; a two-phase validation architecture comprising (a) pre-ingestion validation via a central egress orchestrator spawning ephemeral test agents through dedicated egress (NOT through customer DUT), and (b) pre-flight validation at test execution time routed through customer DUT for delta-only checks; and a defense-in-depth in-bench resource isolation comprising three coordinated layers (pod-level scale-to-zero, BGP route advertisement withdrawal, external-vs-internal DNS sanity check) to prevent test contamination AND accidental MITM of real customer traffic when test bench infrastructure shares public IP space with the device under test.

INDEPENDENT CLAIM #13¶

A method of validating a network security appliance ("DUT") against real-world traffic patterns, the method comprising:

(a) Multi-source URL discovery — receiving URL observations from a plurality of source types selected from: - live SPAN port packet capture extracting hostnames from TLS SNI extensions and HTTP Host headers; - live syslog telemetry from one or more network security devices, parsed via per-vendor regex catalogue (Cisco FTD, Palo Alto, Fortinet, Check Point, Sophos) with a generic quoted-URL fallback; - live vendor management-plane API (Palo Alto Cortex, FortiAnalyzer, Cisco SCC) decoded from a per-vendor JSON envelope; - operator-uploaded packet capture files (PCAP) with magic-detection bounce + minimal SNI/Host header walker; - operator-uploaded HTTP Archive (HAR) files with three-aggressiveness sanitiser (light / medium / aggressive) that strips Authorization headers, cookies, sensitive JSON body keys, and pattern-matched PII (credit card numbers, CPF, email) with the original file NEVER persisted; - curated public Top-N lists (Tranco, Umbrella, Majestic, Cloudflare Radar) with embedded snapshot air-gap fallback; - cloud-endpoint indirect telemetry from cloud SD-WAN on-ramp pods;

(b) Privacy-preserving aggregation with source-IP strip at ingestion boundary, k-anonymity gate (configurable threshold), per-customer URL database (NO cross-customer cache by default), and SHA-256 stamping of source snapshots for compliance-grade reproducibility;

(c) Two-phase validation architecture comprising: - Pre-ingestion validation (PVI) orchestrated by a central egress component, spawning ephemeral test agent pods configured with NetworkPolicy egress restricted to the central egress (NOT through customer DUT), executing a three-stage cascade per URL (lightweight HTTP probe → headless browser probe → stealth-enabled headless browser probe), with WAF/bot-defense signature scanning at each stage (Akamai Reference, Cloudflare challenge, Imperva incapsula, DataDome, PerimeterX, F5 Shape, Sucuri, reCAPTCHA, hCaptcha, Turnstile), HTTP 30x redirect chain capture with scheme-upgrade and cross-domain and loop detection, response Content-Type plus body signature plus UA filtering test for target-platform classification (web-browser / mobile-app-iOS / mobile-app-Android / api-only / widget-embed), hostname-pattern matching for noise-role classification (primary / subresource / tracker / cdn-asset / dns-infra / update-endpoint), and persistent capability tagging in a central URL database; - Pre-flight validation (PVP) at test execution time, scope-reduced to a DUT-specific delta-check routed through the customer's production DUT, comprising single probe per URL via a PVI-tagged-compatible agent, with issue tagging into five categories (dut-blocked / tls-broken / routing-fail / timeout / high-latency-delta), and auto-abort when issue-rate exceeds a configurable threshold;

(d) Defense-in-depth in-bench resource isolation ("PIE-PA") MANDATORY before any production-mode test execution, comprising three coordinated layers applied as an atomic transaction with automatic rollback of partial side-effects on any layer failure: - Layer 1 — pod-level pause: scaling persona deployments to zero replicas and waiting for termination, with snapshot of original replica counts for restoration; - Layer 2 — BGP route advertisement withdrawal: querying each BGP-speaking router for advertised persona prefixes, applying route-map deny + clear-ip-bgp to force re-converge, verifying withdrawal via downstream route-table inspection; - Layer 3 — DNS sanity check: for each test URL, resolving the hostname both externally (general internet) and internally (customer recursive resolver), and HARD ABORTING the entire test when any resolved IP lies within the persona public-IP prefix space; - the three layers PROVABLY preventing accidental MITM of real customer traffic when test bench infrastructure shares public IP space with the device under test;

(e) Scheduled multi-source list refresh with monthly cadence per source vendor, schema sanity check, diff-vs-prior-snapshot gate (default 50% maximum change), atomic snapshot swap with prior retention for rollback, retry policy on persistent failure with fallback to last-known-good snapshot, and operator-uploadable offline snapshot for air-gap installations;

(f) Per-test cryptographic audit trail stamping each test invocation with the SHA-256 of the source snapshot used, enabling compliance-grade reproducibility ("rerun the same test one year later → re-downloadable + bit-identical input set");

(g) Staleness gates with severity-graded test execution behavior: fresh (0–30 days), warning (31–60 days), stale (61–89 days), critical (90+ days) which HARD-BLOCKS test execution unless explicit operator override is captured in the per-test audit flag set;

(h) Multi-engine execution dispatch routing per-URL execution to the engine appropriate for the URL's PVI capability tag, the engines selected from: synthetic browser (PW.Art) for browser-required URLs; synthetic HTTP load (K6.Art) for both-OK URLs; L7 HAR replay (HAR.Art) for high-fidelity session replay; L4 PCAP replay (DoYour.Art) for byte-faithful packet-level replay; with operator override per URL;

(i) Role-based default UI filters suppressing non-meaningful test targets (subresources, trackers, CDN backbone, DNS infrastructure, mobile-app-only endpoints, widget embeds) while preserving operator per-URL override;

(j) Cross-MÓDULO RPC integration delivering vetted URL lists from the Discovery Hub to the L7 HAR replay engine and L4 PCAP replay engine via a privacy-stamping cross-module protocol (sanitised flag always true).

DEPENDENT CLAIM #14 (Method of safety-gating)¶

The method of claim #13, wherein the defense-in-depth in-bench resource isolation is enforced by a state machine that: - maintains a strict layer order (Layer 1 → Layer 2 → Layer 3); - mutex-serializes Apply transactions per orchestrator instance; - on partial failure at any layer, atomically restores prior layers in reverse order (Layer 2 readvertise BEFORE Layer 1 pod scale-up) to maintain prefix uniqueness during pod-replica restoration; - requires Restore() to be idempotent and safe to call multiple times; - records every layer transition + outcome (ok / partial / fail / abort) in an append-only audit log keyed by test_id + operator identity.

DEPENDENT CLAIM #15 (Pre-validation precedence rule)¶

The method of claim #13, wherein the pre-flight validation (PVP) is performed BEFORE the defense-in-depth in-bench resource isolation (PIE-PA) is applied, such that test bench resources are NOT torn down when the pre-flight delta already indicates the URL list cannot succeed through the customer DUT, with the auto-abort rule triggered when (number-of-PVP-issues / total-URLs) exceeds a configurable threshold.

DISTINGUISHING ART (5 assertions)¶

vs Spirent / Keysight / Ixia (lab traffic generators): those products assume lab-isolated bench addressing — they cannot drive tests against real public URLs through a customer's production DUT because their bench infrastructure cannot disambiguate "real traffic" from "test traffic" at IP scope. Claim #13(d) (3-layer defense-in-depth) is the bridge that makes shared-IP-space production testing safe.
vs HashiCorp Vault / Akamai bot-management / Cloudflare Bot Fight: those are defense systems — they DETECT what claim #13(c) does (WAF/bot scan during PVI), but they do not extract that detection into a capability tag persisted on a URL catalog that drives multi-engine dispatch. The capability tag → engine routing of claim #13(h) is novel.
vs Splunk URL filtering / FortiAnalyzer URL log reports: those products collect URL observations from a single source (live syslog), but they do not (a) cross-source aggregate with privacy-preserving k-anonymity, (b) validate URLs with a separate ephemeral-pod cascade through dedicated egress, or (c) gate test execution on per-source snapshot staleness with SHA-256 reproducibility stamping.
vs GoFlow / IPFIX collectors: those products collect flow records, not URLs — there is no L7 extraction, no PVI cascade, no capability tagging, no Test Plan dispatch.
vs Cisco SCC / Palo Alto Cortex / FortiAnalyzer URL-filtering reports: those products are SOURCES to claim #13's Discovery Hub (claim element a), not equivalent systems. Our claim covers the aggregation + validation + safe-execution layer above them.

IMPLEMENTATION STATUS TABLE¶

Claim element	Source file	Test count
(a) 7-source ingestion	`pkg/pure-art/internal/ingestion/{syslog,vendorapi,pcap,har,curated}/`	50 (PURE-2)
(a) SPAN + Cloud endpoint	(deferred to PURE-3-late; cross-ref `discuss_cloud_endpoint_span`)	—
(b) NormalizeURL + SHA-256 stamping	`pkg/pure-art/internal/ingestion/ingestion.go` + `internal/testplan/testplan.go`	10
(c) PVI 3-stage cascade	`pkg/pure-art/internal/pvi/pvi.go` (Stage 1 real; Stages 2+3 deferred)	9 (PURE-3)
(c) WAF/bot signatures	`pkg/pure-art/internal/wafsig/wafsig.go`	9
(c) Redirect chain capture	`pkg/pure-art/internal/redirect/redirect.go`	6
(c) Target-platform + noise-role tagging	`pkg/pure-art/internal/tagger/tagger.go`	13
(c) PVP DUT-side delta	`pkg/pure-art/internal/pvp/pvp.go`	11 (PURE-4)
(d) PIE-PA 3-layer	`pkg/pure-art/internal/piepa/piepa.go` (Cascading + Simulated backends)	11
(d) Audit log	`pkg/pure-art/internal/audit/audit.go`	6
(e) Curated refresh + air-gap	`pkg/pure-art/internal/curatedrefresh/curatedrefresh.go` + `internal/ingestion/curated/seeds/tranco-top-100.csv`	12 (PURE-5)
(f) SHA-256 audit trail	`pkg/pure-art/internal/testplan/testplan.go` (`SnapshotProvenance`)	10
(g) Staleness gates 30/60/90d	`pkg/pure-art/internal/testplan/testplan.go` (`stalenessOf` + `ErrStalenessHardGate`)	(covered above)
(h) Multi-engine dispatch	`pkg/pure-art/internal/hooks/hooks.go` (`Engine` enum + `PickEngineFromRecommendation`)	5
(i) Role-based UI filters	`dashboard/src/app/admin/pure-art/PureArtBrowser.tsx` (`HideHidden`)	(UI)
(j) Cross-MÓDULO HAR/PCAP RPC	`pkg/pure-art/internal/hooks/hooks.go` (`BuildHARReplay` + `BuildPCAPReplay`)	(covered above)

Total Go tests across PURE.Art: 189 (PURE-1: 36 + PURE-2: 52 + PURE-3: 46 + PURE-4: 28 + PURE-5: 27).

FILING NOTES¶

Total patent sub-claims in family: 13 (DOM / OOBI / GATEWAY / RELAY / PURE family).
Claim #13 was reserved in the strategic memo discuss_pure_real_url_replay_2026_05_10; this provisional draft materialises the full claim language.
Patent claim #15 (the precedence rule "PVP before PIE-PA") is novel enough to potentially stand alone — recommend filing both #14 and #15 as dependent claims under #13.
Three Dependent claims surface naturally from the 3-layer state machine: per-layer enforcement, mutex-serialization, idempotent restore. Consider whether each merits a separate independent claim.

NEXT STEPS (post-provisional)¶

Patent attorney review (target: file provisional within 60 days of 2026-05-24 to lock priority date).
Implementation hardening: PVI Stages 2 + 3 (PURE-3-late), real K8sApplierBackend + VyOSBackend + MiekgDNSBackend (PURE-4-late), Postgres URL catalog (PURE-3-late).
Customer validation: pilot PURE on one customer's production DUT with full PIE-PA wired.