foundedYear Is the Wrong Field for Company Data

corpdigest — Wed, 05 Aug 2026 18:48:46 +0000

Almost every company dataset stores founding as a single integer. It is the first field you add and the first one that turns out to be a lie.

Take Visa Inc. What year was it founded?

1958, when Bank of America launched the BankAmericard programme
The early 1970s, when the programme was reorganised into a member-owned network under Dee Hock
1976, when it took the Visa name
2007-2008, when Visa Inc. was incorporated as a stock corporation and went public

All four are defensible. Your integer field forces you to pick one and silently discard the other three. Worse, whichever you pick becomes unfalsifiable downstream, because the reasoning is not stored anywhere.

Model entity events, not a founding year

Keep the integer for display, but make it derived rather than authoritative. Store the events:

{
  "slug": "visa",
  "displayFoundedYear": 1958,
  "entityEvents": [
    { "year": 1958, "type": "program_launch", "note": "BankAmericard" },
    { "year": 1976, "type": "rename", "note": "Visa" },
    { "year": 2008, "type": "ipo" }
  ]
}

Three things get easier immediately. Conflicting sources stop being bugs and become different event types. "Companies founded before 1970" becomes a question you can answer precisely instead of approximately. And when someone challenges a date, you can show them why you chose it.

The rendered version of that record, for reference: Visa company data

Banks, insurers and anything that has been through a demutualisation will break the same way. If your schema has a single founding integer, pick your oldest company and try to defend the number. That exercise is the whole argument.

Modelling Corporate Acquisition History as a Graph, Not a List

corpdigest — Wed, 05 Aug 2026 17:59:41 +0000

Most acquisition data on the web is stored as a flat list: acquirer, target, date, price. That shape is easy to render in a table and nearly useless for analysis, because it throws away the thing you actually want - structure.

Acquisitions are a graph. Nodes are entities, edges are transactions with a direction and a timestamp. Once you model it that way, a set of queries opens up that a flat table cannot answer:

Chains. Company A buys B; B had previously bought C. The IP you care about moved twice. A flat list shows two unrelated rows.
Divestments. An entity leaves the graph and re-enters elsewhere. Spin-offs are edges too, and omitting them makes portfolios look monotonically expanding.
Clustering by category. Group edges by target category and the acquirer's strategy becomes visible as a shape rather than a narrative.

Pharmaceutical companies are the clearest test case for this, because their acquisition activity is pipeline acquisition. Buying a company is often buying one molecule at a specific trial phase. Novartis AG is a useful example - the company was itself formed in 1996 by the merger of Ciba-Geigy and Sandoz, so its own root node is a merger, and its subsequent activity includes both acquisitions and significant divestments as it moved away from generics.

A schema that survives contact with real data:

{
  "acquirer": "novartis",
  "target": "example-bio",
  "announced": "2024-03-11",
  "closed": "2024-07-02",
  "type": "acquisition",
  "category": "oncology",
  "disclosed_value_usd": null,
  "source_url": "https://..."
}

Two design notes.

Keep announced and closed separate. Deals fall through, and collapsing the two dates silently rewrites history.

Make disclosed_value_usd explicitly nullable rather than defaulting to zero. "Undisclosed" and "zero" are very different facts, and 0 will quietly poison every aggregate you compute.

For a worked example of the raw material, the Novartis acquisition history is laid out chronologically, which is a reasonable input format before you normalise it into edges.

Once the graph exists, the interesting queries are the ones about time: how long between a therapeutic area's first acquisition and its second, and does that interval shorten when a strategy is working?

DEV Community: corpdigest

foundedYear Is the Wrong Field for Company Data

Model entity events, not a founding year

Modelling Corporate Acquisition History as a Graph, Not a List