Compare results
Use the same contract and input, then compare the resulting behavior across runtimes.
How to prove portability
Portability is easy to claim and harder to prove. In UMA, portability becomes credible only when the same service behavior can be observed across more than one runtime target without quietly changing its meaning.
The short answer
You prove portability by comparing observable behavior, not by trusting shared source code or similar intent. If two runtime targets emit the same governed result from the same contract and input, portability is becoming evidence instead of a slogan.
That comparison matters because many systems look portable in code review while still drifting in execution. The only honest test is what the system actually does.
Why shared code is not enough
Shared code can be a useful starting point, but it does not prove the behavior is stable once the code is compiled, hosted, and run under different runtime constraints. Subtle host assumptions, missing capabilities, data-shape drift, and adapter shortcuts can all change the outcome while leaving the codebase looking deceptively aligned.
That is why UMA treats portability as something to validate from outputs, events, and contract-governed results instead of something to assume from a familiar repository structure.
What to compare instead
The most useful comparison point is observable behavior. That can mean a shared result payload, an emitted event, a stable output shape, or another contract-visible artifact that shows the service behaved the same way under two runtimes.
Once the comparison becomes observable, portability stops being an abstract architectural virtue. It becomes something a reader, a reviewer, and a runtime test can all evaluate directly.
Keep differences visible
Target-specific capabilities should stay explicit instead of leaking into the portable path unnoticed.
Trust emitted evidence
Event streams, payloads, and digests make parity easier to inspect than implementation claims alone.
Let the contract lead
Portability is more credible when the same contract governs both targets without hidden forks.
Why observable parity matters
Observable parity is stronger than “both implementations look similar.” If two runtimes converge on the same contract-shaped result, the architecture can point to something concrete. If they do not, the system has already learned something valuable: where portability breaks and which boundary is not as durable as it seemed.
That is one reason Chapter 6 matters so much in the learning path. It turns portability from a design preference into a test that can pass or fail in public.
Why target-specific behavior should stay explicit
Proving portability does not mean pretending every runtime should behave identically in every respect. Some capabilities are inherently target-specific. The important point is that those differences stay visible and do not contaminate the portable behavior being compared.
A good portability test therefore has two layers: the shared behavior that should stay aligned, and the runtime-specific behavior that should remain explicit as a governed difference rather than a hidden divergence.
How portability usually gets overstated
Teams often overstate portability when they stop at “the same logic compiles” or “the implementations are based on the same design.” Those are encouraging signs, but they are not enough. Portability becomes trustworthy only when the system can show that the actual behavior stayed aligned under real execution.
Another common mistake is to ignore the runtime-specific paths that do differ. That weakens the claim because it blurs the line between portable behavior and host-only extensions. UMA is clearer when both are visible.
A practical portability proof checklist
- Use one explicit contract across the runtime targets you are comparing.
- Run the same service behavior with the same relevant input.
- Compare observable outputs or events rather than source structure.
- Make target-specific capabilities visible instead of hiding them.
- Record enough evidence to explain why parity passed or failed.
Frequently asked questions
Does portability require byte-for-byte identical execution?
No. What matters is that the portable behavior stays semantically aligned. Some runtime-specific details may differ, but the business result being protected should remain stable.
Why compare events or payloads instead of internal code paths?
Because emitted results are what the architecture can actually prove. Internal similarity is informative, but it does not settle whether the system behaved the same way in practice.
Can a portability check fail and still be useful?
Yes. A failed portability check is still valuable because it shows exactly where the architecture is not yet as runtime-agnostic or contract-disciplined as it claimed to be.
This page gives the test, not the whole runtime story around it. In the book, I go further into how portability checks change the way teams reason about service boundaries, execution targets, and confidence. On the site, the best next step is to connect this idea to portable services, the runtime layer, and the runnable examples.