Most monitoring tools work the same way: find a keyword, send a notification. You get pinged when the term appears — whether that's a significant development or the fifth article saying the same thing.
Pingmer works differently. The goal isn't to tell you a story was mentioned. It's to tell you something meaningful changed. That requires the system to understand story evidence, not just match text.
Here's how that works.
The Problem with Keyword Mentions
Imagine you're tracking a court case. Over the course of a year, hundreds of articles might reference the defendant's name. Most of them are:
- Recaps of things already reported
- Background context in unrelated articles
- Opinion pieces with no new facts
A keyword-based tool sends you something for all of those. You train yourself to ignore most of what arrives. Eventually you stop opening the notifications at all.
The signal drowns in noise.
Pingmer's fact-shift detection is built around a different question: did the underlying facts of the story actually change? A new arrest, a ruling, a correction, a scheduled hearing — these shift what we know. Rewording old information doesn't.
Three Layers: Source, Observation, Event
To answer that question reliably, Pingmer separates story knowledge into three distinct layers.
Source documents are the raw evidence. When Pingmer scans a thread, it saves records of every source it analyzed — which URL, what was fetched, when it was published, and how much content was actually available. This creates a durable provenance record. The system knows exactly what it looked at, not just what it concluded.
Observations are what the system extracted from that evidence. A source document might be a news article about a trial. The observation derived from it is structured: a court ruling happened, on a specific date, with a specific outcome. That's different from storing the article text. It's normalized story knowledge — the kind of information you can compare across time.
Events are what you see on your timeline. When something genuinely new appears in the observations layer — a fact that wasn't there before — Pingmer creates a timeline event and, if you have notifications on, pings you.
The chain is: source → observation → event.
This separation is what makes the system more reliable than keyword matching. The decision to ping you isn't "this keyword appeared." It's "this story now contains a fact it didn't contain before."
What Gets Stored as Evidence
Every time Pingmer scans a story you're tracking, it logs what it analyzed:
- The URL of each source, along with its canonical form
- Whether the content was fully fetched, partially fetched, or only available as a search snippet
- When the source was published (not when Pingmer found it — when the underlying article was written)
- Structured metadata from the content
This matters for a few reasons. It means Pingmer can filter out sources it already processed — so a reshared article from six months ago doesn't look like new evidence. It means the system knows whether it was working with full text or just a headline. And it means developments can be traced back to the specific source that produced them.
Before this system existed, Pingmer stored source URLs embedded inside timeline events. That worked for displaying timelines, but it made it hard to reason about where conclusions came from or reprocess evidence with improved methods. The dedicated evidence layer fixes that.
Comparing Detectors
Pingmer currently uses two approaches to decide whether a story has a new development.
The primary approach, fact-shift detection, has been running in production for some time. It takes search results from a scheduled scan and asks: does this represent a meaningful change in the story's known state?
The newer approach, observation-based detection, runs a separate analysis pass on the same search evidence. It extracts structured story knowledge — the kind of information that can be compared precisely against what the system already knows. If a candidate development is genuinely novel, it gets persisted.
The two systems currently run in parallel on a sample of scans. Pingmer compares their conclusions — where they agree, where they differ, and what kinds of stories or categories surface disagreements. This evaluation process guides how the system evolves.
This doesn't change anything you see today. Your timeline and notifications still work the same way. But it's the infrastructure that makes higher-confidence, lower-noise notifications possible over time.
Why This Matters for Reliability
The practical effect of this architecture is that Pingmer can answer questions keyword-based tools cannot.
Did Pingmer scan this story today and find nothing new? That's a documented non-event, not a gap. The scan happened, it looked at recent sources, and nothing crossed the threshold for a meaningful development.
Did an event get created from this specific article? Yes — and the system can trace which source led to which extracted knowledge, which led to which timeline entry.
Was this source already analyzed in a previous scan? Yes — which is why it didn't produce a duplicate event.
That kind of traceability is what separates a story-tracking system from a keyword alert. You're not just getting a list of links. You're getting a maintained record of story state, updated over time as facts shift.
What You See vs. What the System Tracks
What you see in Pingmer is unchanged: the timeline on each thread, the events and their sources, the notifications when something shifts. Those are the public-facing layer.
The evidence and observation layers operate underneath. They're how Pingmer decides what makes it to your timeline in the first place.
The result: fewer pings on content that doesn't matter. Clearer timelines with meaningful developments. And when something does change in a story you're following, a higher-confidence notification that something genuinely shifted — not just that the keyword appeared again.
For a broader look at how story tracking differs from keyword monitoring, see what story tracking is and why it works differently. If you're currently using Google Alerts and wondering why it keeps missing things, the comparison with Pingmer covers the architectural gap directly.
Frequently Asked Questions
How does Pingmer avoid sending duplicate notifications?
Pingmer maintains a record of every source it has analyzed for a given story. When a new scan runs, already-processed sources are filtered out before any analysis happens. On top of that, the observation layer compares new extractions against what the system already knows — so if an article reframes old information without adding new facts, it doesn't produce a timeline event.
Does Pingmer scan every story at the same frequency?
No. Pingmer uses adaptive scanning — stories with recent activity get checked more often (as frequently as hourly), while quieter stories are checked less often (up to every few days). This keeps scanning resources focused on threads where something is actually happening.
What types of developments does Pingmer detect?
The observation layer is structured to capture specific story-state changes: rulings, arrests, filings, corrections, scheduled events, leadership changes, and similar concrete developments. It's designed to distinguish "new fact" from "new article about the same facts."
Can I see why a specific event was added to my timeline?
Each timeline event on Pingmer links to the source that produced it. The underlying evidence layer tracks which sources were analyzed and when — the timeline entry is the user-facing surface of that process.