Focused capability boundaries
Capabilities should be meaningful enough to govern without being split into tiny steps that add more complexity than value.
What makes a system coherent?
A UMA system is coherent when its runtime behavior still reflects the architectural model it claims to have. That is a higher standard than simple functionality. A system can work and still be architecturally unclear, fragile, or misleading.
The short answer
Coherence means the system’s boundaries, events, metadata, capability choices, and runtime decisions reinforce one another instead of fighting each other. The architecture stays easier to explain because the runtime outcomes still match the declared model.
That is why Chapter 10 matters. It pushes the conversation beyond “did the workflow finish?” and toward “what kind of system did these decisions create?” In UMA, that difference is where architectural quality becomes visible.
Why functionality is not enough
A system can produce the expected output while still accumulating architectural damage. It may split behavior into too many capability fragments, hide meaning inside vague events, let runtime selection become ambiguous, or pile orchestration logic into metadata that no longer clarifies anything. None of those problems necessarily causes an immediate failure.
That is exactly why coherence matters as its own topic. It gives teams a way to talk about whether the architecture is staying healthy, not only whether the current scenario happened to complete.
Where coherence becomes visible
In UMA, coherence becomes visible in runtime behavior. Which capability was selected? Why was it selected? Do the event names still reflect stable domain meaning? Is metadata clarifying the flow or bloating it? Can the system explain the path in a way that still matches the intended architecture?
Those questions matter because diagrams alone can hide degradation. The runtime outcome is often where the real architectural tradeoff finally becomes obvious.
Stable event semantics
Events should describe durable domain facts, not vague workflow hints that only local code can interpret.
Deterministic runtime choices
When multiple paths exist, the system should still explain why one was chosen and under which declared conditions.
Metadata with purpose
Metadata should clarify compatibility and governance, not become a dumping ground for hidden orchestration detail.
What makes a system drift away from coherence
Several patterns create drift quickly: over-granular capability splits, hidden event coupling, runtime ambiguity, and over-orchestrated flows that try to control every step centrally. Each one can still look justified locally. Together they make the architecture harder to reason about and harder to repair.
Coherence is often lost gradually. That is why runtime-visible tradeoffs are so useful. They show where the system stopped matching its own architectural story before the damage becomes too expensive to reverse.
Why recovery matters as much as diagnosis
A good architecture page should not only help a reader spot what is wrong. It should also help them see what recovery looks like. In UMA, recovery usually comes from clearer constraints, sharper capability boundaries, more stable event meaning, and runtime rules that reduce ambiguity instead of layering on more complexity.
That is a healthier model than assuming every problem can be solved by adding more orchestration or more services. Sometimes architectural repair is really about removing noise until the runtime can be authoritative again.
A practical coherence test
Ask whether the system can explain a runtime outcome in the same terms the architecture uses to describe itself. If the runtime says one thing and the architecture slides say another, coherence is already weakening.
Another useful test is whether the recovery path becomes simpler or more complicated. If every fix adds more indirection, more orchestration, and more metadata without restoring clarity, the system is probably becoming merely functional rather than more coherent.
Frequently asked questions
Can a system be functional but not coherent?
Yes. That is exactly the point of this concept. A system may still produce the right output while becoming harder to explain, govern, and evolve safely.
Does coherence mean fewer services?
Not automatically. The issue is not service count by itself. The issue is whether boundaries, events, metadata, and runtime choices are still making the architecture clearer or only more fragmented.
Why is this a runtime question and not only a design question?
Because runtime outcomes expose tradeoffs that static structure can hide. Coherence becomes easiest to judge when the system has to act, select, emit, and explain itself.
This page gives the standard, not every tradeoff that can challenge it. In the book, I take the idea further through concrete degraded and recovered designs so the difference between “working” and “coherent” becomes much more practical. On the site, the next useful move is to connect coherence to orchestration, graph evolution, and runtime authority.