Skip to main content

AI Infrastructure Research Desk

A solo-built research desk that turns scattered market chatter, filings, and news into a structured view of AI-driven market trends, with a complete research workflow on top.

Context
Personal project · AI infrastructure research
Period
2026 – present
Categories
Data ProductsData ScienceAutomationAI

Executive Summary

The AI buildout is repricing whole sectors of the market, and understanding it means watching trends, not tickers. The AI Infrastructure Research Desk is a personal system I built end-to-end to track those trends: which themes are accelerating, which companies benefit directly versus one layer down, and what the evidence actually supports. Data centers are the anchor theme, but the lens is wider on purpose. It covers semiconductors, power and grid, networking, memory, cooling, colocation, and space infrastructure, organized into thematic watchlists across 121 tracked companies.

The desk covers a five-stage workflow as one connected loop: map the theme (which companies benefit, and where the bottlenecks are), discover names early (scanners and scored signals), generate and vet ideas (AI-backed analysis with human review), follow institutional money (13F flows), and manage and learn (planning, an earnings calendar, and a journal whose outcomes feed back into the research). Nothing in the system is a one-shot stock pick. It's a pipeline where each stage's output is the next stage's input.

The Problem

The goal is not to guess the next stock in one step. It's to build a repeatable system that answers structural questions about the AI trend: which themes are inflecting, which companies are direct beneficiaries versus second-order enablers, which relationships are disclosed versus inferred versus unknown, and where the bottlenecks sit, whether that's chips, memory, networking, optics, power, cooling, colocation, or backup generation.

Done manually, this research means re-reading the same filings, re-searching the same names, and losing yesterday's insight in a browser tab. It's the same disease as every manual institutional process I've automated, just with SEC filings instead of program webpages.

Architecture

The system is a Python + SQLite platform with a clear pipeline: collectors ingest from each source on its own cadence, a scoring engine turns raw text into comparable signals, a relational model stores companies, relationships, and evidence, and a local API serves a web UI with watchlists, signal feeds, and premarket views.

Social signalsReddit · StockTwitsSEC EDGARfilings & eventsNews & marketprices · headlinesIngestionPython collectorsSignal scoring0–100 keyword engineSQLite modelcompanies · relationshipsWeb UIwatchlists · premarketlocal API
Multi-source ingestion converges on a scoring engine and a SQLite research model, served locally.
  • Ingestion: dedicated Python collectors for Reddit, StockTwits, SEC EDGAR filings, company news, and multi-provider market data with automatic fallback between price feeds. Each collector is isolated so one flaky source can't poison the rest.
  • Two interpretable scoring engines: Early Signals (0–100 breakout-potential scores with catalyst timing) and Breakout Watch (news scoring across categories like guidance raises, earnings beats, and revenue acceleration). Both are keyword-driven on purpose, so every score traces back to the exact phrases that produced it.
  • Discovery scanners that find names before headlines do: relative volume versus 20-day average, RSI momentum across the tracked universe, and SEC 8-K full-text scanning for contract awards and design wins.
  • Institutional flows: 13F filing tracking via SEC EDGAR, with the caveats modeled honestly. 13F data lags roughly 45 days, and put positions are flagged as possible hedges rather than directional bets.
  • Research model: a SQLite schema mapping companies, operator-to-vendor relationships, and the evidence behind each link.
  • Delivery: a local API server and a web UI organized into sixteen task-focused views, from premarket analysis and signal feeds to a supply-chain map and an earnings calendar.

Research Rules: Data Governance for One

The system runs on written research rules, the same data-governance discipline I'd apply to an institutional dataset:

  • Separate exposure from valuation. An exposure score estimates how directly a company benefits from data center buildout. It is explicitly not a buy rating.
  • Track evidence strength. Every operator-to-vendor relationship is labeled High, Medium, or Low confidence based on how directly it is disclosed.
  • Do not invent backup vendors. If a supplier relationship isn't publicly disclosed, it stays marked unknown rather than plausible-sounding.
  • Tie every company to a source: official company pages or announcements, not vibes.
  • Keep market data physically separate from research notes, so stale prices can't silently contaminate source-backed supply-chain work.

Rule three is my favorite. A research database that refuses to guess is worth more than one that always has an answer.

AI in the Loop, Reviewably

  • Model-backed analysis runs (premarket, open-market, and post-market journal reviews) are built with a structured-output API and web search, and they degrade gracefully: without credentials, a local tracker-based fallback keeps every view working.
  • The UI includes a 'Copy Prompt' control exposing the exact prompt payload behind any analysis, so AI output is inspectable rather than oracular.
  • AI-generated research (say, a ChatGPT-produced company list) never merges directly. A staging script writes it to a review area where new companies, overlaps, and source quality get checked before anything touches the seed data.

This is the pattern I bring to AI-assisted work generally: use the model for leverage, keep a human review gate in front of the system of record, and make every automated conclusion traceable.

Deployment Architecture: Local-First on Purpose

A partial copy runs on Vercel, but the primary system is deliberately local-first, and the reasoning is the part of this project I'd defend in a design review. The workload is a stateful ingestion loop writing continuously to SQLite on disk. Serverless functions have ephemeral filesystems, so truly hosting this means swapping SQLite for an external database, moving collectors into cron jobs or queues, and rebuilding the caching layer. That's a re-architecture, not a deploy.

For a single-user research tool, that re-architecture buys nothing. Locally there are no cold starts, no function timeouts on long multi-step research operations, no function-count ceilings, and no egress bills for hammering my own API. Knowing when not to put something in the cloud is a systems decision too.

Two Modes, One Desk

Financial tools have a voice problem. The interface language of a trading desk (tickers, RSI, invalidation levels) signals 'you don't belong here' to anyone who didn't grow up with it. That gatekeeping is a design choice, so I made a different one. The desk ships with two complete interface registers: Full Desk, the dense professional view, and Soft Mode, which rewrites the entire experience in plain, warm language for people just getting into investing. Women are heavily underrepresented in that audience, and not by accident.

Soft Mode isn't a feature-reduced 'lite' version. Same data, same signals, same workflow. What changes is the voice: 'Open Briefing' becomes 'Open calm idea list,' 'Open Retail Pulse' becomes 'Show retail chatter,' and every module explains what it's for and what to click next instead of assuming you already know. It's the same design conviction behind the Equity Gap Calculator's simple and technical result modes. Expertise should live in the analysis, not in the vocabulary barrier. Both modes are in the public demo, so try the toggle.

Limitations & Responsible Framing

  • Signal scores are research indicators, not predictions. The scoring is keyword-based and transparent precisely so it can be doubted intelligently.
  • Supply-chain relationships are only as good as their evidence; the model distinguishes disclosed from inferred links rather than presenting both as fact.
  • This is a personal research tool. Nothing it produces, and nothing in this case study, is investment advice.

Skills Demonstrated

  • End-to-end system design: ingestion, scoring, storage, API, and UI built solo
  • Python ETL against heterogeneous sources (social APIs, SEC EDGAR, news, market data)
  • Interpretable scoring-engine design and SQLite data modeling
  • Deployment-architecture judgment: choosing local-first for a stateful workload and knowing what productionizing would require
  • AI-assisted development used deliberately, with the architecture and every scoring rule owned and reviewed by me

Skills in this project

  • Python
  • SQLite
  • ETL
  • APIs
  • SEC EDGAR
  • Signal scoring
  • Data modeling
  • Web scraping
  • Inclusive UX design
  • AI-assisted development