Repeated business rules
The same logic is expressed several times because each runtime surface wants a local version of the rule.
What problem does UMA solve?
UMA exists because modern systems keep preserving deployment freedom while losing behavioral coherence. The same business rule gets reintroduced in the browser, edge layer, backend, workflow engine, and now inside AI-assisted paths. Each move feels locally justified. The system as a whole becomes harder to explain, govern, and change.
The short answer
UMA solves the problem of behavior fragmentation across runtimes. It gives teams an execution model for distributed systems where compute can happen in many places and the system decides where logic runs, while still keeping one business behavior portable and runtime choices explicit.
It is not mainly a deployment optimization. It is an architectural response to a system that keeps multiplying its execution surfaces faster than its architectural model evolves.
The useful portability slogan here is not “write once, run everywhere.” It is “write once, run where it makes sense.”
What the pain looks like in real teams
A product rule starts in one place and then spreads. The frontend adds a local check for responsiveness. The backend repeats it for authority. An edge adapter copies part of it for latency. A workflow or agent path recreates it because the original service boundary is no longer visible enough to reuse directly. No single duplication looks outrageous. The total effect is drift.
When that happens, the architecture is no longer governed by one stable model of behavior. It is governed by whichever runtime happened to become responsible for the latest copy.
Hidden runtime authority
Placement, adapters, policy, trust, and orchestration start deciding outcomes without staying legible in the architecture.
Expensive change
Simple rule updates require touching multiple stacks, increasing the chance of inconsistency and regression.
Weaker explanation
The system can still work while becoming harder to audit, reason about, and evolve safely.
Why common platform tooling does not fully solve it
Good platform tooling can deploy services, route traffic, scale workloads, and wrap them with observability or policy. Those are necessary capabilities. They still do not guarantee that one business behavior remains coherent as execution spreads across browser, edge, backend, background jobs, and AI-assisted workflows.
That is why UMA is not mainly competing with deployment platforms. It is trying to solve a different architectural gap: the absence of a durable model for one behavior that can survive across many runtime surfaces without being silently reauthored by each one.
What UMA changes
UMA changes the center of gravity. Instead of treating the deployable unit as the main architectural anchor, it treats portable behavior as the durable unit and makes the runtime around it explicit. That runtime can then discover capabilities, validate constraints, approve workflows, enforce trust, and preserve enough trace for the system to explain what happened.
In practical terms, UMA tries to keep three things true at once:
- the service behavior stays recognizable across runtimes
- runtime decisions stay governed instead of becoming hidden architecture
- system evolution stays visible instead of collapsing into duplication and drift
Why this matters more now
The problem is sharper today because more systems now include workflow engines, edge execution, local client logic, and agent-assisted planning. If the architecture only models backend service ownership, it leaves too much of the real system outside the durable design vocabulary.
UMA becomes relevant when a team realizes its hardest architectural problem is no longer just how to split services. It is how to keep one business behavior coherent while several runtimes, policies, and decision surfaces participate in producing the result.
A fast test for whether this is your problem
Ask one blunt question: if a core product rule changes tomorrow, how many runtime surfaces need to be inspected, rewritten, or revalidated before you trust the result? If the answer is browser, backend, workflow, edge, and maybe an AI-generated path, then your architecture is already paying the tax UMA is trying to reduce.
Where to go next
This page is the short version of the problem statement. The site covers the vocabulary needed to evaluate the model in more concrete terms, and the examples repository shows how that model behaves when it is pushed into runnable systems. In the book, I take this problem further and connect it to the full design sequence from one portable service to a governed runtime reference application.
Once the problem is clear, the next useful question is not “what tool should I use?” but “what durable unit should the architecture preserve?” That is where the rest of the UMA concept cluster becomes useful.