{"slug": "stratagems-13-p-posted-a-question-on-a-public-forum-24-hours-later-their-sales", "title": "Stratagems #13: P Posted a Question on a Public Forum. 24 Hours Later, Their Sales Team Called.", "summary": "P, a security researcher, posted a technical question on DEV.to containing a deliberately altered model version tag that matched Finova's internal pipeline. Within 24 hours, Finova's sales team called, confirming that someone was monitoring the forum and that the company had copied P's publicly shared architecture.", "body_md": "Startle the snake by striking the grass.\n\n— The 36 Stratagems,[Stomp the Grass to Scare the Snake]\n\n**Previously on this series:**\n\n[ #1: Mark Johnson Walked Into an AI Audit. The Benchmark Had Everything Figured Out — Except the Truth.](https://dev.to/xulingfeng/stratagems-1-mark-johnson-walked-into-an-ai-audit-the-benchmark-had-everything-figured-out--adh) — Mark audited a company called Pulse AI. The benchmark evaluation set had 98 fabricated data points. CTO Torres called at 3 AM to confess: they needed the numbers at 95% before the C-round. Mark hung up. Pulse AI did not die.\n\n[ #7: P Watched an AI That Only Looked One Way. The 99.97% Was Real. It Just Missed Everything That Mattered.](https://dev.to/xulingfeng/p-watched-an-ai-that-only-looked-one-way-the-9997-was-real-it-just-missed-everything-that-1djm) — P used a simulated attack as bait to expose the critical blind spot in FortDefender's security system. The 99.97% accuracy was real. It just missed everything that actually mattered.\n\nThis was three months later.\n\nP and Mark met on DEV.to. Mark had replied to one of P's posts — a precise technical answer that was correct on every front. P thanked him. The email thread stayed open, but neither of them wrote again.\n\nP was doing pre-audit work. An AI platform coming up for review — a risk model evaluation pipeline under Finova. While digging through their tech stack, P noticed something interesting. A model evaluation approach P had casually discussed on DEV.to months ago — a bagging ensemble + k-fold time-series cross-validation pipeline for risk modeling — matched Finova's publicly documented architecture almost line-for-line.\n\nSame framework (TensorFlow 2.x + TFX). Same ensemble strategy (XGBoost + LightGBM stacking). Same evaluation window size and sliding step as the example P had posted. P pulled up the old post — it was published before this Finova product line even went live. And it wasn't just the technical whitepaper. Every signal pointed the same way: Finova engineers at meetups, their open-source tooling on GitHub, the tech stack in their job descriptions.\n\nP put the two documents side by side on screen. Finova's whitepaper on the left. P's own DEV.to reply on the right. Not a coincidence. Someone was watching.\n\nOne in the morning at the Third Cup. P sat at the usual table by the window, screen dimmed to minimum. The person behind the bar put down an espresso without asking — regulars at the Third Cup don't need to order.\n\nP did one thing. Opened a new tab, logged into DEV.to, created a new post. Title: *Discussion: Evaluation set leakage in ensemble-based risk model backtesting.* P used an account registered six months ago with a few routine technical posts — a normal discussion history, not a fresh account that just appeared out of nowhere.\n\nThe post body laid out a detailed model configuration:\n\n```\nA typical risk model evaluation pipeline we set up looks like this:\n\nModel architecture: XGBoost + LightGBM stacking ensemble\nEvaluation strategy: rolling window time-series CV (12-month window, 3-month step)\nTraining features: ~480 dimensions (transaction time-series + user behavior embedding + external credit score)\neval_batch_size: 2048\nModel version: risk-ensemble-v3-test-stub\n\nWe ran into a temporal leakage issue with the evaluation set...\n```\n\nThe `risk-ensemble-v3-test-stub`\n\nwas the changed part — Finova's real tag was `prod`\n\n. Every other line matched Finova's actual pipeline configuration: model architecture, feature dimensions, rolling window step, batch size. The problem was real. The parameters were real. The only fake one sat in the middle, looking like a routine experimental version tag.\n\nBefore posting, the cursor hovered over the submit button for two seconds. Then clicked.\n\nThen P waited.\n\nPhone on the left side of the table, screen on, face up. No one called.\n\nThe espresso cup was empty. P flipped through a few notes, glanced at the phone again. No one called.\n\nBut if there's a snake in the grass — strike the grass, and the snake will scare itself.\n\nThe next afternoon. Phone lit up. Unknown number.\n\nP watched it ring for three seconds. Didn't pick up right away.\n\nNo caller ID. P's fingers tightened around the phone — just for a moment.\n\nPicked up on the fourth ring.\n\nThe caller introduced himself: Pulse AI sales team. They'd seen P's question on DEV.to. Their platform had similar capabilities. Would P be open to a demo? Friendly tone. Standard script.\n\nP listened. Eyes on the post page still open on screen — the parameters were still the altered version.\n\nThe salesperson ran through their product capabilities, then casually mentioned P's environment setup —\n\n**\"I'm referring to your model evaluation configuration, the risk-ensemble-v3-prod pipeline...\"**\n\nP paused. One beat.\n\n**\"Sure, I'll think about it.\"**\n\nHung up. Didn't ask anything else.\n\nP's hand stayed on the phone.\n\nThe post said `test-stub`\n\n. The caller said `prod`\n\n. There's only one place that name could have come from.\n\nP put the phone down on the table.\n\nThe person behind the bar looked up. Said nothing. Went back to drying a glass.\n\nThe post page was still open. The cursor hovered over the edit button — P could change the parameter back. Didn't. Closed the DEV.to tab. Opened a terminal.\n\nP set up a honeypot. Switched to another account — an older one, mostly questions with a few answers sprinkled in, read like a junior-level engineering manager. Posted a generic question in the same direction:\n\nHas anyone run ensemble risk pipeline evaluation with rolling window validation in production? Our results keep fluctuating across windows — not sure if it's data leakage or the evaluation strategy.\n\nThe question was deliberately vague. No tech stack details. No paragraph breaks. Typed like it was sent from a phone. The post embedded an architecture diagram — the image URL pointed to P's VPS, carrying `Referer`\n\nand `User-Agent`\n\nheaders with each request. P configured `Cache-Control: no-cache, no-store`\n\non the VPS, forcing CDN to revalidate on every hit — making sure every crawler fetch landed in P's Nginx logs.\n\nTwo days. The tracking link was never clicked. Nothing.\n\nThen P made a second post. Switched back to the first account. This one kept the full technical signature:\n\nWe're running XGBoost + LightGBM stacking for risk model evaluation in production — 12-month rolling window, 3-month step, batch size 2048. A few curves are looking abnormal and we suspect evaluation set leakage. Model version is risk-ensemble-v3-test-stub. Anyone run into something similar?\n\nSame setup: an external reference link at the bottom of the post, pointing to an HTTP endpoint on P's own server. When a crawler hit it, the server logged the IP, User-Agent, and timestamp — then issued a 302 redirect to a public research paper's PDF. To a crawler, it looked like a normal paper link.\n\nIt was 3 AM by the time all of this was done. P didn't turn off the computer. Dimmed the screen. Got some sleep.\n\nLess than 6 hours. The trigger fired.\n\nThe second post — the one with the full technical signature. The first post, the generic one, never got indexed. Bots don't read vague questions. They read technical fingerprints.\n\n```\n[REQUEST LOG — 07-13 08:22:08]\nSource IP: [REDACTED] → [REDACTED] (/24 range, 12 distinct hosts)\nTarget: DEV.to post #4829 (slug: ai-pipeline-behavior)\nPipeline: Page fetch → ML intent classifier → tech-stack extractor → CRM confidence model\nKeywords hit: [ai model evaluation, ensemble method, risk pipeline, batch size 2048]\nCRM lookup: 4/8 cross-reference fields matched\n  → model architecture match ✓\n  → training distribution match ✓\n  → eval config structure match ✓\n  → batch size pattern match ✓\n  → parameter name: mismatch (not excluded — weighted partial match)\n  → final confidence: 0.87\n  → tag inferred: risk-ensemble-v3-prod\nSales queue: match → thread author email extracted from forum profile → queued to PulseAI SDR (priority: medium)\n\n[ROUTING]\nRequest interval: every 4-6 hours across 12 IPs, round-robin\nTech stack detection: 43 framework signatures extracted from headers, SEO meta, DOM class patterns\n```\n\nP read through it line by line. The screen cast a reflection on P's face. No expression. Two taps on the tabletop — then stopped.\n\nRead the last three lines again.\n\nPulse AI was systematically monitoring DEV.to. Auto-scraping technical posts. Extracting tech-stack signatures. Matching sales leads. Routing outbound calls. No human intervention anywhere.\n\nP took a screenshot. Closed the terminal.\n\nP opened the email list. An old thread — someone in the industry had mentioned an independent audit report a few months back, commissioned by a VC firm to dig into Pulse AI. The sender address was the same one in the current email thread.\n\nThe next morning. Same number.\n\nP glanced at it. Didn't decline. Swiped.\n\nDifferent voice this time. Calmer. Technical account manager, he said. His team had reviewed P's second post — the one with the full technical signature — and ran an internal evaluation. The match was significantly higher this time. They wanted to set up a deeper technical discussion.\n\nHe was more specific than the first caller. Mentioned the model architecture direction. Suggested batch size tuning. Even referenced the paper from P's embedded link — like he was reading from a briefing, not researching it himself.\n\nP listened. Fingers still. Opened the terminal window on the desktop — the honeypot logs were still on screen. `confidence: 0.87`\n\n. `tag inferred: risk-ensemble-v3-prod`\n\n. 12 IPs in round-robin. CRM 4/8 match.\n\nP let him finish.\n\nTwo seconds of silence.\n\n**\"Your crawler is better than your sales pitch.\"**\n\nHung up.\n\nThis time, P's hand didn't tighten around the phone. P put it down on the table. Closed the terminal window. Opened email.\n\nP opened the thread with Mark Johnson. Sent the crawler's technical signature — log snippets, URL patterns, pipeline naming conventions.\n\nMark's reply came a few hours later. Short.\n\nHe wrote in his email that these naming conventions weren't something you find on the internet. He'd been inside Pulse AI.\n\nAttached was a screenshot — a pipeline config skeleton he'd saved during the Pulse AI audit. The `triple_redundant`\n\nsuffix wasn't in the screenshot — that piece was added after he'd left — but the directory structure he'd spent months in, combined with P's crawler path data, was enough to reverse-engineer the full naming convention:\n\n```\n/pulse/ingestion/{env}/{source}\n├── prod\n│   ├── api_gateway\n│   ├── benchmark_framework\n│   └── sales_engine        ← new, wasn't in his audit scope\n├── staging\n│   ├── api_gateway\n│   └── benchmark_framework\n└── dev\n    └── sandbox\n\nNaming convention: pulse_{service}_{env}_triple_redundant\nDEV.to crawler paths P observed:\n  pulse_crawler_prod_triple_redundant\n  pulse_crawler_staging_triple_redundant\n\nSame template as the Benchmark dataset.\n```\n\nThe crawler wasn't outsourced. Pulse AI built it themselves — using the same architecture habits from the old Benchmark AI fabrication days. Same directory structure. Same naming rules. Same environment separation. Different job, same hand.\n\nOne more line at the bottom of Mark's email:\n\n**\"Torres didn't change architects.\"**\n\nP read it. Didn't reply. Stared at those five words for a moment. The cursor hovered over the close button — paused — then clicked.\n\nP didn't go public. Didn't post a third article. Didn't call the authorities.\n\nP organized everything into a folder — posting timeline, call recordings, honeypot logs, crawler request records, Mark's confirmation screenshot, Pulse AI pipeline comparison. Named it `pulse_crawler/`\n\n. Stored locally.\n\nP didn't close the laptop right away. That log line — `risk-ensemble-v3-prod (confidence: 0.87)`\n\n— was still on the terminal. Stared at it for a few seconds.\n\nClosed it.\n\nP typed `gpg -c`\n\n.\n\nNot yet. But this folder would open eventually.\n\n3:45 AM. Fifteen minutes until the Third Cup closed. When P pushed the door open, the person behind the bar glanced at the clock — not many customers at this hour. Didn't ask. Turned around and took a cup off the shelf.\n\nP opened the email. Wrote back to Mark. Started with thanks for the technical confirmation. Ended with —\n\n**\"Next time, let's talk in person. The Third Cup. My tab.\"**\n\nClosed the laptop. Coffee hadn't come yet.\n\n4:00 AM.\n\nMark received the email. Read the last line. He didn't reply right away.\n\nThe screen went dark.\n\n**This is Stomp the Grass to Scare the Snake — when you're not sure if the snake is there, strike the grass. If it is, it'll prove itself.**\n\n```\n[36 Stratagems Tactical Database v3.2.1] Loaded\n[Tactic Match] Stomp the Grass to Scare the Snake\n[Analysis Mode] Full-field scan\n━━━━━━━━━━━━━━━━━━━━\nTactic Match: ~83%\nOperator: P\nAction: Posted a deliberately modified technical parameter on a public forum thread\nObjective: Confirm whether the forum is being systematically monitored for sales targeting\nResult: Crawler infrastructure identified via honeypot post + server-side tracing. Pipeline lineage traced to a prior engagement the operator was unaware of.\n\nObservation: We notice that the crawler outperformed on every metric the sales team measures — pattern matching, tech-stack extraction, CRM cross-referencing. It still lost. The operator did not beat the crawler at its own game. The operator understood what the crawler was optimizing for and designed the variable it could not account for: a parameter value that was technically valid, contextually plausible, and deliberately wrong.\n\nDecision Evaluation:\n  - Target: Pulse AI forum monitoring infrastructure\n  - Bait: `risk-ensemble-v3-test-stub` (one parameter changed, seven left untouched)\n  - Confirmation: Second post triggered within 6 hours. CRM assigned 0.87 confidence to inferred tag `risk-ensemble-v3-prod`\n  - Net effect: Infrastructure confirmed without penetration. No access to the data — confirmation of the pipe.\n\nRisk Assessment:\n  Personal cost: Low. No exposure of the operator's identity.\n  Institutional cost: Medium. The crawler is part of a systematic monitoring infrastructure.\n  Observational note: The operator paused before hanging up the first call. The metrics do not have a field for that.\n```\n\n*Next stratagem: Pilfer a Plum Along the Way*\n\n*P.S. English isn't my first language. I use AI to polish the writing and smooth out the rough edges. Thanks for reading. ☕ Buy me a coffee*", "url": "https://wpnews.pro/news/stratagems-13-p-posted-a-question-on-a-public-forum-24-hours-later-their-sales", "canonical_source": "https://dev.to/xulingfeng/stratagems-13-p-posted-a-question-on-a-public-forum-24-hours-later-their-sales-team-called-29h1", "published_at": "2026-07-14 02:54:49+00:00", "updated_at": "2026-07-14 03:28:16.764506+00:00", "lang": "en", "topics": ["ai-safety", "ai-ethics", "developer-tools"], "entities": ["P", "Mark Johnson", "Finova", "DEV.to", "TensorFlow", "TFX", "XGBoost", "LightGBM"], "alternates": {"html": "https://wpnews.pro/news/stratagems-13-p-posted-a-question-on-a-public-forum-24-hours-later-their-sales", "markdown": "https://wpnews.pro/news/stratagems-13-p-posted-a-question-on-a-public-forum-24-hours-later-their-sales.md", "text": "https://wpnews.pro/news/stratagems-13-p-posted-a-question-on-a-public-forum-24-hours-later-their-sales.txt", "jsonld": "https://wpnews.pro/news/stratagems-13-p-posted-a-question-on-a-public-forum-24-hours-later-their-sales.jsonld"}}