Inspiration

Consulting firms routinely charge hundreds of thousands of dollars for reports containing stale data and invented references, while standard AI tools generate unsourced claims and loose links. Neither approach provides verifiable proof or predictive foresight. Aphelix eliminates both failure modes by delivering a continuous competitive intelligence platform where every claim carries an explicit source, date, and forecast.

What it does

Aphelix operates as a world model for competitive intelligence, mapping relationship networks including suppliers, partners, competitors, and lost contracts to predict market movements. Focusing initially on the consumer devices sector, it tracks 301 companies across seven global regions to cover 99.5% of the market. The platform features an AI co-pilot that uses 14 tools to search the underlying network and double-check claims against sources, an automated research engine that validates new predictive signals against fixed test sets, and a live interface featuring watchlists, direct risk rankings, a 3D network viewer, and automated briefing reports. Every mapped link includes a verifiable quote, source URL, event date, and public publication date.

How we built it

The system processes data across five distinct operational layers. First, the ingestion layer uses Bright Data to extract global news, including local-language media, while Apify, Exa, and public SEC filings feed in talent and structural data. Second, the extraction layer runs Claude Sonnet to parse documents, resolve entity names, and discard events that fail cross-validation of their quote, event date, and public disclosure date. Third, the knowledge graph layer uses a Google Cloud instance of PostgreSQL 16 with pgvector to store entities, domain ontologies, and temporal labels. Fourth, the live engine layer uses a dedicated SpacetimeDB virtual machine to stream live watchlist events directly to the client browser at roughly 5,400 row updates daily. Finally, the inference and UI layer runs Claude Opus to drive the interactive co-pilot on top of the graph, delivering risk calculations, canvas views, 3D visual maps, and briefs.

Challenges we ran into

Severe data disparities required targeted adjustments because US companies accounted for 27% of entities but 56% of links, whereas Chinese A-share companies made up 18% of entities but only 3% of links; running targeted Chinese-language retrieval passes yielded 4,094 usable news units for low-coverage companies. Entity resolution errors presented another major hurdle since incorrectly merging distinct companies corrupts downstream predictions, forcing auto-merging to be capped at a 99.5% precision threshold and leading to the removal of 9 incorrect or questionable alias matches before system rebuilds. Vendor reliability was similarly strict, as only 2 of 14 tested scraping actors met quality benchmarks, leading to the removal of low-performing sources like Business Wire after producing zero usable pages across 45 trials.

Accomplishments that we're proud of

The system establishes complete end-to-end traceability for every graph connection back to a quote over 1M nodes and connections, source URL, event date, and publication date. It successfully mapped 282 of 301 targeted companies to LinkedIn profiles, generating 318 high-level talent flow records. The architecture forms a fully repeatable data processing workflow capable of scaling to new industries without structural redesign.

What we learned

Time serves as the critical axis for all predictive intelligence, as information missing a public disclosure date cannot be used to generate valid time-series predictions. Localized retrieval consistently beats generic modeling for thin companies, with local-language news parsing producing significantly larger coverage gains than statistical estimation. Strict technical quality gates prevent underperforming data signals from degrading overall model outputs, while routing all API calls through a single centralized spend ledger maintains tight cost controls at scale.

What's next for Aphelix

The immediate focus is deploying the ingestion and mapping framework to additional industry verticals. Future releases will launch automated alerts triggered by shifts in competitor risk scores and enable the co-pilot agent to draft full competitive briefs and execute actions directly from active watchlists.

How Aphelix uses our sponsors

Aphelix turns public company records into a dated, evidence-backed map of who supplies, partners with, hires from and competes with whom across the consumer-devices supply chain. Each sponsor technology powers a different layer: the agent that answers questions, the data that feeds the graph, and the live feed that brings new relationships to the user as they appear.

Factory Droid SDK: the agent behind Arbiter

Arbiter is Aphelix's analyst agent. You ask it a question such as "Which suppliers do Apple and HP share?" and it plans, calls tools over the graph and writes an answer in which every sentence cites a public record. We put Arbiter's planning loop on the Factory Droid SDK, and the Droid backend ships in the main Aphelix app (services/intel/sandbox/llm_droid.py) beside our other model backends.

One switch, same product. Setting SANDBOX_LLM=droid runs each turn in a Droid Session. The prompt, the checker, the evidence cards and the ledger are the same code as on our other backends, so Droid plugs in behind an interface we already had.

Our tools, served in process. Arbiter's tools (company context, shared counterparties, timelines, evidence lookup) are exposed to Droid through an in-process SDK MCP server (create_sdk_mcp_server with DroidTool schemas). A Droid tool call lands directly in our Python function, against the same store, and returns facts bound to evidence ids.

Read-only by construction. Droid's native shell and file tools are turned off, and a permission handler approves only Arbiter's own read tools. Droid's streamed steps and tool events map onto Arbiter's narration rail and canvas cards, so the user watches Droid work in real time.

Apify: the people layer of the graph

Companies reveal their plans through who they hire and who leaves. We used Apify actors to add a talent layer to the relationship graph.

LinkedIn at scale. The people lane ran Apify's LinkedIn company-employee actors (harvestapi/linkedin-company-employees and memo23/linkedin-company-employees-scraper) in 1,239 runs, returning 8,627 records for the tracked companies. Director-level and senior roles became person rows; everyone else is counted at company-pair level only.

Into the graph. Those runs feed 7,620 edges in the latest graph build (LAYER-3F): 6,870 current roles, 695 moves between companies and 55 board seats. Each edge carries its Apify source, so the user can see where the fact came from.

Hiring signals. The postings lane used Apify's LinkedIn company and jobs scrapers to build company-level hiring features (hiring_company, hiring_segment).

Spend under control. The runner reads each run's settled charges back from Apify and checks them against two independent counters. It deletes datasets after ingest and refuses to start a run that would exceed the budget. The whole people layer cost about USD 53.

In the CI platform too. Our CI service has a first-class apify collector for social and news posts, enabled by configuration next to RSS, SEC and web-page sources.

Bright Data: reaching the news that APIs miss

Filings tell you what a company had to disclose; the press tells you what it is doing now. Bright Data gave us news coverage our other providers could not reach.

Chinese financial news. A Bright Data Web Unlocker lane collected Chinese-language coverage from Baidu, Eastmoney, STCN, Yicai and Sina: 2,333 successful page fetches in about an hour, for the China supply-chain companies.

English newswires. A second pass fetched 771 pages and turned them into 396 news units, which went into the same extraction queue as the filings.

A drop-in second provider. We built a Bright Data provider (colab/brightdata/) that runs Google SERP plus Web Unlocker over the same entity-by-query grid as our existing Exa search, so the two providers can be compared cell by cell.

It parses dates from SERP snippets and cleans Unlocker markdown down to the article body.

It honours per-host rate limits and books failed requests at zero cost.

We piloted it on 30 consumer-devices companies. On the first 10, every news unit it produced was dated, at about 2.5 billed requests per unit.

Ready for agents. A Bright Data MCP configuration lets our Claude extraction workers search and scrape through Bright Data. The workers hold the tool, never the token.

SpacetimeDB: the live watchlist

A relationship map is most useful when it updates as the world changes. We used SpacetimeDB to stream new relationships to the user the moment they are extracted.

From seal to screen. When an extraction job is sealed on our VM, a feeder picks out new supplier, customer, contract and partnership ties for tracked companies. It pushes them through a SpacetimeDB reducer (add_tie_events) into the aphelix-live module, and every connected browser receives them.

A real-time table, not a polling API. The tie_event and watch tables are subscribed to directly from the React app through the generated TypeScript bindings. Users press Watch on a company, and watch lists are stored per browser identity.

Evidence on every row. Each live row carries its public date, source, a quote of at most 15 words and a link. It is labelled as new evidence that enters the graph at the next rebuild. The feed handles about 5,400 new ties a day.

Secure by design. Only the module owner's identity can write rows. A probe script checks that a non-owner is refused and measures the time from seal to arrival.

In the product. The live ties panel ships in the main Aphelix shell. It loads the SpacetimeDB SDK on demand, so the first page load stays light.

Together

Apify and Bright Data widen what Aphelix can see: people moves, Chinese-language press and newswires. SpacetimeDB brings what it finds to the user live. Factory Droid lets an agent reason over all of it while every claim stays tied to its source.

Built With

Share this project:

Updates

Submission history