In this section: Discovery and References
UMA Glossary
Definitions for core Universal Microservices Architecture terms. Each entry answers the definitional question directly so architects and engineers have a shared vocabulary when reading the book, working through the examples, or applying the model to their own systems.
A
- Active descriptor
- Structured metadata the runtime reads before making an execution decision. not documentation beside a service. A descriptor declares input schema, output schema, emitted events, placement targets, version constraints, and evidence expectations. If any check fails, the runtime rejects the path with a specific reason. Because the descriptor constrains rather than informs, drift is detectable before production, not after an incident.
- Active runtime governance
- Per-execution enforcement of policy, trust, and compatibility constraints by the runtime layer. Governance is "active" because it applies at every invocation, not just at deployment. For any specific run, the runtime can explain why a capability was allowed, denied, or rerouted. That record exists as inspectable evidence after the fact.
- Adapter
- A runtime-provided binding that connects a portable service to a concrete host without changing the service's business logic. Adapters handle transport, protocol translation, and credential injection. Because adapters live in the runtime layer (not inside the service) the same service works across different hosts by swapping adapters, not by forking the code.
- Adapter binding
- Attaching an adapter to a portable service at runtime, not at build time. Because binding happens during the execution decision, one compiled artifact can run in different environments. The active descriptor declares what the service needs. The runtime resolves which adapter satisfies those needs in the current context.
B
- Behavioral coherence
- The property of a system where the same business rule produces equivalent outcomes across all execution surfaces. A behaviorally coherent system can have many runtimes and deployment targets. What it does not have is multiple diverging copies of the same rule drifting apart over time. UMA treats behavioral coherence as an explicit architectural goal, not an assumption.
- Behavioral equivalence
- A narrower claim than behavioral coherence: identical inputs should produce identical outputs when the same portable service runs in two different runtimes. Behavioral equivalence is testable through parity proofs that run the service across environments and compare results. It is the concrete, measurable form of what "portable behavior" means in practice.
C
- Capability
- The unit the runtime can discover, validate, and compose into a workflow. A capability is a named piece of behavior with a visible contract: input schema, output schema, version, placement rules, and events it emits or requires. The runtime selects, rejects, or chains capabilities based on declared contracts. not implicit knowledge of their internals.
- Contract
- The explicit declaration of what a service expects as input, produces as output, emits as events, requires as permissions, and leaves as execution evidence. In UMA, a contract is machine-readable and runtime-evaluated. not a human-readable agreement between teams. Contracts are what make portability verifiable rather than assumed.
E
- Execution context
- The full set of runtime conditions for a single execution: host capabilities available, trust policy in effect, identity and permissions granted, and placement constraints applied. Two runs of the same service in different contexts may use different adapters, trust levels, and latency profiles. but the business behavior inside the portable boundary stays the same.
F
- Feature flag evaluator
- A concrete portable service used throughout the UMA book and examples. It takes a flag key and evaluation context as inputs and returns a boolean or variant result. It is deterministic, stateless, and free of runtime-specific dependencies, which makes it an ideal first portable service. Chapter 4 runs it as a WASM module with an active descriptor, identically in native Rust and in a WASM host, without changing the compiled artifact.
G
- Governance layer
- The part of the runtime responsible for policy, trust, versioning, and audit. It sits between the external request and the portable service. It evaluates active descriptors, enforces trust boundaries, records execution evidence, and rejects paths that violate declared constraints. Separating governance from business logic lets you change policy without touching the service and audit decisions without relying on the service to report them.
H
- Host environment
- The concrete runtime that executes a portable service: a browser, an edge worker, a server running wasmtime, a Kubernetes sidecar, or an AI-adjacent workflow engine. The host supplies capabilities through adapters and WASI interfaces. UMA's portability goal is that the host can change without requiring the service to change. as long as the host satisfies the service's declared contract.
P
- Parity proof
- Evidence that a portable service produces equivalent outputs across two or more execution environments. A parity proof runs the same service with the same inputs against different hosts (for example, native Rust and a WASM runtime) and compares outputs and observable side effects. Chapter 6 of the UMA examples is structured as a parity proof. Portability that is not proved is an assumption.
- Portable behavior
- Business logic that is expressed once, carries an explicit contract, and runs in more than one host environment without being reimplemented or forked. The test of portable behavior is not that the code compiles in multiple places. It is that the same artifact produces equivalent outcomes across environments and that a parity proof exists to confirm it.
- Portable service
- A service whose business behavior stays stable across execution environments. It carries an explicit contract, has no hidden runtime dependencies, and can be verified through parity proofs. A portable service is not tied to a specific framework, queue, or host assumption. In UMA, portable services are the durable center of the system. the runtime layer handles everything that varies by environment.
R
- Runtime diversity
- The ability to run the same portable service across structurally different host environments ( browser, edge, server, workflow engine) without splitting business behavior into separate implementations. Runtime diversity is an architectural goal in UMA. The system should be able to add or change execution targets without triggering behavioral drift.
- Runtime layer
- The governed infrastructure around a portable service that handles validation, adapter binding, placement decisions, trust enforcement, and execution evidence. The runtime layer owns everything that varies by environment. the service owns the durable rule. That separation lets you move a service to a new host without rewriting the business logic and audit execution decisions without instrumenting the service itself.
- Runtime placement
- The runtime's decision about where a portable service should execute for a specific request: browser, edge node, backend server, or workflow engine. The decision is governed by the service's declared placement constraints, the trust policy in effect, latency requirements, and host capabilities. Moving placement decisions into the runtime layer (rather than hardcoding them in services) is one of UMA's structural contributions.
S
- Service boundary
- The declared edge of a portable service's responsibility: what it accepts as input, what it produces as output, and what it does not own. In UMA, a service boundary is expressed through the active descriptor. not through implicit code-level coupling. A well-drawn boundary lets the runtime validate compatibility, compose services into workflows, and detect when one service's change would break another.
U
- Universal Microservices Architecture (UMA)
- An execution model for distributed systems that keeps business behavior portable across multiple environments (browser, edge, cloud, workflow, and AI-assisted paths) while runtime governance, contracts, trust, and placement stay explicit. UMA splits responsibility in two: the portable service owns the durable business rule, and the runtime layer owns everything that varies by environment. The goal is behavioral coherence across runtimes without duplicating logic across surfaces.
W
- WASM component model
- A typed interface layer on top of core WebAssembly modules, stabilized alongside WASI 0.2. Components define imports and exports using WIT (WebAssembly Interface Types), which supports records, variants, options, lists, and streams. Two components that agree on a WIT interface compose at the binary level with no serialization boundary. For UMA, this means service contracts are machine-readable, version-aware, and embedded in the compiled artifact itself.
- WASI (WebAssembly System Interface)
-
A standardized, capability-gated interface that gives WASM modules access to host resources (
clocks, file descriptors, network sockets, and HTTP) without embedding host-specific code in
the module. WASI 0.2, stable since February 2024, introduced the Component Model and added
wasi:http, making server-side WASM practical for real workloads. The host decides which WASI capabilities to grant at startup. the module can only use what it explicitly receives. - Workflow
- The execution path the runtime approves from one or more capabilities to satisfy a goal. A workflow in UMA is not handwritten orchestration glue. It emerges from declared events, subscriptions, capability contracts, and placement policy. The runtime can explain why that path was chosen, which capabilities participated, and what evidence the run produced.
This glossary captures the shared vocabulary. The pages below explain each concept in its full architectural context, with runnable examples where the idea matters most.