Use case · Shared computation
From Spreadsheet to Shared Model
Keep the freedom that made spreadsheets indispensable. Give the model a shared home when its rules begin to coordinate teams, systems, or organizations.
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.
▶ 0:30
Guided path · Keep the work, share the model
Keep the freedom. Change the architecture.
The spreadsheet succeeded because it let the person closest to a problem build the model. The transition begins when that model becomes shared infrastructure: copies drift, several teams depend on it, or one result can no longer be explained without reconstructing file history.
Explore the worked examples and calculations
Finance · One forecast, several decisions
The workbook became the operating plan.
FY27_Operating_Forecast_v18.xlsx combines actuals, pipeline, hiring, pricing, costs, and cash. Sales keeps a scenario copy, people operations imports the hiring view, department leaders adjust local versions, and the board pack receives a pasted result.
Changed assumption
FORECAST.freight_cost_rate
- Source
- FINANCE PLANNING POLICY
- Revision
- RULE-F27
- Observed
- Planning round 3
What depends on it
- Cost of goods sold
- Product and department margin
- Cash forecast
- Operating plan
- Executive brief
Bounded finding
The approved assumption is represented once, and finance, department, and leadership views resolve from the same forecast revision while retaining their different purposes.Evidence record. Retain the original workbook and digest, formula inventory, named source revisions, approved assumptions, representative periods, edge cases, reconciled differences, accepted model revision, accountable approver, and exact outputs for each view.
Claim boundary. Fictional illustration. It does not claim arbitrary workbooks convert automatically, parity proves the workbook correct, or a shared model improves forecast accuracy. Macros, links, controls, accounting policy, and acceptance criteria require customer review.
Operations · One plan, many handoffs
The weekly plan outgrew the planning file.
W37_Supply_Plan_FINAL.xlsx combines demand, inventory, supplier commitments, production capacity, lead times, and transport windows. Planners update it, buyers receive exceptions, plant teams rekey a schedule, logistics keeps a shipment view, and leadership sees a later summary.
Changed commitment
SUPPLIER-47.confirmed_quantity
- Source
- SUPPLIER COMMITMENT FEED
- Revision
- S-118
- Observed
- 07:30Z
What depends on it
- Available inventory
- Coverage and allocation
- Production sequence
- Buyer exceptions
- Shipment and leadership views
Bounded finding
The represented reduction crosses named coverage and timing rules once, then the planner sheet, buyer queue, production schedule, logistics view, and leadership summary update from plan revision PLAN-38.Evidence record. Retain the source workbook and rule inventory, source revisions, represented constraints, sample periods, known exceptions, parallel-run results, reconciled variances, accepted model revision, permission map, approvals, and as-of receipts for each view.
Claim boundary. Fictional workflow. It does not claim automatic ERP, WMS, MES, supplier, or transport integration; exhaustive optimization; real-time performance; service improvement; inventory reduction; or savings. Validate sources, constraints, security, and acceptance in the customer environment.
Reporting · One number, an inspectable history
Publishing the number is not the same as proving it.
Q3_Performance_Report_v12.xlsx calculates a business-critical metric used in an executive pack, lender report, customer commitment, and external filing. Copied formulas, exclusions, adjustments, and as-of dates make apparently identical numbers difficult to reconcile.
Changed metric rule
METRIC.active_account_exclusion
- Source
- APPROVED METRIC POLICY
- Revision
- METRIC-R12
- Observed
- Effective Q3 close
What depends on it
- Eligible account population
- Metric calculation
- Executive pack
- Lender report
- Filing artifact and configured API
Bounded finding
The sheet, executive document, lender report, and configured API resolve from metric revision METRIC-R12, while an authorized reviewer can replay the prior report under its earlier rule.Evidence record. Retain source revisions and digests, metric-definition revision, reporting period, inclusion and exclusion rules, approved adjustments, permission map, test cases, reviewer comments, approval, publication time, accountable actor, and artifact receipt.
Claim boundary. Fictional illustration, not a certified control, compliance design, audit engagement, or assurance claim. Traceability helps inspection; it does not make source data complete, a rule appropriate, a judgment lawful, or a report correct.
The migration pattern
Keep the work. Make the model shared.
-
Bring the working model
Begin with the spreadsheet people actually use, including manual steps, exceptions, external links, and known imperfections.
One inspectable starting point -
Name its contract
Identify the inputs, assumptions, rules, outputs, decisions, owners, and downstream copies that give the file organizational responsibility.
Owners, rules, decisions, and copies -
Separate facts from judgment
Connect approved facts to named sources. Keep scenarios, overrides, estimates, and policy choices explicit instead of hiding them among formulas.
Visible sources and assumptions -
Make the logic shared
Express relationships and rules in one governed model without taking authorship away from the domain experts who understand them.
One governed model revision -
Prove a bounded result
Run representative periods, edge cases, and known exceptions in parallel. Reconcile differences and record what the accountable owner accepts.
Reconciled tests and acceptance -
Reconnect the work
Give each role the view and permissions it needs, then retain source, model revision, approval, and output history as the model changes.
Role-specific views with history
Continue at your depth
Compare it. Watch it. Read deeper. Build it.
- 01 · Try Compare private copies with one shared model Inspect the same authored rule as five separately maintained implementations and as five permitted surfaces of one governed revision. Jump to the comparison
- 02 · Watch 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 the 0:30 film
- 03 · Read How Grid Works: From Typed Facts to Accountable Action A technical and operational guide to the six-stage Grid chain: governed sources, a shared and versioned model, reactive constraint evaluation, coordinated surfaces, explanation and evidence, and AI assistance bounded by human authority. Read the white paper
- 04 · Build Follow the decision into Grid Continue into the linked Grid Developers guide for the exact behavior, prerequisites, and limits used by this explanation. Build your first reactive model
Evaluate your own model
Bring one model your organization already depends on.
Bring the working file, not a cleaned-up demonstration. Identify its inputs, rules, copies, decisions, approval boundary, and evidence needs before promising a wholesale migration.
- Which copies or implementations must stay aligned?
- Which facts, assumptions, and rules should become shared?
- Where must a person or existing system retain authority?
- What evidence would justify a bounded pilot?
Written analysisRead the full article behind this guided example.
Jump to a section in this publication
The spreadsheet succeeded
The spreadsheet gave people closest to a problem a way to build useful software for themselves. A finance team could encode a forecast. An operator could shape a plan. A scientist could test a model without waiting for a software team.
That freedom is worth preserving.
The difficulty begins when a personal model becomes shared infrastructure. The file is copied. Each team adjusts its version. Data arrives at different times. A rule changes in one place but not another. The cells still look familiar, yet the organization can no longer be sure that everyone is calculating the same answer.
What changes with Grids
Grids moves the model from a private file into a shared computational system.
The expert still defines the information, relationships, and rules. Different people can still work through the views that fit their jobs. But those views are powered by the same model instead of separate copies of its logic.
A sheet, chart, map, document, or application can become another way to use the model—not another place to rebuild it.
When to consider the shift
A shared model becomes valuable when the same rules cross teams, when copies regularly drift, when explanations require forensic spreadsheet work, or when one change must be reconciled across several systems.
The goal is not to eliminate spreadsheets. It is to recognize when a model has outgrown the architecture of a file.
Imagine the first bounded test
Choose one recurring decision already encoded in a spreadsheet. Name the people who depend on it, the copies that must stay aligned, the source that changes most often, and the person who approves the result.
Then keep unlike claims separate. Matching an existing workbook is parity evidence, not proof that its formulas are correct. An explainable result is not automatically a good policy. A recommendation is not authorization, and authorization is not an observed business outcome.
That is enough to frame a focused Grid evaluation without redesigning the entire workflow.