First-Class Models: The Missing Productivity Revolution

4 hours ago 2

TL;DR: First-class models with branching and merging capabilities represent an almost entirely unused enormous productivity and expressiveness unlock in programming and computer systems.

Imagine you’re building an accounting system from scratch. You’d design it properly: a normalized database schema, algebraically defined operations for debits and credits, account reconciliation, and comparison functions. You’d implement data-only, invariant-preserving operations using database functions and procedures, with clean authorization models. The result would be a database perfectly customized for accounting, supporting multiple simultaneous client interfaces in any language.

This represents the current state of the art—and it’s genuinely good architecture.

But now put yourself in the shoes of the users: knowledge workers, engineers, analysts who depend on this beautifully designed system. Despite having access to well-structured data and operations, they face a fundamental limitation when it comes to the kind of thinking their work actually requires.

Consider an engineer working on a project management system. They’re constantly asking computational questions that our current systems simply don’t support:

- What if I replace this supplier with one offering different prices?

- If I increase this capacity parameter, how much larger does the engine room need to be? How much more cement do we need?

- Would using a different manufacturing process have significantly changed our profitability last year?

Today, when faced with these questions, professionals resort to crude workarounds: rough estimates, Excel spreadsheets copied from the main system, or in rare cases, custom programs written specifically for the analysis. Each approach disconnects them from the authoritative data source and requires manual reconciliation with the primary system.

What we need is the ability to explicitly manipulate and navigate between different models of our system’s state. This goes beyond simple version control—it’s about making hypothesis exploration a core system capability.

Users should be able to view any previous state the system was in, not just as read-only history, but as a living branch they can extend and modify. This isn’t just data versioning—when examining past states, users should be able to run the older versions of functions that were available at that time, maintaining complete computational consistency.

Without changing the authoritative state, users should be able to create simulation branches. Imagine branching your company’s current accounting state to model next month’s performance. You manually enter projected sales for California stores, then use regression or AI to estimate likely values for other regions. You can then:

- Compare this hypothetical future against a baseline projection

- Diff the states to understand the specific impacts of your California strategy

- Selectively merge insights back into your planning process

This is a generalization of what programmers do with Git, but applied to all system state and made accessible to ordinary users.

Users need intuitive ways to see and navigate branches without getting lost in complexity. While this presents interesting UI challenges (including fraud prevention), the core operations are familiar: branch, compare, merge, and rollback. The key is making these operations meaningful for business content, not just code.

The branching and merging users perform manually should be built on the same foundations that handle automatic synchronization in distributed systems. This means generalizing the work done in CRDTs (Conflict-free Replicated Data Types) and other synchronization primitives.

Currently, we have a fragmented landscape:

- CRDTs handle concurrent collaborative editing

- Git provides version control with manual conflict resolution

- Database replication uses various conflict resolution strategies

- Most business systems avoid conflicts entirely through restrictive permissions

By unifying these approaches, we can create composable synchronization primitives where user-driven branching and automatic conflict resolution are different manifestations of the same underlying mathematical operations.

Some changes (updating contact information) can auto-merge across all branches. Others (modifying core business logic) require explicit human decisions about propagation. The system provides the infrastructure for both, with the choice of automation level being a design decision rather than a fundamental limitation.

This approach solves what we might call “spreadsheet escape”—the common pattern where users copy data into Excel to explore scenarios, losing connection to the authoritative source and creating reconciliation problems. With first-class modeling, users stay within the system where their explorations maintain semantic relationships and can be selectively integrated back into the main state.

The engineer wondering about supplier changes doesn’t need to export data and lose track of dependencies. They branch the current state, modify supplier relationships, and let the system compute cascading effects while maintaining full traceability back to the source.

When modeling becomes a first-class system capability rather than an ad-hoc user workaround, we unlock fundamentally new ways of thinking about business problems. Decision-makers can explore scenarios with the same rigor programmers bring to code, but without requiring programming skills.

The knowledge worker asking “what if” questions deserves computational support that matches the sophistication we bring to the underlying data management. First-class models provide that support, turning hypothesis exploration from a painful exception into a natural part of how systems work.

This isn’t just better tooling—it’s a different relationship between users and their computational environment, one where the system actively supports the kind of exploratory thinking that drives actual business value.

Attentive readers will realise that this is a description of the UI design principles underlying Frest (the subject of this Blog).

Discussion about this post

Read Entire Article