Bigdata.comby RavenPack
Bigdata.comby RavenPack
Nikhil Iyer Bigdata Trends · Product & engineering

Building Bigdata Trends

From news
to evidence.

How we built Bigdata Trends to help investors explore the forces affecting companies, with a path from each index move to the reporting behind it.

Inside Bigdata Trends

From financial reporting to traceable evidence

Find the companiesSearch, co-mentions & exposure checks
Define the questionsNarratives, mechanisms & statements
Extract & checkCompany events, relevance & freshness
Score & deduplicateKeep event identity and source evidence
Explore the evidenceInspect companies, periods & sources
Company discovery and a structured taxonomy guide retrieval. Extracted events are checked, scored and connected to their sources for exploration.

Bigdata Trends began with a question: how could we help investors understand the forces affecting a theme without having to piece together every article themselves? In my first conversations with Peter and Aakarsh, we discussed tracking macro trends, starting with AI bottlenecks and the industrial supply chains around them. My experience building knowledge graphs and processing unstructured data made this a problem I was particularly keen to tackle.

I estimated three days. The project took roughly three months, with the first week spent getting my bearings. Calling it a three-day project was, in hindsight, a small act of tomfoolery. Most of the work was in questions that sounded straightforward until we examined the output: which companies belonged, what an article actually established, and how often we were counting the same event.

I was also interested in whether tracking narratives could eventually support research into early catalysts or forward earnings. Those remain research questions, not capabilities claimed here. The proof of concept focused on a practical task: explore an investment theme, follow its narratives and inspect the reporting behind an index move.

Rare Earths became our first implementation. Building it meant turning a large volume of reporting into company-level events that a reader could check. The charts made the results accessible; inspecting what sat underneath them drove much of the development.

Finding the companies

Rare earths offered a way to examine upstream industrial activity, from mining and processing to magnet manufacturing. Government policy and demand changes could affect each part of that chain differently. An export restriction, for example, could help one producer’s competitive position while hurting a manufacturer that relied on the restricted material.

The first requirement was a defensible company basket. Early versions admitted companies with weak connections to the theme and missed major producers. Reviewing those omissions led us back to search coverage, ranking cutoffs and listing mappings. Duplicate identifiers also needed to be resolved before we could attribute evidence consistently.

We used Bigdata’s Search API, Connected Entities and Co-mentions API to discover candidates, then checked their business exposure, listings and market eligibility. Co-mentions was particularly useful: exploring companies reported together around a topic gave us better leads than broad searches alone. I discovered it about six weeks in, which was excellent timing for my three-day project. It remains my contender for best thing since sliced bread.

Co-mentions supplied leads, not proof. Appearing alongside rare earths does not establish business exposure, and appearing alongside another company does not establish a supplier or customer relationship. Each candidate still needed evidence of why it belonged.

Making the evidence reliable

Quality control accounted for much of the development. We reviewed company attribution, statement classification, duplicate handling and scoring together, because errors in one stage could distort the next.

An event can legitimately belong to multiple statements. Earlier versions handled this poorly; allowing multiple memberships then required us to prevent repeated contributions from the same event. We also tightened classification around the extracted claim. An article discussing financing and mining does not make every financing event evidence of additional mining supply.

Relevance and company impact needed separate treatment. An event can be relevant to an adverse statement while contradicting it, or benefit a company within a negative-sounding narrative. We tested a separate stance layer for support and contradiction, then disabled that version after reviewing its results. It was an experiment, not part of the active scoring described here.

AI accelerated implementation, while manual inspection exposed errors that successful runs and valid JSON could not. I repeatedly reviewed charts and triplets, revised the process and checked the output again. Aakarsh’s reviews often found cases I had missed. “Nearly finished” became a phrase I used more carefully.

Repeated coverage needed particular care. One announcement could appear in several articles, match multiple queries and qualify for several statements. Without a stable event identity, those observations could look like independent developments.

We used exact hashing around the canonical company, predicate and atomic-event text. Date was excluded from that identity, so an identical triplet reported later did not become a new event. We retained later observations and source links separately from the event’s first contribution.

Figure 03 / Event identityIllustrative records

Repeated reporting adds evidence, not another identical event.

Canonical companyProducer A
Predicatebenefits from
Exact atomic-event textA customer signs a long-term purchase agreement.
identity = hash(company, predicate, exact event text)
  • Source ADay 1
  • Source BDay 2
  • Source CDay 4
1 event, 3 observations

Keep the first-seen contribution.
Retain each source as evidence.

What the hash does not solve

A paraphrase changes the exact event text and may produce a different identity. Recognizing that two differently worded records describe one real-world announcement requires semantic event resolution.

Date and publisher are not part of the exact event identity. The example assumes that all three sources yield the same company, predicate and event text.

Exact hashing made duplicate handling reproducible, but differently worded accounts of the same announcement could still produce separate identities. Resolving those cases requires semantic event matching; exact hashing alone does not solve it.

Freshness was classified separately as a new development, material update, historical background or uncertain evidence. A newly published article can contain an old event. We kept historical background in the research record without treating it as fresh impact, and preserved uncertainty rather than assigning false confidence.

Understanding an index move

Scoring separated the direction of company impact from its assessed economic strength, attention, source authority and freshness. This let us distinguish a material development from a recap, while using repeated coverage as information about attention without treating every report as a new event.

Attention considered document frequency, relative evidence density and publisher breadth. We also retained eligible documents that produced no triplets. Leaving those out would remove part of the denominator and distort the calculation. Reconstructing attention later made the importance of preserving that underlying document data especially clear.

The charts revealed another interpretation problem. In one audit, 53 of the 55 largest downward narrative moves were dominated by evidence leaving the rolling window. On 47 of those days, no new evidence arrived. A falling line could therefore reflect older supportive evidence expiring, even without a new adverse development.

Figure 04 / Rolling windowsConceptual illustration

A falling index does not always mean fresh bad news.

53 / 55

Largest downward narrative moves in the reviewed audit were dominated by rolling-window expiry. On 47 of those days, no new evidence arrived.

Dots illustrate event inclusion, not equal score weights or actual observations. Expiry can remove supportive contribution without introducing an adverse event.

We explained the rolling window, marked the warm-up period and let readers inspect the evidence contributing to a move. Those details belong in the interface: a user should not need to read the implementation to interpret a chart.

MP Materials’ Department of Defense deal illustrated the kind of exploration I wanted to enable. Readers could examine a substantial business development alongside market activity and open the reporting behind it. That connection helps investigate what happened; it does not establish that the index predicted the price move.

Building the research experience

The website connects basket and individual-company charts to an evidence table. Readers can click a day or drag across a period to inspect its developments, then explore the theme’s narratives and mechanisms through an expandable taxonomy.

Several visual treatments preceded the full-width table. Simplifying that view made room for the evidence and reduced the work required to reach it. The goal was a clear path from a company or period of interest to the underlying reporting.

We consolidated processing into a Python service with a pinned basket, taxonomy and configuration. The daily updater retrieves the requested date and uses checkpoints and exact deduplication to extend the dataset while preserving accepted historical scores.

For one catch-up, three days ran in parallel in isolated databases. A single process then merged them chronologically into the canonical dataset. We checked historical scores and event identities after merging, keeping parallel processing separate from updates to shared history.

Figure 05 / Catch-up executionThree isolated days

Process days in parallel. Commit them in order.

Day 1 workerIsolated database
Day 2 workerIsolated database
Day 3 workerIsolated database
One chronological merge processDay 1 → Day 2 → Day 3

Canonical dataset · historical score and identity checks

This was the one-time catch-up arrangement. Workers did not write concurrently into the canonical database.

Security, compliance and legal review also needed time in the plan. In financial services, “the code works” is an encouraging update, not a release checklist. We addressed authentication, workload limits, private versus public exports and source-preview restrictions. Docker packaging made the service easier for others to run and review. None of this was optional, regardless of my original estimate.

The verified October 14, 2026 snapshot contained more than 10,000 unique events across 16 companies and 11 narratives. The packaged service included a repeatable generation process and a daily updater, so another operator could continue the dataset without reconstructing my sequence of scripts.

Taking the process to more themes

I’m proud of taking an open-ended idea to a reproducible proof of concept, doing much of the build myself at 23. RavenPack’s team helped make it better by questioning the evidence and challenging the output. That scrutiny improved both the system and how I evaluated it.

This project taught me how much depends on choosing the right companies, retrieving the right reporting and checking what a score represents. Those decisions shape the research experience as much as the chart itself.

The ambition is to apply the process to more themes, potentially hundreds of trend experiences. Repeatable infrastructure helps, but each theme still needs a reviewed basket, a well-defined taxonomy and careful evidence inspection. Bigdata Trends gives investors a way to move between a broad theme and the specific developments affecting its companies.

Early-catalyst and forward-earnings research still interests me. For the next phase, my focus is on expanding theme coverage while preserving the quality controls established here. I will also be giving future time estimates a little more room.

Cheers to increasing shareholder value.

© 2026 Bigdata.com by RavenPack. All rights reserved.

© 2026 Bigdata.com by RavenPack. All rights reserved.