“New findings this week” sounds straightforward until someone asks when the underlying exposure happened. An indexing chart can answer when evidence entered a platform. It usually cannot establish when the original data was taken, when a password was last valid, or when unauthorized access occurred.
Those are separate events. Clear reporting gives each timestamp a name and preserves unknown dates as unknown.
Four dates that can describe one record
A capture or incident date refers to the underlying event. Establishing it may require reliable information from the affected service, device evidence, or another corroborated source.
A publication date describes when a particular dataset or post became available through a particular channel. That may be much later than the event and may describe a republication.
An indexing date describes when a platform incorporated the record into its searchable data. It belongs to the platform's processing history.
A report date describes when someone generated a summary. A report may use an earlier snapshot, so its generation date and the end of its data window can differ.
You may have only one or two of these dates. Filling the gaps with the timestamp that happens to be available produces a more confident story than the evidence supports.
Why established systems keep dates separate
This distinction is not unique to exposure monitoring. Have I Been Pwned's API model separates the reported breach date from the date a breach was added and warns that breach dates can be uncertain.
Likewise, Microsoft's Azure Monitor ingestion documentation distinguishes a source event's time, receipt at the collection endpoint, and availability after ingestion. These are examples of different clocks describing different stages; they do not imply that Vuxep uses either service.
When reading any security chart, ask which clock drives the horizontal axis. The answer determines which conclusions you can reasonably draw from a spike.
What first indexed means in Vuxep
Vuxep uses indexing context to show newly available evidence. Its reports explicitly describe indexing windows rather than breach windows. A record's first-indexed timestamp does not certify the original incident date.
Older collections can have incomplete processing history. Their available timestamp may have been retained from an earlier system or assigned during migration. Read it as the system's available indexing history; it cannot establish when a person lost control of an account.
Employee profiles and search evidence help reviewers inspect relevant records. They do not provide a complete timeline of every later sighting or a verified breach date for every source.
A fictional example
Suppose a file describing older account information is posted on Monday. The platform downloads it on Tuesday, finishes indexing distinct records on Wednesday, and includes those records in a later dashboard snapshot.
A report based on that snapshot can correctly call the records newly indexed on Wednesday. It cannot call Wednesday the breach date. Monday is a publication observation for that particular file, not necessarily the first time the information circulated.
If the file contains records already indexed from another collection, those duplicate observations should not automatically become additional newly indexed distinct findings. Raw input volume, duplicate observations, and new indexed records measure different things.
How to interpret a sudden increase
A visible increase may reflect new source coverage, a historical collection finishing processing, newly verified domain coverage, or a change in the selected reporting window. It can also include evidence relevant to recent events. The chart alone does not distinguish all those possibilities.
Start by checking the scope and the metric. Are you looking at records or unique accounts? Did the organization add a domain? Does the report warn that its snapshot is incomplete or older than expected? Are several hostnames part of the same underlying service?
Then inspect representative findings and available source context. This gives the increase an explanation before it becomes a claim in a management presentation.
Write dates that readers can trust
Use a sentence such as: “The platform first indexed these findings during the selected reporting window; the original exposure dates have not been established.” Add the snapshot date and verified-domain coverage when summarizing a dashboard.
Reserve terms such as “breached this week” for cases where reliable incident evidence actually supports them. Similarly, a quiet indexing week means few new findings entered the selected view. It does not establish that no exposure occurred during that period.
Consistency is more useful than apparent precision. A report with clear units, scope, and date definitions lets readers compare periods without mistaking collection activity for incident frequency.
For source interpretation, read stealer logs versus breach data. For a scoped review process, see checking company credential exposure.
Contact Vuxep to discuss exposure reporting for your verified domains.