Validation
Input checks, constraint checks, and fail-fast rules should happen before side effects are allowed to begin.
What belongs in the runtime layer?
In UMA, the runtime layer owns the governed conditions around execution. The service keeps the durable business behavior. The runtime keeps the decisions that must remain visible when that behavior is validated, adapted, and allowed to run.
The short answer
The runtime layer should own validation, adapter selection, policy enforcement, lifecycle evidence, and the execution context around the service. It should not quietly become the place where the service’s core business rule is rewritten.
This distinction matters because many systems claim to preserve a portable service while still allowing runtime code to carry the rule that actually determines the outcome. Once that happens, the service boundary stops being the durable center of the architecture.
What should stay inside the service
The service should keep the business behavior that must remain semantically stable across hosts. That usually means rules, normalization logic, decision semantics, and the contract-shaped meaning of the result. This is the part of the system that portability is trying to preserve.
If the service boundary is clean, the same behavior can be tested, compared, and reasoned about without depending on one transport, one adapter, or one deployment surface.
What the runtime should own instead
The runtime should own the questions around the service rather than the rule inside it. Is the request valid? Which adapter is allowed to satisfy the capability? Which policy applies? Should execution fail fast before side effects happen? What evidence should be recorded so the run can be explained afterward?
Those concerns are not secondary infrastructure details. They are part of the architecture because they determine how the system turns portable behavior into governed execution.
Adapter binding
The runtime should decide which host capability or adapter implementation satisfies the requested behavior.
Policy and trust
Permissions, placement, trust boundaries, and environment-specific rules belong around the service, not inside it.
Lifecycle evidence
The runtime should keep enough observable evidence to explain what path actually ran and why.
Why fail-fast validation belongs there
One of the clearest runtime responsibilities is stopping invalid execution before the system causes side effects. If the runtime has enough context to know that a request is malformed, incompatible, or disallowed, the architecture is stronger when that rejection happens before the adapter path even begins.
This is not only about safety. It is about keeping the system honest. A runtime that validates too late often forces cleanup logic to carry architectural meaning that should have stayed visible from the start.
Why adapter binding should stay visible
Adapter selection is easy to hide in helper code, but that usually makes the architecture less legible. If a capability can be satisfied through different bindings or wrappers, the system is easier to review when the runtime owns that decision and records it explicitly.
That makes the system more explainable to both people and tooling. The service result can stay stable while the runtime still shows which adapter path actually participated.
Why lifecycle evidence matters
A runtime layer becomes much more valuable once it can show what happened instead of merely claiming success. Event ordering, binding records, validation failures, and final state markers help the architecture stay auditable instead of turning into an opaque control flow.
This does not require a heavy observability platform to matter. Even a small service becomes easier to trust when the runtime leaves behind enough evidence to prove which governed path actually ran.
What the runtime layer should not become
- It should not absorb the core business rule because the host code feels more convenient.
- It should not become a vague utility layer with hidden architectural decisions.
- It should not hide adapter choice when that choice affects trust, policy, or evidence.
- It should not wait until after side effects to perform validation it already knows how to do.
- It should not make the service boundary harder to see.
A practical design test
Ask whether your system can point to the exact place where validation happens, the exact place where adapter choice is made, and the exact place where execution evidence is recorded. If those answers are scattered across helpers and host-specific code, the runtime layer still exists, but the architecture has not owned it cleanly.
Another useful test is this: if the service behavior stays the same, can the runtime change validation rules, adapter wrappers, or lifecycle recording without forcing a rewrite of the core logic? If yes, the separation is probably healthy.
Frequently asked questions
Does the runtime layer replace the service?
No. The service remains the durable behavioral center. The runtime layer exists around it so execution conditions stay explicit instead of leaking back into the service logic.
Why not keep adapter binding inside the host application?
You can, but the architecture becomes harder to inspect. UMA is stronger when adapter choice is treated as a visible runtime concern rather than an implementation accident.
Is lifecycle evidence only useful in large systems?
No. It becomes more valuable at scale, but even a small service is easier to trust when the runtime can explain what it did and what it chose.
This page isolates one practical question the chapter sequence makes important: what the runtime should own once the service itself stays clean. In the book, I push that separation further into execution traces, adapter design, and the evolving responsibilities of the runtime as systems grow. On the site, the best next step is to connect this idea to the UMA runtime and to the runnable examples.