Programming with Rules
Every Spreadsheet is a Program
You write a formula that says =A1*B1. You copy it down a column and the result propagates through the grid. You link cells across tabs and the calculation traces a path through dependencies. You are writing logic, executing logic, and changing logic.
The question is not whether you are programming. The question is at what level.
The Spreadsheet as Assembly Language
A spreadsheet is the closest thing to assembly language that most business people will ever write.
Think about what assembly gives you. It is direct. Every instruction maps to a machine operation. You can do almost anything if you have enough patience. But writing real software in assembly is miserable because the abstraction gap is enormous. To build anything meaningful, you spend most of your energy managing memory addresses, registers, and control flow, spending time on something that has nothing to do with the actual problem you are trying to solve.
A spreadsheet works the same way.
In a spreadsheet, the cells are memory addresses. The formulas are operations. The grid layout is the control flow. When you write =B2*C2 in cell D2, you are not expressing a business rule. You are encoding a calculation at the level of individual memory locations, i.e. you are NOT defining relationships between rows, columns, sheets explicitly. The structure and relationships live only in your head and the software does not enforce them.
This is fine when you are writing five formulas. It is catastrophic when you are writing five thousand.
The Abstraction Gap
Here is the fundamental problem.
When you write Gross_Margin = Revenue - Cost_of_Sales in natural language, you are expressing a single, clear idea. It is self-documenting. It is independent of layout of the calculations on the sheet, independent of how many times it appears in the model.
When you write =B2-C3 in cell D4, you are encoding the same idea, but it is invisible. Anyone opening the spreadsheet has to read D4, trace back to what B2 and C3 are, hope that the naming conventions are consistent, and hope that nobody has overwritten a formula with a hardcoded number. The idea is buried inside the ‘workings.’
This is the abstraction gap. Spreadsheets force you to express high-level business logic at a low-level addressing scheme. You are programming in coordinates instead of concepts.
One other way of expressing the problem is that in a traditional spreadsheet you have to use ‘positional’ addressing while a business rule can be expressed by what is called ‘semantic’ addressing independent of the grid. That is, a rule ‘lives’ in a ‘semantic’ space.
Rules as a Higher-Level Paradigm
High-level programming languages exist because programming in assembly is not easily scalable. Most high level programming languages support statements like Revenue = Price * Quantity. SQL, for example, lets you describe what data you want instead of how to traverse the indexes. Python let you say “for item in items: …” instead of managing loop counters and memory.
Each higher level does one thing: it lets you express intent directly instead of encoding it through addressing and “plumbing.”
OpenModeling takes the same approach. Instead of forcing you to express business logic as cell formulas scattered across a grid, it lets you express it as rules, easily inspectable units of logic.
A rule says what, not where.
Gross Margin = Revenue - Cost
This rule has an identity. You can trace its dependencies. You can change its expression without moving data around. The model understands it as a relationship, not as a combination of a formula and grid layout.
OpenModeling is not a minor improvement. It is the same kind of leap that separated assembly from, say, BASIC. Each leap reduced the gap between what you meant and how you had to encode it.
What Changes When Rules Are First-Class
When rules become first-class citizens of the model, everything about working with large financial and planning models changes.
You can audit a model without reverse-engineering it. In a spreadsheet, auditing means tracing formula references through a maze of cell addresses. In OpenModeling, you open the rule panel and read the rules. Each rule is explicit. Each rule has a clear target. The dependency graph is a first-class object you can inspect.
You can change structure without breaking logic. Add a new dimension? The rules do not care. Reposition items in a grouped hierarchy? The rules do not care. Rules operate on semantic relationships, not on coordinates. When the model is explicit, you can reorganize it without hunting down hardcoded references.
You can version your logic. Model versions can be tracked, compared, and reverted. In a spreadsheet, versioning means saving model_v3_final_final5.xlsx. OpenModeling provides easy to use git-like version control tree allowing you to have as many versions as you like without resorting to external tools.
You can separate concerns. The model defines dimensions, cubes, rules, and groups. The grid presents them. You CAN use individual cells, but that is reserved for overrides by hard values, or, simply, manual input values. When someone rearranges the layout, say flips rows and columns, or changes which dimension is on page filter, the logic still does not change. So the view is separate from the model.
The Tradeoff
Every abstraction involves tradeoffs. High-level languages hide details. They constrain what you can do so that the common use cases become easy.
OpenModeling is no different. You accept that the model has structure based on dimensions, cubes, and rules, and that structure is non-negotiable. You DO have to define dimensions and items (i.e. business parameters) first. You trade the spreadsheet’s infinite flexibility for something more valuable at scale: predictability.
This is the same tradeoff that structured programming made over machine code, that relational databases made over flat files, that ORMs made over raw SQL. You lose some raw control. However, what you gain through architecture surpasses the loss of the comfort of spreadsheet familiarity.
What You Are Building
OpenModeling is an attempt to bring this higher-level paradigm to financial modeling, planning, and analytical computing.
It is early. Open Modeling (OM Core™ alpha) is a working prototype. There are dimensions, groups, cubes, rules, views, and a calculation engine. There is also a terminal / command line interface allowing you to perform most of actions via a command line or record/play a script, perhaps generated by an LLM. You also have a basic multi-user support. There is a lot of infrastructure that is not the point of this post.
The point is simple: business logic ought to be expressed at the level of concepts, not coordinates. If that idea resonates with you, follow along. Try the preview build and tell me what you like and where the design is incomplete.
The links below will get you started:
YouTube Demo
Update: OM Core is now public
Since publishing this post, I have made the OM Core repository public:
https://github.com/cloudcell/om-core
It is still early alpha software. APIs, commands, file formats, GUI behavior, and module boundaries may change before v1.0. But the core idea described above is now available to inspect, run, test, and critique.
The repository currently includes the modeling engine and the supporting application stack needed by the current alpha: commands, REPL, GUI/TUI/runtime components, examples, tests, and project governance files.
I am especially looking for feedback from people who build financial, planning, operational, or analytical models today.
The most useful help right now is simple:
clone it
try to run it on a clean machine
read the examples
tell me where the idea, installation, terminology, or workflow becomes confusing
Documentation is here:
https://cloudcell.github.io/om-docs/
If “programming with rules instead of coordinates” resonates with you, I would value your feedback.