Article · Shared models

The Spreadsheet Is Not the Problem. The Private Copy Is.

Spreadsheets made computation accessible to experts. Their limitation appears when one useful model becomes many separately maintained versions of shared business logic.

August 24, 20262 minute readexplainer

Narrated film · 0:30

From Spreadsheet to Shared Model

A familiar spreadsheet gives experts freedom to build, but separate files leave every organization maintaining its own version of the rules.

Watch film · 0:30 Read the publication · 2 min
▶ 0:30

A remarkably successful interface

The spreadsheet is often blamed for problems created by its own success.

It let people express logic directly. That mattered because the person who understands a forecast, allocation, experiment, or transaction is often not a professional software developer. Cells and formulas closed that distance.

For personal analysis and bounded team workflows, a file may still be exactly the right tool.

The boundary changes the problem

The architecture strains when the model crosses an organizational boundary.

One team emails a copy. Another adjusts a formula. A third imports the results into an application. Each version begins with the same intent, but each develops its own history. The organization is no longer sharing a model. It is periodically reconciling descendants of one.

The visible problem is duplicate files. The deeper problem is duplicate authority.

Which rule governs? Which input is current? Which result was approved? What changed between the number presented yesterday and the number shown today?

One model, many useful views

A shared model does not require everyone to use the same screen. Finance may need a sheet. Operations may need a map. Leadership may need a concise decision view. A partner may receive only one approved result.

The important change is underneath: each view derives meaning from governed logic rather than reimplementing it.

A practical threshold

Do not begin by replacing every spreadsheet. Begin where a model already behaves like infrastructure:

  • Several teams depend on it.
  • Copies regularly drift.
  • A change must be translated into multiple systems.
  • Explaining a result requires reconstructing file history.
  • The decision carries material or public consequences.

The spreadsheet proved that experts should be able to build models. The next step is giving important models an architecture equal to the responsibility they already carry. How Grid Works follows that architecture from a governed source fact through reactive evaluation, coordinated views, explanation, and accountable action.

Related films, scenarios, and next steps

Choose the next move

Test the claim with a different kind of evidence.

For business leadersApply the model to familiar workFollow a bounded use case from a changed fact through evidence, calculation, review, and authorized action.See the modelFrom Spreadsheet to Shared ModelA familiar spreadsheet gives experts freedom to build, but separate files leave every organization maintaining its own version of the rules.For technical evaluatorsFollow the concept into Grid DevelopersContinue into the linked Grid Developers guide for the exact behavior, prerequisites, and limits used by this explanation.

Continue exploring

Follow the next question.

White paper · 13 min What must be shared so that changing facts produce one inspectable decision state without forcing every participant into one system or transferring authority to software?

From Common Operating Picture to Common Operating Model

Seeing the same facts is not the same as calculating from the same rules. A common operating model connects source identity, dependencies, constraints, alternatives, authority, role-specific views, and replayable evidence.

Understand · EvaluateSource-grounded Explore
White paper · 11 min How can one public-program rule serve many people and systems without becoming many conflicting implementations?

One Program Rule, Many Public Surfaces

Governed Policy Across Staff Tools, Public Explanations, Reports, and APIs

Public programs often reimplement one rule in staff tools, websites, notices, reports, and partner interfaces. This paper proposes a governed, versioned rule package with audience-specific surfaces and a bounded way to test whether they remain aligned.

Understand · GovernSource-grounded Explore