AI Infrastructure Research Desk

When AI data center capex rises, which public companies actually benefit — directly, or one layer down the supply chain? Answering that question repeatably requires connecting things that live in completely different places: social sentiment, SEC filings, news flow, price action, and the disclosed (or inferred) relationships between operators and their vendors. The AI Infrastructure Research Desk is a personal system I built end-to-end to do exactly that.

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 goal is not to guess the next stock in one step. It's to build a repeatable system that answers structural questions: which companies are direct beneficiaries of data center buildout versus second-order enablers? Which operator-to-vendor relationships are disclosed, which are inferred, and which are still unknown? Where are the bottlenecks — chips, memory, networking, optics, power, cooling, colocation, 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.

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.

• Ingestion: dedicated Python collectors for Reddit, StockTwits, SEC EDGAR filings, company news, and multi-provider market data (with automatic fallback between price feeds) — each 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 keyword-driven on purpose — 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; 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.

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

• 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.

• Model-backed analysis runs (premarket, open-market, and post-market journal reviews) are built with a structured-output API and web search — and 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 (e.g. 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.

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.

• 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.

• 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