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.
"every signal has two dates and most tools show one" is the crisp version of this. the aggregator restamping is almost the lucky case, because it was visible. the deeper failure is that event-time and observation-time get collapsed at ingest, and once they are merged nothing downstream can tell them apart again. that distinction has to be preserved at the boundary or it is simply gone, and you find out months later from something that happened to be famous enough to check.
This is the kind of thing that sounds small until you trace what decisions got made on top of the wrong date. A stale timestamp is easy to dismiss as a display bug, but if it fed into any reporting or forecasting, it’s really a data quality issue wearing a UI costume. What tipped you off, did something downstream stop matching, or did someone just notice the number looked off?
There is a one-query version of this audit and it generalises past dates, so I will leave it here.
Count the rows where the two dates are equal to the second. Genuine same-second coincidence is rare at any volume. A fallback produces exact equality every time it fires, so that count is not a smell, it is the number of rows the fallback wrote. We found a whole class of borrowed-field bugs that way after finding the first one by hand, which is the wrong order and the expensive one.
The other thing I would add is that the two clocks want opposite defaults, and that is not obvious until it bites.
The error is asymmetric. A stale item shown as fresh costs you one wasted outreach. A fresh item shown as stale costs you the opportunity entirely, because nobody looks at it again. So when the event date is genuinely unknown, ranking and display want different treatments: rank it as if it were old, so it cannot crowd out something live, and show it as unknown, so a person can decide. We tried to pick one behaviour for both and it was wrong in one direction every time.
On the empty field borrowing, the fix that held for us was making the fallback impossible rather than correct. If the type is a date or null, something downstream will helpfully reach for another date and it will look right. If the type is a date or an explicit unknown value, the renderer has to handle unknown, and it breaks at compile time instead of in front of a customer.
Your line about each label stating what it is not is the part I had not thought of, and I am taking it.
The cheapest reliable test I have found is a first-seen registry: hash the entity plus event type plus amount, record the earliest timestamp any source published it, and treat every later hit as a mention rather than an event. On the investing side I do the manual version, when a round surfaces I check the SEC Form D filing date and the company's own announcement, and everything after that is echo. Your aggregator would have failed that check in one lookup, which is a good sign it can be automated.
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.