> ## Documentation Index > Fetch the complete documentation index at: https://docs.bigdata.com/llms.txt > Use this file to discover all available pages before exploring further. # Inside Monitors: how a monitor decides what's new > A monitor reads the news for you and speaks up only when something changed. Here is how it works, step by step, and why we built each step the way we did. November 13, 2026 Engineering, Monitors, Search / 15 minutes read Ask a search engine a question and you get an answer for this moment. Ask it again tomorrow and you get today's answer, mixed with yesterday's, in a different order. That's fine for research. It's useless as an alert. A monitor is a question you ask once. "Tell me if Nvidia replaces its CEO." "Alert me on deals over a billion dollars." "Tell me when a listed company discloses a cyberattack." On a schedule, it searches what was published since it last looked, reads it, and tells you only what is new. The hard word is *new*. News doesn't arrive once. A CFO appointment comes as a press release, a regulatory filing, a dozen rewrites, a line on an earnings call and a profile two days later. A merger is rumored, announced, reviewed by regulators and closed, and every step is retold in articles that recap the steps before. A monitor that alerts on every new document is a firehose. One that alerts on every new link is the same firehose with fewer exact copies. What you want is one alert per event, and one more each time the event moves. Take the biggest business story of early November. From 8 November, Nvidia's board opened an investigation into its chief executive, the FBI was reported to be looking into it, shareholders sued, and [the board was reported to be meeting about his future](https://fortune.com/2026/11/11/nvidia-oust-jensen-huang-spy-affairs/). We replayed a monitor asked "Tell me if Nvidia replaces its CEO" hour by hour, from midday on 9 November until just after the news on the 12th. For 58 hourly runs it read about 21,000 passages on the investigation, the FBI and the lawsuits, and sent nothing: none of it was the change it was asked about. Late on 11 November, when reports citing The Wall Street Journal said Nvidia was moving to oust Huang, it sent its first alert. Before dawn, as more headlines said he was out, it sent an update. Then, at 13:48 UTC on 12 November, [Nvidia announced](https://www.globenewswire.com/news-release/2026/11/12/3401635/0/en/nvidia-announces-ceo-transition.html) that Huang had resigned and that Colette Kress, its finance chief, was interim CEO. By 14:00, 59 documents from 40 sources had covered it, from newswires and from outlets in Seoul, Taipei, Mumbai, Oslo and Paris, and that hour's run read them all as the same event moving on: Kress in, Huang out, effective. That update is the one that mattered. ![A timeline of 8 to 12 November. The news lane shows the board's investigation, the FBI inquiry and first lawsuit, the board meeting about his future and the announcement at 13:48 UTC on 12 November. The monitor, replayed hour by hour, stays quiet for 58 runs, sends an alert late on 11 November, an update before dawn, and an update at the announcement: effective, Kress in, Huang out, from 59 documents and 40 sources.](https://mintcdn.com/ravenpackinternational/YkNz6O9O7Xkvu3SX/images/blog/inside-monitors/nvidia-quiet-then-one-alert.png?fit=max\&auto=format\&n=YkNz6O9O7Xkvu3SX\&q=85\&s=12b37f36930687810fb10b4fe9a43f9b) Quiet through days of coverage, an alert when reports said Nvidia was moving to oust Huang, an update as more headlines followed, and the update that mattered at 13:48 UTC on 12 November. > [!NOTE] > > How we ran it: we created the monitor through the Monitors API, with that sentence as its question, set it to run every hour, and replayed it from 12:00 UTC on 9 November to 14:00 UTC on 12 November with the simulate endpoint (`POST /v1/search-monitoring/monitors/{monitor_id}/simulate`, with a start and an end time). ![The alert in the Bigdata.com app: Nvidia CEO change, Colette Kress as incoming CEO, status effective, from 624 documents.](https://mintcdn.com/ravenpackinternational/YkNz6O9O7Xkvu3SX/images/blog/inside-monitors/alert-card.png?fit=max\&auto=format\&n=YkNz6O9O7Xkvu3SX\&q=85\&s=7541124b099fcfce5167cc5f48dc89ae) The alert as it arrived on 13 November, from a monitor following the same change: one event from 624 documents and 163 sources, with Colette Kress resolved to her entry in RavenPack's knowledge graph. How does a monitor on Bigdata.com stay quiet through days of coverage, speak up when the story moves, and turn hundreds of documents into a single alert each time? The short version: language models do the reading, and the decision about what's new rests heavily on code. ## Four words, one meaning each * **Document:** one news article, regulatory filing or call transcript, stamped with the moment it was published. * **Report:** what one document says about one thing that happened, written into the monitor's form. One document can hold several reports. * **Event:** the thing that happened, built from all its reports. AutoZone's CFO resigning is one event, however many documents tell it. A central bank's decision at its next meeting is a new event, even when the decision repeats. * **Alert:** what you receive. A new event alerts, and so does a known event that moved: a new status, a new person, a figure that changed. An event with nothing new stays quiet: the monitor keeps it, but doesn't send it. In the Nvidia story, 59 documents covered the change in the hour it was announced. Each carried a report, and together they moved one event and sent one alert. ![59 documents become 59 reports, which fold into one event, Nvidia with Kress in and Huang out, and one alert.](https://mintcdn.com/ravenpackinternational/YkNz6O9O7Xkvu3SX/images/blog/inside-monitors/four-words.png?fit=max\&auto=format\&n=YkNz6O9O7Xkvu3SX\&q=85\&s=1412d68ce9f0a867a761030f9dfbaeb2) Four words, one meaning each. In the Nvidia story, 59 documents carried 59 reports, which moved one event and sent one alert. ## Three questions in every run For every document it reads, a monitor has to answer three questions, and get all three right. 1. **Is this the event I was asked about?** The new head of a company's health unit is not the company's CEO. 2. **Who is it about?** "Apple" in a story about orchards is not the company. Fidelity National Information Services and FIS are the same company. 3. **Have I already told you?** The fortieth report of one appointment is not news. The report that says a deal has closed is. It's tempting to ask a model all three at once. It's also slow, expensive and inconsistent. Ask a model "is this new?" twice and it can answer differently, and to answer at all it has to reread everything the monitor has already seen, a bill that grows every day. So we split the work. Language models do what they are good at: reading documents and filling in a form. The decision about what is new rests heavily on code, which gives the same answer to the same input, can say exactly why it alerted, and never has to reread its history. ## What a monitor is made of You describe a monitor in one sentence, in the Bigdata.com app or in the AI assistant you already use. A language model drafts its design, which is checked before it's saved. * **An event definition.** What counts and what doesn't, in a few lines. It becomes the reader's whole brief, so the reader never has to guess what you meant. For "Tell me if Nvidia replaces its CEO", it covers the chief executive leaving or being replaced, from the announcement to the new chief executive taking over, and says that a confirmation that the current one stays is not the change. * **Fields.** What the reader fills in for every report, such as the company, the role, who leaves, who comes, the status and the date it takes effect. * **Search texts**, and optionally a **watchlist**: up to 500 companies, people or places. * **A schedule**: every few hours, or at exact times in your time zone. Thresholds and tolerances, such as how far a number must move to count as a change or how far apart two dates can be and still describe one event, are set from each field's type, so they stay the same from one design to the next. Your sentence is stored as you wrote it, and when you edit a monitor, only what you name changes. You can make an edit in a sentence, such as "only deals over \$1 billion". Here is one alert from a monitor on CEO and CFO changes at S\&P 500 companies, with the index as its watchlist. | Field | In the alert | | - | - | | Company | AutoZone | | Role | CFO | | Outgoing executive | Jamere Jackson | | Incoming executive | J. Scott Murphy, as principal financial officer | | Status | Announced | | Summary | AutoZone said CFO Jamere Jackson will resign to become CFO at FedEx | | Sources | The documents it came from, one click away | A second change in the same role weeks later is a new event, told apart by its date. ## The architecture ![The monitor's architecture. Your question and a one-time design drive every run. Each run searches, groups, reads, normalizes, resolves names, gates, consolidates, checks novelty and delivers, with licensed content, the knowledge graph and the event history as stores.](https://mintcdn.com/ravenpackinternational/YkNz6O9O7Xkvu3SX/images/blog/inside-monitors/architecture.png?fit=max\&auto=format\&n=YkNz6O9O7Xkvu3SX\&q=85\&s=6419d40cb66d5c3b2c7c6f3911e8ec45) One monitor, from your question to an alert. Jump to a step: [1. Search](#1-search-a-window-in-time) · [2. Group and read](#2-group-and-read) · [3. Normalize](#3-normalize-dates-and-numbers) · [4. Resolve names](#4-resolve-names-to-entities) · [5. Gate](#5-gate-junk-never-alerts) · [6. Consolidate](#6-consolidate-many-reports-one-event) · [7. Novelty](#7-novelty-new-update-or-quiet) · [8. Deliver](#8-deliver). The design step is described under [What a monitor is made of](#what-a-monitor-is-made-of). Each step ends with a link back here. Language models read the documents and draft each monitor's design, and they help in other steps where reading is needed. The decision about what is new rests heavily on code, so the same reports get the same verdict. ## 1. Search: a window in time Every run covers a window, from the last run to now. The monitor's search texts run against licensed news, filings and transcripts, each stamped with the moment it was published. The oldest documents go back to 2000, and how far back each kind goes varies. A watchlist filters at search time, so a monitor on 500 companies reads about those 500 companies, not the whole market. Point in time matters twice. Every document carries two times: when it was published, and when it reached our index, seconds to an hour later. Live, each run reads what reached the index since the last run, so a story that lands late still counts. A replay works the same way: each window sees only what had reached the index by then, and runs every step a live run does, so you can try a monitor on past news before you turn it on. [↑ Back to the architecture](#the-architecture) ## 2. Group and read Documents about the same companies are read together, so one deal's coverage reaches the reader at once and unrelated stories don't crowd it. On busy days in our tests, reading documents grouped by the pair of companies they are about found about twice as many distinct events as reading them in fixed-size bundles. A language model reads each document and fills in the monitor's form once for every thing that happened in it. Each field takes one kind of answer: a date, a number with its unit, a name, or a stage from a fixed list. A field the document doesn't state stays empty; it is never guessed. Every report cites the passages it came from, and a report with no source is dropped before it can alert. When a document is unclear, the reader is told to leave it out: we would rather miss a report than send a false alert. [↑ Back to the architecture](#the-architecture) ## 3. Normalize dates and numbers Dates like "last Tuesday", "with immediate effect" and "in the fourth quarter" can't be compared as written. So every date becomes a calendar day or a period, read in the document's own time: a year-less "September 30" in a document from October means this year, not next. The reader also marks each date as past or future from the sentence's own words, so "left in January", read in October, is last January, and "starts in January" is next. In a test of 33 relative and weekday dates, all 33 landed on the right day. An event with no date of its own takes the document's date only when the headline states it. A profile published in November may open with a retirement in 2014, and being near the top of the document doesn't make it today's news. Every number keeps the value, unit and scale the source stated, so "$22 billion" and "$22bn" are the same value, and a headcount isn't compared with a percentage. [↑ Back to the architecture](#the-architecture) ## 4. Resolve names to entities An event is only as good as its *who*. Monitors resolve the names in a report's fields to entities in RavenPack's knowledge graph of companies, people, places and products, the same graph that tags every document in our index. A name is matched in several ways: the entity tags already on the document, a lookup of the name in its context, and the monitor's own watchlist. When a name could be several entities, or none, a decision step weighs the candidates of the kind the field allows and picks one, or says it is none of them. On ten test monitors, that step cut the cases of two different names wrongly treated as one from 108 to 3. A name nobody knows yet, such as a new start-up, a product or a hacker group, gets an entry of its own that stays the same from run to run, so it can still be followed and still alerts once. We collect those names, and the names the graph files in the wrong place, as requests for the team that maintains it: add this company, merge these two entries, give this person a description. Once a fix is in the graph, every product that reads it knows. [↑ Back to the architecture](#the-architecture) ## 5. Gate: junk never alerts Before anything is compared, the monitor drops what can't be trusted: a report with no usable date, a report that doesn't say who it is about, a report older than the monitor's age limit or, for a watchlist, a report that doesn't name a watched entity in a field that matters. We accept the trade. Once in a while a real event is lost, and junk never reaches you. [↑ Back to the architecture](#the-architecture) ## 6. Consolidate: many reports, one event Documents are read in parallel batches. Grouping them by the companies they're about ([step 2](#2-group-and-read)) means most of an event's coverage is read together, but a big story can fill several batches, so one event can still come out as several reports. Before anything is judged, they are folded into one event: grouped by what they are about, ordered by publication time and merged while they describe the same event. A stated value beats an empty one. A later value replaces an earlier one only when the field's own comparison calls it a change. Every distinct value and every source is kept, in the order they were published. When Keysight named its next CFO on 2 November, the news arrived in eight stories and the company's 8-K filing within about an hour of the market close. One headline gave the start date and the CFO he succeeds; the others gave less. The monitor sent one alert that carried every detail, with all nine documents under it. ![Nine documents about Keysight's new CFO, the 8-K, one headline with the start date and his predecessor and seven stories with less, fold into one event with every detail, and one alert.](https://mintcdn.com/ravenpackinternational/YkNz6O9O7Xkvu3SX/images/blog/inside-monitors/keysight-one-alert.png?fit=max\&auto=format\&n=YkNz6O9O7Xkvu3SX\&q=85\&s=ae2d596c25f8ea42c0ce5c7a9861e78c) Nine documents within about an hour, each with part of the story. They fold into one event that carries every detail, and one alert goes out. [↑ Back to the architecture](#the-architecture) ## 7. Novelty: new, update or quiet Now the monitor compares each event with its history. Every event the monitor has seen is tracked with its latest values and when it was last seen. The same company can have many events over time: one per meeting, one per quarter's guidance, one per appointment. * A new event is **NEW**, and it alerts. * A known event that moved is an **UPDATE**, and it alerts: a new status, a different person, a number that moved by more than its tolerance. * A known event with nothing new stays **quiet**. ![An event from this run is compared with its history. Never seen: NEW, it alerts. Seen, and a field moved: UPDATE, it alerts. Seen, and nothing moved: quiet, kept but not sent.](https://mintcdn.com/ravenpackinternational/YkNz6O9O7Xkvu3SX/images/blog/inside-monitors/novelty-verdicts.png?fit=max\&auto=format\&n=YkNz6O9O7Xkvu3SX\&q=85\&s=b14e1f3b7fa330254d16dc661b7db48d) Every event is compared with what the monitor already knows. Only NEW and UPDATE go out; the rest is kept, and stays quiet. Some fields carry rules of their own. Ordered stages only move forward: a deal goes from announced to under review to closed, and a report recalling that it was "rumored in January" can't drag it back. Endings such as rejected or withdrawn close an event. Dates match within a day, so news stamped late in New York and early in Sydney is one event. A value the event stated recently is no change, so a deal reported at $22 billion, then $20 billion, then \$22 billion again alerts twice, not three times. A figure for an older period, reported after a newer one, is old news. ![A deal's stages: rumored, announced, under review, closed. Each new stage is an update and alerts. A later report recalling a January rumor can't move the deal back. Rejected or withdrawn close the event at any stage.](https://mintcdn.com/ravenpackinternational/YkNz6O9O7Xkvu3SX/images/blog/inside-monitors/stages-move-forward.png?fit=max\&auto=format\&n=YkNz6O9O7Xkvu3SX\&q=85\&s=32f81e3370a02bcd9d75d8ac4a588e20) Stages only move forward. Each new stage alerts as an update; a later recap of an old rumor can't move the deal back. A repeat isn't always old news. When a central bank holds its rate at one meeting and again at the next, every value matches, but the decision is new. So a report joins the latest event only when it covers the same reporting period, names the same person, comes while the status is still under way, or carries dates close to the event's own. A report with its own, later date starts a new event and alerts as NEW, even when every value repeats. A recap dated only by when it was published stays quiet. In a replay of a rate-decision monitor over 90 runs, this found 37 alerts that comparing values alone would have missed, 36 of them right, and lost none. The monitor behind the AutoZone alert above sent one more alert the next day, when reports gave the date the CFO leaves: 25 November. One event, two alerts. The same week, six more documents reported on HP's new CEO after her appointment, some adding her pay and two new board seats. None of that changed who leads HP or when, so the monitor stayed quiet. Because the verdict rests on rules, the same reports get the same verdict, and every alert can say which field changed. Because history is kept per tracked event instead of being reread, a run costs the same on day 300 as on day one. An event's history is kept while it's in the news: one nobody mentions for 90 days starts afresh. Figures for a dated period, such as a fiscal year's guidance, are kept for good, so the same figure repeated months later is still known. [↑ Back to the architecture](#the-architecture) ## 8. Deliver Alerts go out by email, through the API, in the Bigdata.com app and to the AI assistants that connect to Bigdata.com. Every alert carries its fields and links to its sources. In a replay, the quiet events are there too, marked as already known, so you can see what the monitor held back. [↑ Back to the architecture](#the-architecture) ## The choices, in one table | We chose | Instead of | Because | | - | - | - | | What's new decided mostly by rules | Asking a model "is this new?" | The same input gets the same answer, every verdict says which field changed, and no run rereads its history | | One event from all its reports | One alert per new document or link | Forty documents, one appointment: one alert | | Rules for each field | Text similarity | A deal's closing alerts; a recap of its rumors doesn't | | Events told apart by their dates | Treating a repeated value as old news | The next meeting's rate hold alerts; the fifth recap of the last one doesn't | | Names resolved to entities | Matching strings | FIS is Fidelity National Information Services, and a watchlist means the company, not the word | | Each company as the story names it | Rolling every company up to its top parent | In a test on real alerts, one in six of those merges joined two different events | | Point-in-time search | Searching today's index for the past | A replay reads only what had reached the index by each moment | | Junk dropped before it's compared | Alerting and leaving the filtering to you | A rare miss costs less trust than a false alert | | Thresholds set from each field's type | Letting each design pick its own | Designs stay repeatable and safe to edit | Back to Nvidia. For days the monitor read about an investigation, the FBI and lawsuits, and said nothing. It spoke when reports said Nvidia was moving to oust Huang, again as more headlines followed, and once more when the change was official, the alert that mattered. Hundreds of documents told each step; a language model read every one of them, and the event's history decided which ones were news. ## Try it before you trust it * **Preview.** Describe a monitor and see sample events from one recent window in seconds. Nothing is saved to its history. * **Replay.** Run the monitor over a past period through the whole pipeline. A replay first reads the week before its first window in silence, so its first alert is news, not a backlog. * **Activate.** The first live run does the same silent read, so you aren't flooded with last week's news. A paused monitor, turned back on, reads what it missed the same way, in silence, and alerts on what comes next. * **Schedule.** A weekday schedule's Monday run covers the weekend in one email, not three. Monitors are in the [Bigdata.com app](https://app.bigdata.com), in the API and in the AI assistants that connect to Bigdata.com. Start with [Get started with Monitors](https://docs.bigdata.com/getting-started/monitors/overview.md) or the [Monitors API reference](https://docs.bigdata.com/api-reference/monitors/create-a-monitor.md). Or, if your AI assistant is [connected to Bigdata.com](https://docs.bigdata.com/mcp-reference/introduction.md), just ask it to create a monitor for you. *** ![János Juhász](https://mintcdn.com/ravenpackinternational/YkNz6O9O7Xkvu3SX/images/blog/authors/janos_juhasz.png?fit=max\&auto=format\&n=YkNz6O9O7Xkvu3SX\&q=85\&s=5cba290ec2533db98d3ec073ec27712e) János JuhászHead of Engineering, Search (VP) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.