AAPL) closely, the problem is usually not lack of articles. The problem is that high volumes of coverage arrive as fragmented signals: product updates, supply-chain developments, legal actions, partner news, demand checks, pricing changes, follow-up reports, and generic commentary. It is often difficult to tell which stories are connected, which developments are genuinely new, and what broader company narrative is actually taking shape.
ViceWire exists to convert company coverage into structured, company-specific event data instead of leaving it trapped in headlines, broad sentiment, or ad hoc internal notes.
The current public examples in these docs focus on Apple, but the underlying model is designed for company-specific event extraction more broadly.
Why broad feeds are not the same as company event structure
Broad feeds answer distribution questions well: what was published, by whom, and when? ViceWire is trying to answer a different question: what company-specific event does this article actually describe, and what part of the company’s business is implicated by that event? That difference matters when similar article language points to different underlying states. A story mentioning a flagship product, for example, might be about a launch, a demand signal, a manufacturing issue, a legal action, or a pricing change. Those are not the same event type.Why event stage matters
The same company topic can appear at very different points in its lifecycle, and those points should not be treated as the same event: research shows that filings, formal procedural steps, settlements, and final decisions can carry different market meaning, while developments that are already public and repeatedly covered are more likely to be at least partly incorporated into prices unless a new step adds incremental information or resolves uncertainty. This taxonomy separates coverage by event family, stage status, subtype, and family-specific metadata so the output captures what has actually happened, not just the general topic being discussed. For example, stage changes the meaning of the event:- in
legal_regulatoryevents, where there is a real difference between a pre-case inquiry, an initiation, an active proceeding, a negotiated resolution, and a post-decision enforcement step - in
product_service_innovation, there is a difference between an emerging development signal, an official announcement, a rollout in progress, and a broadly effective or terminal state - in
partnerships_ecosystem, there is a difference between deal talks, a formal agreement, an integration in progress, and a relationship that is already live or has reached a terminal state
legal_regulatory events, procedural stage is distinct from whether the matter is about competition, privacy, consumer practices, employment, or another legal subject. In partnerships_ecosystem, lifecycle position is distinct from whether the relationship is about distribution, payments, content rights, or default placement.
This is why stage or status is a core part of the data model. It tells you where the event sits in its lifecycle, not just what broad category it belongs to.
Why manual review still leaves a schema problem
Analyst review can capture nuance. Internal notes can preserve context. Shared annotations can improve collaboration. But those workflows do not automatically create a stable event schema unless a team explicitly imposes one. ViceWire is meant to make that schema explicit so downstream users can ask the same question across articles and over time. Examples of those questions include:- Is this a formal case-opening step or a later legal development?
- Is this a rumor, an official announcement, or an already-live rollout?
- Is this a demand signal, a supply-chain event, or a commercial reset?
- Is this partner news about rights, distribution, payments, or default placement?
The model keeps family-specific metadata, not only labels
For each event family, anevent_family_metadata object captures the structured details that make the event usable beyond a high-level category. Instead of only saying what broad family an article belongs to, it preserves the specific facts that define what happened within that family.
That includes the event attributes that are materially relevant to interpretation, filtering, and downstream use. Depending on the family, this can include effective or announced dates, counterparties, obligations, remedy type, monetary amounts, scope, and event-linked geography when those details are explicitly supported by the source.