Google Thinks You Know That Person. Do You Know What That Means?

TRIPLE HELIX DATA & AI

A PySpark and GremlinPython pipeline for SERP brand association risk management, because the Epstein problem is now anyone’s problem.

David Kabii | triplehelixdata.org | Triple Helix Data & AI Framework

The Epstein Problem Is Not About Epstein

Jeffrey Epstein had a lot of contacts. The men and women who attended his dinners, gave his foundation money, or sat next to him at one conference did not know they were banking a liability. They were doing what professionals do: networking. Their names appeared in his book, in news coverage, in court documents. Google indexed it all. Search for some of them today and the association still surfaces, years later, with zero editorial intent from anyone.

That is the SERP association problem. It does not require you to do anything wrong. It requires only that you are co-mentioned with someone who later does. The search engine does not judge. It does not differentiate between a handshake and a conspiracy. It scores proximity.

This pipeline gives you the ability to measure that proximity before someone else does.

What SERP Management Actually Is

SERP management is the practice of understanding, monitoring, and influencing what appears when someone searches your name or brand. Most people think of it as “pushing down bad results.” That is the reactive version. The proactive version starts with a graph.

When Google processes search results for your name, it is running a form of graph computation. Your entity has edges. Those edges connect to every URL you appear in, every co-mentioned person, every domain that references your contact details. The PageRank era is over but the graph model is not. Google’s Knowledge Graph, entity recognition systems, and SERP clustering algorithms all operate on relationships between entities, not just keyword frequency.

Managing your SERP means managing your graph. That means you need to know what is in it.

The Triple Helix Architecture

This pipeline follows the Triple Helix Data & AI Framework: three co-evolving strands coiled around a shared data platform and an organisational contract, converging on Decision Engineering.

Strand 1: Data Reliability (SERP Ingestion)

PySpark ingests raw SERP results from any provider: SerpAPI, Bright Data, ZenRows, or a self-managed Playwright scraper cluster. The ingestion layer enforces:

• Deterministic deduplication via SHA-256 on (url, brand_entity)

• Schema enforcement using StructType with TimestampType for scraped_at

• Full-text column concatenating title + snippet for downstream NER

• Source domain normalisation for graph edge typing

The ingestion function is provider-agnostic by design. Swap mock_serp_results() for any SERP API client and the rest of the pipeline is unchanged.

Strand 2: Analytics & Insights (GremlinPython Graph)

Extracted entities are written to a GremlinServer instance: JanusGraph locally, AWS Neptune in production. The graph schema uses two vertex labels (brand, entity) and typed edge labels matching the risk weight taxonomy.

The ego-graph query returns the 1-hop association neighbourhood. A second-hop query is available for deeper network analysis: finding who your associations are associated with, which is exactly how the Epstein problem propagates.

Edge weight formula:

weight = RISK_WEIGHTS[edge_type] * (1 + entity_risk_score)

Where edge types and their baseline weights are:

• CONTACT (phone or email in same page): 0.30

• SOCIAL_PEER (FB mutual, LinkedIn 2nd degree): 0.25

• COAUTHOR (co-byline, co-paper): 0.20

• CO_MENTION (same paragraph): 0.15

• CO_RESULT (same SERP result page): 0.10

CONTACT edges carry the highest weight because a phone number or email indexed alongside a risk entity is not ambiguous proximity. It is linkage.

Strand 3: BI & AI (Brand Risk Scoring)

The BrandRiskScorer aggregates ego-graph edge weights into a normalised brand risk score and assigns a risk tier:

• GREEN: score < 0.20. Baseline clean. Monitor monthly.

• AMBER: 0.20 to 0.44. Moderate associations. Contextualise and monitor weekly.

• RED: 0.45 to 0.69. Elevated risk. Publish counter-narrative content within 14 days.

• CRITICAL: 0.70+. Immediate response. Legal review, PR intervention, content displacement campaign.

The scorer emits a BrandRiskReport dataclass containing the full ego graph, high-risk entity list, strand scores, and prioritised recommendations. This is the Decision Engineering output: not a dashboard metric, but an actionable brief.

Connection Sources: What the Pipeline Checks

The pipeline checks four categories of connection source. All of them are indexed by search engines. Most people do not know they are.

1. SERP Co-mentions

The most direct signal. If your name appears in the same article, press release, or LinkedIn post as a risk entity, Google associates you. The pipeline extracts named entities from SERP snippets using regex NER (swappable for spaCy or AWS Comprehend in production) and scores them against a risk keyword lexicon.

2. People-Search Aggregators

Sites like TruePeopleSearch, Spokeo, BeenVerified, and Whitepages index phone numbers, addresses, and known associates from public records. If your phone number appears next to someone with a risk history in a people-search result, the pipeline captures it as a CONTACT edge with weight 0.30. These sites rank well. They are often the third or fourth SERP result for a person’s name.

3. Social Graph Indices

Facebook’s public friends lists were indexed extensively before privacy policy changes. Third-party graph tools archived significant portions. LinkedIn 2nd-degree connections are visible in SERP snippets. The pipeline models these as SOCIAL_PEER edges. If your public friends list includes someone later convicted of a financial crime, that association is in the graph.

4. Phone Numbers and Email Addresses

Contact details in SERP results create direct graph edges regardless of context. A phone number appearing on a domain associated with fraud creates a CONTACT edge even if you listed that number in a different context. The pipeline detects phone and email patterns in snippet text and flags them for opt-out action.

Running the Pipeline

Install dependencies:

pip install pyspark gremlinpython

With GremlinServer running (JanusGraph or TinkerGraph):

python serp_brand_graph_pipeline.py “Your Name”

In offline mode (no GremlinServer), the pipeline runs in simulation, produces the same risk report using in-memory graph computation, and writes brandrisk{id}.json. The simulation mode exists precisely for CI/CD integration: run this against your brand on every deployment pipeline.

For production Neptune deployment, replace the GREMLIN_ENDPOINT constant with your Neptune cluster endpoint and set IAM authentication headers in the BrandGraphClient constructor. The query syntax is identical; Neptune is Gremlin-compatible.

The Decision Engineering Output

The pipeline does not produce a dashboard. It produces a brief. The BrandRiskReport is structured to answer three operational questions:

• What is my current association risk score and tier?

• Which specific entities are creating that risk, via which connection type?

• What actions should I take, in what order?

The Shared Axis governance layer enforces a compliance verdict gate before the report is emitted. A report with CRITICAL or RED tier triggers an alert channel. The recommendation engine generates entity-specific actions: not generic SERP advice, but targeted instructions like “submit opt-out to TruePeopleSearch for phone number +254 700 XXX XXX” or “publish clarifying content contextualising co-mention with Max Holloway on news.example.com.”

That is the Triple Helix model operating as designed: Data Reliability feeding Analytics feeding BI and AI, all three strands contributing to a decision, not just a report.

What You Can Do With the Output

The report identifies edges. Your SERP strategy removes or outweighs them.

• For CO_RESULT and CO_MENTION edges: publish new content that ranks for your name and displaces the co-mention URL. Author attribution on high-authority domains works faster than most people expect.

• For CONTACT edges: submit data removal requests to people-search aggregators. Most have automated opt-out forms. Verify within 72 hours. Google typically de-indexes within 30 days of source removal.

• For SOCIAL_PEER edges: lock down public friends lists on Facebook. Audit LinkedIn connection visibility settings. The graph cannot index what it cannot read.

• For COAUTHOR edges: if a co-author later becomes a risk entity, publish a clarifying statement as a new indexed URL. Do not delete the original; deletion signals suppression and often triggers more coverage.

The Epstein problem is ultimately a graph problem. You cannot unsign a guest book. But you can publish enough counter-signal that the guest book entry moves to page three.

David Kabii is the inventor and author of the Triple Helix Data & AI Framework, an independent data and AI consultant based in Nairobi, Kenya, with 15 years of production data engineering experience across East Africa. GitHub: github.com/dkabii | Web: triplehelixdata.org