In 2023 I published a paper on Client-Side Microservices Architecture. The core question was: why can't the browser be a first-class execution environment? Not a thin UI layer that calls a server for everything important. An actual runtime that runs real business logic with the same guarantees as the backend.
The question got traction. People recognized the problem even if the specific framing was new. A year later, after building the ideas out further and running them against real teams with real codebases, I realized the question was actually about something bigger. Not just about the browser. About what it means to define a business capability independently of any execution environment at all.
That is what Universal Microservices Architecture ended up being. And what Traverse is the runtime implementation of.
What UMA is in plain terms
Universal Microservices Architecture is a framework for writing business capabilities that run anywhere. Not "anywhere with the right SDK installed." Genuinely anywhere: browser, edge node, cloud function, mobile device, AI orchestration pipeline. The capability does not need to know which of these it is in.
The word "universal" in the name is doing real work. Traditional microservices are universal in the sense that they are deployed as network services accessible from anywhere that can make an HTTP call. UMA is universal in a different sense: the logic itself is portable. You do not access it over the network. You run it where you are.
This distinction matters. Accessing logic over the network adds latency, adds a failure mode, and adds a hard dependency on connectivity. Running logic locally removes all three. The challenge is maintaining consistency: how do you ensure the capability that runs in the browser is the same capability that ran in the backend worker last Tuesday?
The answer is contracts and a shared registry. Which is exactly what UMA specified.
The three ideas that held up under scrutiny
After a year of building on the UMA model, three core ideas proved consistently correct:
- 01 Portable capabilities. A business capability should be a named, versioned unit of behavior that can be placed in any conformant runtime. The capability is the artifact. The runtime is the context it is placed in. These two things should be independently managed.
- 02 Machine-readable contracts. Every capability should have a contract that a machine can read and validate against. Not documentation. Not comments. A structured file that answers: what does this capability take, what does it produce, what does it require from the environment, where can it run?
- 03 Runtime is a deployment decision. Where a capability runs should be decided by the deployment layer, not encoded in the capability's logic. The capability declares where it can run. The runtime decides where it does run based on context, policy, and availability.
These three principles are the backbone of everything Traverse implements. They sound straightforward when written out. Getting a real runtime to enforce them consistently across four different execution environments is what took two years.
What changed from UMA to Traverse
UMA was a model. An architectural framework. It described how a system should behave and why. It did not ship code.
Traverse is the runtime implementation of the UMA model. It ships code. It has an opinionated implementation of contracts in TOML, capabilities compiled to WASM from Rust, a registry for discovery, a placement engine that reads contracts and decides execution context, and a tracing layer that produces structured artifacts for every capability invocation.
Some things changed between the model and the implementation. The UMA model was more abstract about the capability format. Traverse committed to WASM and Rust because WASM gives the portability guarantees and Rust gives the performance and correctness properties you need for business logic. Other languages that compile to WASM can work; Rust is the first-class path.
The tracing layer was not heavily emphasized in UMA. It became critical in Traverse once AI pipeline use cases became real. When an AI agent calls a capability, you need a trace. Not a log entry. A structured artifact with the capability ID, contract hash, validated inputs, outputs, postconditions satisfied, and a reconstructable execution record. UMA did not anticipate AI agents as callers. Traverse does.
What the book covers
The UMA book is 13 chapters. It works through the problem from first principles: why existing microservices architectures struggle with the browser as a runtime, what portable capabilities actually require, how contracts enable governance across environments, and how the architecture extends to AI agent orchestration through what I called Contract-Driven AI Development.
The examples in the book are runnable Rust and WASM. Not pseudocode. Not diagrams with arrows. Actual code that compiles and produces the output described.
Where C-DAD fits in
Contract-Driven AI Development is the application of the UMA contract model to AI agent orchestration. It addresses a specific gap: function calling in AI systems gives agents the ability to invoke tools, but not the structured metadata needed to invoke them correctly, govern their side effects, or reconstruct their execution for audit.
C-DAD says: every tool an AI agent calls should be backed by a contract. The contract declares preconditions, postconditions, side effects, and failure modes. The runtime validates calls against the contract. Every invocation produces a trace artifact.
This is not primarily about safety in the existential sense. It is about building AI systems that behave correctly in regulated, consequential domains. Financial services. Healthcare. Legal workflows. Anywhere a wrong decision has a cost and "the model decided" is not an acceptable audit trail.
Traverse implements C-DAD by exposing governed capabilities as MCP tools. The MCP interface is the discovery and invocation layer. Traverse is the governance layer underneath it.
What Traverse actually ships that UMA specified
To close the loop: here is what exists in the Traverse v0.7.0 runtime that the UMA model specified as necessary.
- TOML-based capability contracts with typed inputs, outputs, permissions, and placement targets
- WASM module compilation from Rust with contract-enforced permission boundaries
- Capability registry for discovery by contract ID and version
- Placement engine that selects execution context based on contract targets and runtime policy
- Structured trace artifacts on every capability invocation
- MCP tool surface exposing governed capabilities to AI agents
- Offline-capable browser placement with cached WASM binaries
The model held up. The implementation took time and made specific bets that the model left open. WASM was the right bet. Contracts in TOML were the right bet. Tracing as a first-class concern rather than an afterthought was the right bet.
The question UMA started with, "why can't the browser be a first-class execution environment?", has an answer now. It can be. Traverse makes it one.