Skip to main content
affected_business_surface maps an event to the company-specific product, service, platform, operating practice, or company surface most directly implicated by that event. It does not just say what kind of event occurred. It also asks where in the company that event lands. This taxonomy answers two core questions:

What is affected?

What part of the company is affected or could be affected?

How much is involved?

Does the article give a number for how much of that part of the company is involved?

​
Why this layer exists

Megacaps like Apple should not always be treated as one undifferentiated entity. Two events may belong to the same event family but land on very different parts of the business. A partnership event might relate to apple_tv_plus if it concerns content rights, while another partnership event might relate to wallet_payments_and_cash if it concerns payments enablement. A legal event might land on privacy_and_data_practices, while another legal event might land on app_store_and_app_distribution. Without this layer, those events would all be grouped at the company level even though they implicate different Apple surfaces.

​
What the Affected Business Surface Taxonomy Covers

The company-specific affected-business-surface taxonomy is global across the event model. Using Apple as an example, it includes normalized surfaces across areas such as:
  • devices and hardware
  • software and platforms
  • media and subscription services
  • commerce, payments, and customer practices
The goal is not to predict ultimate business impact with certainty. The goal is to preserve the most directly implicated Apple surface supported by the article. For each event identified in the article, we ask the question: “What part of Apple is impacted, at risk, or materially implicated?”
For each event object, we collect affected_business_surface metrics.

​
Primary and secondary relevance

Each selected surface can carry a relevance label.
​
primary
primary means the surface is the main locus of impact in the event.
​
secondary
secondary means the surface is also materially implicated, but is not the central surface.
This matters because some events clearly center on one company surface while still touching another.

​
Example Usage

In January 2026, Apple agreed to pay a $150,000 fine in New Jersey for failing to clearly display merchandise prices and refund policies. In this example, the event is classified as affecting retail_and_direct_sales because the violations were found across Apple’s physical store footprint in the state and required changes to store training, audits, and in-store pricing display. It is also classified as affecting pricing_billing_and_subscription_practices because the underlying issue still centers on pricing transparency and customer-facing commercial practice. As shown here, in some cases, the payload can also carry a structured counts object when the article explicitly ties a number to the selected surface. This is one way the payload can quantify scope when the article states a number tied to the affected surface.
Example Payload: Affected Business Surface
{
  "affected_business_surface": [
    {
      "surface_relevance": "primary",
      "category": "retail_and_direct_sales",
      "counts": {
	      "count_value": 11,
	      "value_type": "count",
	      "count_entity_type": "store_or_retail",
	      "operator": "exact"
	    }
	},
    {
      "surface_relevance": "secondary",
      "category": "pricing_billing_and_subscription_practices",
      "counts": null
    }
  ]
}

Example Payload: Legal Event

See the full New Jersey Payload Example

​
Why this helps workflow relevance

This layer makes the output easier to use in downstream workflows because users can filter events by the part of Apple they actually care about, or that are most likely to impact earnings reports. That is useful when the question is not just “did Apple have a legal event?” but “did an Apple legal event land on App Store economics, retail practices, Siri, or Mac production?” It also makes it easier to connect events to the business areas that may matter for revenue, costs, operations, or segment-level performance without claiming that the mapping is itself a full causal model.

​
Why it matters in multi-event articles

This layer is especially useful when one article produces multiple event objects. In a multi-event article, different event objects can point to different Apple surfaces. For example, Apple’s dispute with Epic over external purchase fees can be represented as more than one event from the same article. One event is a legal and procedural development, where Apple asks the Supreme Court to revisit the fee and injunction dispute; that would map to the legal_regulatory family and land on app_store_and_app_distribution. A second event is a commercial-practices and monetization development, because the article also centers on Apple’s ability to keep charging fees on purchases made outside the App Store; that could map to the platform_app_store_ecosystem family and land on pricing_billing_and_subscription_practices. The same article therefore contains two distinct developments: one about the legal status of the dispute, and one about the business practice and revenue mechanism at issue. That means the model preserves not only that multiple events are present, but also that they land on different parts of Apple.

​
The core idea

affected_business_surface is not a replacement for event family, subtype, or stage status. It is an additional company-specific layer that says where the event is most directly landing inside the company. That is what makes the output more useful than treating a company as a single undifferentiated entity.