foundedYear Is the Wrong Field for Company Data

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.