The Number Is Not the Company: What Identity Teaches Us About Interactive Systems

What can a tax identification number teach us about designing better software?

At first, almost nothing. One is an eight digit administrative code associated with a company. The other is a way to organize interactive applications around a model, an update function, and a view. One belongs to bureaucracy; the other belongs to programming.

Yet they meet around a surprisingly deep problem: how can a system know what something is while it is changing?

A company may change its address, officers, products, or internal structure while retaining the same legal identity. A software application may change its screen, data, and user interactions while remaining recognizably the same application. In both cases, reliability depends on separating stable identity from mutable behavior.

That separation is not merely a technical convenience. It is a general design principle for making complex things legible.

The difference between identity and activity

An identifier such as 84 2446258 does not describe everything about the organization it names. It does not tell us what the company sells, whether it is profitable, who works there, or whether it is still active. It performs a narrower and more valuable function: it gives many other systems a stable reference point.

A bank can use it to associate records. A regulator can use it to distinguish one entity from another. A form can ask for it without needing to understand the entire history of the business. The number is powerful precisely because it is thin. It does not attempt to contain the company. It points to the company.

This distinction is easy to overlook. People often confuse a description with an identity. We say a company is its product, its employees, its building, or its reputation. Those features matter, but each can change. Identity is what allows us to say that the entity persists through those changes.

Software has the same problem. A button may appear in one place today and another place tomorrow. A form may contain different text. A user may click a button, type into a field, or trigger a network request. These are activities and states, not identity. If an application treats every visible change as a separate phenomenon, its behavior becomes difficult to reason about.

The remedy is to establish a stable model of what the application knows, then define how that model changes when something happens, and finally derive the visible interface from the current model. The screen is not the application itself. It is an expression of the application’s present state.

A stable identity does not prevent change. It makes change intelligible.

This is the first connection between administrative identification and interactive software. Both replace an unmanageable stream of observations with a durable reference. Once the reference exists, changes can be recorded as changes to something, rather than as disconnected facts.

Why input creates the real test

A static page can often hide poor structure. If nothing changes, almost any arrangement of code may appear adequate. The deeper test begins when a person interacts with the system.

Consider a small shopping list. At the beginning, the model might be:

{ items = []
}

The user types “Buy coffee” into a text field. That action should not directly manipulate an assortment of visual elements in an unpredictable way. It should become a meaningful message, perhaps:

UpdateInput "Buy coffee"

The update logic receives that message and produces a new model:

{ items = [], draft = "Buy coffee"
}

The view then reads the model and displays the text field with the new value. When the user clicks “Add,” another message arrives. The update logic decides whether to append the draft to the list, clear the field, or reject the input.

This may sound like an elaborate procedure for a simple interaction. It is actually a discipline for preserving causality. The system can answer three questions clearly:

• What did the user do?
• How did the underlying state change?
• Why does the screen now look different?

Without this separation, a click might directly alter one element, indirectly trigger another callback, modify a hidden variable, and produce a visual result that depends on timing. The application may still work, but its behavior becomes a mystery assembled from side effects.

Administrative systems face an analogous challenge. A company identifier allows many actions to refer back to one stable entity. A payment, filing, or address change is not a new company. It is an event concerning the same company. The identifier provides continuity while the records around it evolve.

The underlying mental model is the same:

1. Establish the entity or model.
2. Represent an input as an explicit event or message.
3. Apply a defined transformation.
4. Produce an updated state.
5. Derive the visible or operational result from that state.

This pattern turns change from a source of confusion into an inspectable process.

The hidden cost of systems without a center

Many organizations and applications become difficult to maintain for the same reason: they lack a clear center of gravity.

In an organization, one department may call a company by its legal name, another by an account number, and a third by a product label. If those references cannot be reconciled, the business accumulates duplicate records and contradictory beliefs. A customer can appear active in one system and unknown in another. The problem is not simply bad data. It is the absence of a shared identity.

In software, the equivalent failure appears when different interface components each maintain their own version of the truth. A text field stores one value, a validation layer stores another, and a summary panel infers a third. The user sees inconsistency because the application has no authoritative model from which all views are derived.

The symptoms are familiar:

• A field displays a value that the application does not actually recognize.
• A button appears enabled even though the underlying data is invalid.
• Two screens disagree about what has been saved.
• Fixing one interaction breaks another because the state is scattered across unrelated locations.

These failures are often described as bugs in individual components. More fundamentally, they are failures of reference architecture. There is no agreed answer to the question, “What thing are we talking about, and where is its current state recorded?”

A central model does not eliminate complexity. It gives complexity a place to live. That matters because complexity is unavoidable once a system accepts input. Every input can alter the future. If those alterations are not represented explicitly, the system’s history becomes implicit, fragmented, and difficult to reconstruct.

A useful design test is therefore not, “Does this component work?” It is, “Can I explain the path from input to state to output without appealing to invisible exceptions?”

The model is a contract, not a storage box

It would be a mistake to think of the model as merely a database or a bag of variables. Its deeper role is contractual. It defines what the system believes to be true at a given moment.

Suppose an account creation form has three fields: email, password, and password confirmation. A weak implementation may let each field manage itself, while validation happens in scattered places. A stronger model might make the state explicit:

{ email = ""
, password = ""
, confirmation = ""
, status = Editing
}

The status could later become Ready, Submitting, Succeeded, or Failed. These are not decorative labels. They prevent the interface from making contradictory claims. If the status is Submitting, the submit button can be disabled because the model says the request is in progress. If the status is Failed, the view can display an error because failure is part of the state, not an accidental side effect.

The same principle applies to any institution that must track an entity over time. An identifier alone is insufficient. It must connect to a structured account of status, history, and permitted actions. The number says which entity is involved; the model says what is currently true about it.

This yields an important distinction:

Identity answers “which one?” State answers “what is true now?” Events answer “what happened?”

Confusing these categories causes design errors. If identity is treated as a description, it becomes unstable. If state is treated as identity, every change looks like a new entity. If events are hidden, the transition between states cannot be explained.

Together, the three categories form a compact grammar for reliable systems:

• Identity: the stable reference that persists across change.
• State: the current description associated with that reference.
• Event: an input that may transform the state.

This grammar works for a form, a company registry, a support ticket, a medical record, or a personal habit tracker. It is not tied to a programming language or an administrative procedure. It is a way of thinking about continuity.

Designing for inspection and recovery

The practical benefit of this architecture appears when something goes wrong. If a user says, “I clicked the button, but nothing happened,” a system with explicit messages and state offers a path to diagnosis. Did the click produce the expected message? Did the update logic receive it? Did the model change? Did the view render the new model? Did an external request fail?

Each question narrows the search.

By contrast, a system built from hidden mutations encourages guesswork. Developers inspect callbacks, timing, shared variables, and component interactions until they find a plausible explanation. The system may be fast in the short term, but every future change becomes expensive because no one can confidently predict its consequences.

The same logic improves organizational operations. When a record is wrong, an explicit chain of identity, event, and state makes correction possible. Which entity did the transaction concern? What input created the current record? Which rule transformed the previous state into the current one? Can the change be reversed or audited?

This does not mean every system needs exhaustive event logging or a grand formal architecture. It means that important transitions should be visible enough to inspect. A small application can benefit from the same discipline as a large institution, even if its implementation is simple.

A useful rule is make the important state boring. Store it in a form that can be read, tested, compared, and recreated. Put creativity into the user experience, not into the question of where the truth is hiding.

Key Takeaways

• Separate identity from description. Use a stable reference for the thing that persists, and allow its attributes to change without redefining the entity.

• Represent input explicitly. Treat a click, keystroke, payment, or status change as a meaningful event rather than an invisible side effect.

• Keep one authoritative model. When multiple screens or components need the same information, derive them from shared state instead of allowing each to invent its own version.

• Make transitions explainable. For every important change, be able to answer what happened, what state changed, and why the visible result followed.

• Design for repair, not only success. A system is trustworthy when a mistaken state can be traced, diagnosed, and corrected without relying on intuition.

The surprising lesson is that identifiers and interfaces are not opposites. Both are technologies for preserving continuity amid change. An identifier gives a changing entity a stable name. A disciplined architecture gives changing behavior a stable path.

Once this becomes visible, many design problems look different. The question is no longer merely whether a company has the right number or whether an application responds to a click. The deeper question is whether the system can maintain a coherent answer to three demands: what is this, what happened to it, and what is true now?

The strongest systems do not resist change. They give change a name, a place, and a consequence. That is how a stream of unpredictable inputs becomes something a person, a team, or a machine can understand.