Chapter 2: Why Device Independence Matters

What goes wrong when logic is environment-coupled

Environment coupling is invisible until it's expensive. A pricing rule written for the backend works correctly in isolation. The same rule rewritten for the browser to reduce latency diverges subtly six months later when one copy gets updated and the other doesn't. By the time the inconsistency surfaces in production, there are three more copies: one in the edge layer, one in the workflow orchestrator, one in the AI-assisted path. Each copy was a local optimization. The aggregate is a governance failure. Device independence isn't about running on phones. it's about the architectural property that prevents this cascade.

Four failure modes of environment-coupled logic

The chapter identifies four specific failure modes that emerge when logic is written against a single execution environment rather than a portable contract.

Behavioral drift is the most common: two copies of the same rule diverge over time because they're maintained separately. Neither is wrong in isolation. The system is wrong in aggregate, and no single team owns the discrepancy.

Hidden duplication is drift before it becomes visible: the same logic lives in multiple places but isn't recognized as the same logic because the implementation shapes are different. A backend function and a browser utility can encode the same business rule in ways that look unrelated until a compliance audit or an incident forces the comparison.

Governance blind spots emerge when a copy of the logic exists in an environment that isn't covered by the team's normal review and audit process. Edge functions and AI-assisted paths are the most common current examples. Logic that runs there is often not subject to the same change management as the canonical backend version.

Portability debt is the accumulated cost of all three: the system is no longer portable in practice, because moving a capability to a new environment requires rediscovering every assumption the current implementation makes about its host. The chapter shows how each failure mode compounds the others and why fixing one copy at a time doesn't reduce the structural risk.

What device independence actually means in UMA

The term "device independence" invites the wrong mental model. It sounds like responsive design. make the interface work on mobile and tablet as well as desktop. That's not what the chapter is about. In UMA, "device" means execution surface: the thing that hosts the logic and provides it with resources. A browser tab is an execution surface. An edge node is an execution surface. A server-side function is an execution surface. A workflow engine step is an execution surface. An AI agent tool call is an execution surface. The list has been growing for twenty years and will keep growing.

Device independence, in this context, is the architectural property that allows the same business logic to run on any of these surfaces without modification. Not a reimplementation in the surface's preferred language. Not a version maintained separately for each host. The same compiled artifact, governed by the same contract, producing the same result regardless of what loaded it. This is a stronger claim than most teams realize when they first encounter it. and a stronger claim than most "portable" service designs actually support.

The chapter establishes why the execution surface is the right unit of analysis. Not the deployment environment, not the cloud provider, not the framework: the surface that owns the execution context. When you define portability at that level, the solution space shrinks to a small set of architectural decisions. When you define it at the framework level, you end up with a different "portable" solution for every class of surface, which is not portability at all.

The cost of coupling made concrete

Abstract arguments about coupling don't move engineering priorities. The chapter uses a worked example to make the cost concrete. The example is a feature flag evaluator: a rule that takes a user context and a flag configuration and returns a boolean. It starts as a single backend service. well-tested, correctly implemented, owned by one team. Then the product organization asks for the evaluation to happen at the browser to eliminate a round trip. One copy becomes two maintenance obligations. When a bug is found in the evaluation logic, both copies need to be patched in the same release window or the system is inconsistent for the duration between patches.

The edge layer comes next: the same evaluation is needed at the CDN to avoid a browser round trip on initial load. Two copies become three. The governance question becomes harder: which copy is canonical? Which gets patched first? Who owns the edge version? Six months later, an AI-assisted path needs the same evaluation to gate tool availability. Three copies become four. Each copy was independently justified as a local optimization. The aggregate cost is four codebases encoding the same rule, four test suites that don't share fixtures, four incident response paths when the rule changes, and no single owner with authority over all four.

This is where the chapter quantifies portability debt. It isn't a vague accumulation of technical debt. it's a specific multiplication of maintenance obligations proportional to the number of execution surfaces. One rule on four surfaces, maintained as four copies, is not four times the cost of one copy. It's four times the base cost plus the coordination overhead every time the rule changes, plus the incident cost every time one copy drifts. The chapter shows that this cost structure is deterministic, not accidental. and that the only architectural intervention that changes the structure, rather than deferring its consequences, is separating the logic from the surface it runs on.

How it connects

Chapter 1 establishes that execution surfaces are multiplying and the model has to change. Chapter 3 defines the model precisely: what UMA is, how it separates portable logic from runtime concerns, and why that separation resolves all four failure modes.