Threat Events.
A Threat Event is the real-world occurrence that reporting describes: a specific breach, a specific exploitation campaign, a specific leak. It is the layer above the Event, which is one report and nothing more.
The distinction matters because reporting repeats itself. A single breach might be covered by a vendor write-up, three news articles, and a post on a leak site. Under a report-per-item model you get six near-identical entries and have to work out for yourself that they are the same story. Liberty91 matches them into one Threat Event with all six reports attached, so you read the occurrence once and can see at a glance who is reporting it, whether they agree, and how much weight the reporting deserves.
How reports are matched
When a report arrives, the platform shortlists Threat Events it might belong to, looking within a two-week window and scoring candidates on how much their text and their extracted entities overlap with the new report. The AI pipeline then makes the decision: this report belongs to one of these Threat Events, or it describes something new and a Threat Event is created for it.
Analysts are not locked out of this. You can link a report to a different Threat Event, unlink one that was matched wrongly, merge two Threat Events that turn out to be the same occurrence, or split one that turns out not to be.
Sources, and whether they agree
A Threat Event holds every report matched to it, and each report carries a stance: what that source is actually doing with respect to the occurrence.
| Stance | What it means |
|---|---|
| Claims | Asserts the occurrence, including the first report of something new |
| Corroborates | Independently supports an occurrence already asserted elsewhere |
| Updates | Adds new developments to a known occurrence |
| Mentions | References the occurrence in passing |
| Disputes | Contests that the occurrence happened as described |
This is the part that is hard to get from a feed. Disagreement between sources stays visible rather than being averaged away, and a story carried by one outlet reads differently from one carried by four independent ones.
Once at least two genuinely independent sources report an occurrence, the Threat Event is marked as corroborated. Independence is assessed deliberately: several outlets running the same wire copy are collapsed together rather than counted as separate confirmation, which stops circular reporting from manufacturing false confidence.
How reliable is it
Two separate judgements combine here, and it is worth keeping them apart. Both come from the Admiralty scale.
Source reliability is a property of the source, rated A to F. A government CERT and an anonymous forum post do not carry the same weight, and that assessment belongs to the source rather than to any one story it runs.
Credibility is a property of the Threat Event, rated 1 to 6, and it is computed across everything reported about it. More reliable sources push it up, as does corroboration. A reliable source disputing the account pushes it down. Credibility therefore moves as the reporting develops, which is what you want from an assessment of something still unfolding.
What you see, and what you do not
Threat Events are a shared layer. Licensed and private sources contribute to them, which is much of what makes them worth reading: your licensed vendor reporting and the reports you upload yourself sit alongside public reporting on the same occurrence.
You only ever see the sources you are entitled to. This is a hard boundary, not a display preference.
| Situation | What you see |
|---|---|
| You are entitled to none of its sources | Nothing. The Threat Event does not appear in your lists, searches, analytics, or exports. It is absent, not redacted. |
| A public source also reports it | The Threat Event, under the public title. Any source you are not entitled to is masked out, including from the report and source counts. |
| Only your own private reporting covers it | The Threat Event, titled from your own report. |
| Only another customer's private reporting covers it | Nothing, as above. Their reporting is never surfaced to you or attributed to them. |
| It has no public title yet | A neutral title derived from the event taxonomy, rather than anyone's private headline. |
Two customers whose private reporting lands on the same occurrence each see it titled from their own report, with their own sources attached. Neither learns that the other is there.
There is a further layer beneath the visibility rules. Private and uploaded reports can join a Threat Event, but they never write to the shared record itself. The victims, the technologies, the dates, the derived entities, the credibility, and the corroboration state are all computed from public reporting only. Contributing your own reporting therefore never leaks it, not even indirectly through the conclusions drawn from it.
Which sources create Threat Events
Genuine reporting sources create and contribute to Threat Events. Enrichment and outbound integrations do not, because they are not reporting on an occurrence: attack-surface tools and IOC-enrichment services add context to what you already have, and production integrations such as Slack, Miro, and webhooks send your finished work outward. See How Modules work.
Frequently asked questions
What is a Threat Event?
The real-world occurrence that one or more reports describe, such as a specific breach. Every report covering that occurrence is matched into the same Threat Event, so you read the occurrence once instead of once per report.
How does Liberty91 know two reports describe the same thing?
The platform shortlists candidate Threat Events within a two-week window using text and entity overlap, then the AI pipeline decides which candidate the report belongs to, or that it describes something new.
Can other customers see my private sources?
No. You only ever see the sources you are entitled to. A private report is masked out of a Threat Event for anyone without that entitlement, and it never contributes to the shared record.