The date on our data was lying to us, and it took a three-month-old funding round to notice
We monitor public buying signals for small B2B teams (hiring, funding, leadership moves) and rank accounts by how strong the evidence is.
Last month a funding round landed in our feed dated August. The round had been announced in May. Bloomberg and TechCrunch both covered it on the day. What we had picked up was an aggregator rewriting the story months later and stamping it with the date of the rewrite.
Our source check caught it before publication, so nothing shipped. But it sent me looking at the whole class of problem, and the general version is worse than the one case.
Every signal has two dates and most tools show one.
There is when the thing happened, and when your system first saw it. Both are legitimate. The first tells you whether a signal is still live, the second tells you your monitoring is alive at all. The trouble is that both get printed as a bare date with no label, so the reader supplies the meaning, and they always supply the first one.
We measured the gap in our own data. Around nine in ten job postings are already over a week old the moment monitoring first encounters them. More than four in five news items too.
That sounds like lag and it isn't. When you start watching a company you don't receive its next posting, you receive its current board, which is an accumulation. Some roles went up last week, others in spring. Any tool reading career pages inherits this. Having the backlog is fine. Displaying it as though it arrived this morning is not.
Two things I got wrong, in case they save someone time.
-
An empty field doesn't fail loudly, it borrows. When a system has nowhere to put the event date, the display quietly falls back to the date it does have, and produces a confident, precise, plausible answer. Nothing looks broken. The dates are well-formed. A months-old posting rendered with today's date raises no flag. It just reads as urgent. I now think date provenance is something you audit rather than assume, because the failure mode is not a gap in the UI. It's a number that looks like a fact.
-
My first instinct was to pick one clock and standardise on it. That would have been wrong. Freshness ranking needs the event date. The question of whether the watch is running needs the discovery date. Collapsing them fixes a display bug by deleting a real signal. The answer was boring. Keep both, label both, and make each label state what it is not.
The knock-on effects were bigger than the fix. Anything we publish now gets checked at its original source, which is why our funding roundup sometimes runs fewer companies than a rounder number would suggest. And published measurements are frozen at their measurement date. Re-running a query to "refresh" a figure quietly produces a third number matching neither the article nor the original finding.
Write-up with the full argument and a ten-minute test for your own feed. https://leadalise.com/blog/signal-date-vs-event-date
Here is the question I actually want answered. If you work from signals of any kind, sales, hiring, investing, competitive, how do you tell a fresh event from a fresh mention of an old event? Every answer I have is manual so far, and I suspect that's a limitation of my imagination rather than of the problem.
Payments taught us the same lesson from the other end. A commission rule says "converted within 30 days of the click", but the money event often arrives as a webhook days later, so every record carries two timestamps, and the rule must only ever read the event one. The habit that stuck after a few self-inflicted confusions: measure closed periods only, and stamp every report with when it was measured, not just what it covers. A number without its measurement time is your bare date in another costume: the reader supplies the missing meaning, and they supply the flattering one. "An empty field borrows" is going straight into our review vocabulary.
The "event date vs discovery date" distinction maps directly onto a problem we hit in almost every deployment that uses external signals as AI inputs.
The most painful version we've seen: a client's AI system was ranking leads based on "recent funding" as a buying signal. The funding was real. The "recent" was wrong — the discovery date was fresh, the event was eight months old. The leads it surfaced were companies that had already allocated that capital. By the time our client's sales team reached out, the budget conversation was closed.
Your "keep both, label both" conclusion is right, but the harder organizational problem is downstream of that. Even when both dates are available, the person reading the signal doesn't naturally adjust their urgency based on event age. The date feels like a freshness indicator regardless of the label. We ended up building a "signal age" field that calculated the gap explicitly — not just showing both dates, but surfacing the delta — because it turns out humans need the interpretation, not just the data.
To your actual question: the only non-manual method we've found that works consistently is cross-referencing the original source at query time rather than at ingestion time. Expensive, but it's the only way to catch the aggregator-rewriting-old-news problem you described.
This is the measurement boundary where systems fail silently. "Empty field borrows confidently" is the exact problem - when a system has nowhere to put what it actually measured, it displays what it can measure, and the reader fills in their own story. Months-old posting rendered with today's date raises zero flag because the format is perfect.
The key insight is that your solution (keep both, label both, make each label state what it is not) doesn't solve the display problem - it solves the decision problem. A human reading "event date: May" and "discovery date: August" has complete information and can make a choice. A system reading the same can rank differently. That's the invisible transformation.
The harder version of your question: if you do tell both dates, founders start gaming one or the other. "Should I report my hiring date or when the job got announced?" If discovery date becomes visible, everyone optimizes to appear fresher. How do you measure through a system where all the signals know you're watching?
The two-date distinction feels like the important insight here.
Curious whether the harder problem is actually detecting the event date reliably, or deciding when an old event is still commercially relevant enough to surface again.