One Lake, Three Names: Building Systems That Survive a Sudden Change to the Facts

One Lake, Three Names: Building Systems That Survive a Sudden Change to the Facts

On 27 August 2026 a US executive order renamed Lake Ontario to Lake America in the federal geographic names database. Three days later Google Maps applied the change, and Apple Maps followed on 2 September. Canada rejected the name, and the border between the two countries runs through the lake itself.

The result is that a single geographic entity now carries three labels depending on where you are looking from: people in the US see Lake America, people in Canada see Lake Ontario, and everyone else sees both. This is not the first case; the Gulf of Mexico was renamed the Gulf of America last year on the same logic.

It is easy to read this as political news and move on. What actually happened is an engineering test: every system in the world that stored this lake's name as fixed text is now showing wrong information to a portion of its users. The question that matters to us: is your system built to absorb that kind of change?

The root mistake: storing the label instead of the identity

Most systems store what the eye sees. A text field called city holds Riyadh, a country field holds a country name, a tax rate is a number written into the code. That works efficiently until the fact itself changes, and you discover your historical data can no longer be interpreted.

The engineering rule is simple: store a stable identifier and render the label at display time. The lake is an entity with an identifier that does not change, and multiple names depending on language, context and official source. Store the identifier and a rename becomes an update to one reference table. Store the name and it becomes a full data migration project.

What actually changes in the life of a Saudi company?

The lake is a distant example. The list is not:

• Tax rates. Saudi VAT moved from 5% to 15% in 2020, and companies that wrote the number into their code had a hard week. Worse than the change itself: old invoices must keep their old rate.
• E-invoicing requirements. Integration waves with ZATCA arrive in phases, and each wave can carry a change to the technical specification.
• Country names. Türkiye became the official UN name in 2022, Macedonia became North Macedonia, Swaziland became Eswatini. Any country list typed by hand into your system is already out of date.
• National address and data formats. Postcode, national ID, IBAN and entity number formats get updated, and every validation written as a rigid regular expression breaks at the first extension.
• Taxes in other markets. If you sell outside Saudi Arabia, change arrives from countries whose news you do not follow — as happened this month when app stores added new taxes in three countries at once.

Five principles for infrastructure that absorbs change

• Identifiers, not labels. Tie every entity to a stable identifier and keep names in a separate table that accepts more than one name per entity, by language and by source.
• Effective dating on every changeable value. A tax rate is not one number but a series of values, each with a start and end date. This alone solves reprinting an old invoice at the correct rate, and prevents an accounting disaster at the first audit.
• Reference data as configuration, not code. Lists of countries, currencies, taxes and regions live in a table or config file an authorised administrator updates — not in constants inside the code that need a release and a development team.
• A display layer separate from storage. What is stored is one thing; what is shown is another. Once a system separates them, showing different names to different users is a setting rather than a rebuild — which is exactly what Google did with the lake.
• One source of truth. If the tax rate is written in the database, in the invoice template and in the sales report, you own three copies that will inevitably disagree. Pick one place and make the rest read from it.

A practical check on your system this week

This does not need a project. Sit with your developer and ask five questions:

• If the tax rate changed tomorrow, how many files do we edit? And do old invoices stay correct?
• Where is our list of countries and currencies — in a table, or written into the code?
• Do we store city names as text, or as identifiers linked to a reference?
• What happens if the authority adds a digit to the national ID or changes the postcode format?
• How many places in the system know the tax value? If it is more than one, that is your next problem.

The answers expose your fragile points in half an hour, and most of them are fixed in days when handled before they are needed rather than after.

The Origami view

We see a lesson here that we repeat to clients: a good system is not the one that works today, but the one that absorbs a changing world without being rewritten. The difference between the two is not the programmer's cleverness but simple design decisions taken in the first week: an identifier instead of text, an effective date instead of a fixed number, a reference table instead of a list in the code.

Those decisions cost hours at the start and save weeks later. We have seen companies stop invoicing for days over a regulatory change that could have been absorbed by updating one row in a table, and the cause is always the same: a value written into a place that was never designed for it to change.

Conclusion

A lake was renamed in one country and the name rejected in another, so it now carries three labels at once. This is not an exception; it is a miniature of what happens to reference data constantly. Taxes, names, formats and regulations change by external decision you do not control. What you do control is your system's readiness, and that is decided in the design, not at the moment of change.

Sources

• The official Google blog — the statement on applying the name change in Google Maps and how it is displayed to users in the US, Canada and the rest of the world, 30 August 2026.
• Reuters, TIME and BBC coverage of the executive order on 27 August 2026, the Apple Maps change on 2 September, and Canada's position.
• ZATCA zatca.gov.sa — the official reference for VAT rates and e-invoicing phases.
• The United Nations — the adoption of Türkiye as the official name in 2022, as a documented example of country name changes.