~/systems · companion to the case study
Company: Omnibound AI · AI search marketing platform · Role: AI GTM Engineer · This page: the reliability layer under the case study numbers, not the pitch
~/walkthrough · 2 min, narrated
The case study tells the revenue story: 5 logos, $897K+ pipeline, an engine live in under 3 days. None of that holds up if the layer underneath is sloppy - a mis-scored lead, a fabricated "signal," a duplicate send, or a domain that gets blocklisted mid-campaign will quietly cap every number above it.
This page is the part most GTM builds skip: the audits, the fail-closed gates, and the infrastructure discipline that make the funnel numbers trustworthy instead of just fast.
A reusable mailbox-and-domain audit runs against Smartlead and live DNS: every sending domain checked for SPF, DKIM, and DMARC; every mailbox scored READY / WARN / NOT-READY against warmup reputation and blocklist status. Volume is deliberately throttled well under capacity rather than run hot.
The 5% utilization is intentional headroom, not idle capacity: committed send volume stays a fraction of what the infrastructure can safely carry, so reputation has room to absorb spikes without threatening inbox placement.
Every claim used in outbound copy - a funding signal, a "this company shows up in AI search answers," a person's current title - has to be verified against a live source before it can be sent. No verified claim, no copy; a blocked article or a dead API key holds the lead rather than guessing.
That discipline came from a real incident: a fabrication slipped through on July 2. The founder call two weeks later wasn't to patch the deterministic checker and move on - it was to compare it head-to-head against a slower, harder path where a Claude agent researches each lead directly instead of a fixed rule set.
The slower path won and became the default for real runs. Compute got more expensive per lead; false positives to real people got rarer. Same week, the engine dropped its one remaining third-party LLM dependency for the AI-search check and replaced it with the agent's own search tool - one less vendor in the trust chain, and the copy stopped naming any specific AI product it hadn't actually queried.
Four parallel audits ran in one sitting - factual pipeline, intel/scoring, bulk runners, live-send safety - against the actual code and live data, not a design doc. ~40 findings surfaced; every critical and high was fixed the same day, then re-validated on a live batch.
Total addressable market was cross-checked across two independent sources before any list-building started, rather than trusting one vendor's count.
Every batch job into that pool runs through fail-closed gates before a single row moves: a missing suppression file kills the run rather than silently sending anyway, competitors are hard-excluded, and previously-contacted people and their whole domain are skipped by default. The most recent full batch processed 2,804 contacts across a 6-way engine and mailbox-combo grid, with 2,772 passing validation - 98.9%, run in dry mode and reviewed before any send authorization.
~/proof · not slideware
Screens, not diagrams: the real repo, the real sending infrastructure, the real enrichment pipeline.
Provider mix: 201 Gmail · 41 Outlook · 30 SMTP. The same numbers that gate every send are what the reusable audit script pulls live, not a one-time snapshot.
Every send feeds back into the same suppression list that gates the next one: reply classifications (bounce, unsubscribe, left-company, negative) get pulled before each re-engagement cycle, and stop-on-reply is enforced at the platform level as a second net. The system that sends today is measurably harder to send a bad lead through than the one that shipped six weeks earlier - the fail-closed changes compound instead of getting patched around.
"Every claim ships verified or it doesn't ship. The discipline underneath the funnel is the whole system." - the operating principle behind this layer, mirrors the one behind the case study