Projection is useful, not authoritative
A local surface may expose likely capabilities and constraints, but it should not pretend it owns final approval.
What makes a decision discoverable?
A decision becomes discoverable when the system can expose how it reached an outcome instead of only reporting that the outcome happened. In UMA, that means intent, authority, revision, execution, and trace all become first-class architectural surfaces.
The short answer
A discoverable decision is one a person or tool can inspect before and after execution. The system should be able to show the proposal, the constraints it could not resolve locally, the authoritative validation response, the approved path, and the resulting trace artifacts. Without those surfaces, a runtime may still work, but its decision model remains hidden.
This is the step where UMA moves from governed execution into understandable execution. It is not enough for the runtime to know why something happened. The system has to make that reasoning legible.
Why execution alone is not enough
Many systems can execute correctly while keeping the actual decision path buried inside code, logs, or implicit behavior. A request succeeds, but no one can tell what alternatives were considered, what assumptions were made at the edge, which constraints forced a revision, or why the final path was approved. The system acts, but it does not explain itself.
Discoverability matters because hidden decision paths turn architecture into folklore. Once the reasoning behind a runtime outcome is no longer inspectable, teams have a much harder time reviewing changes, debugging surprising behavior, or safely extending the system.
Proposals should declare assumptions
The system becomes easier to reason about when unresolved constraints stay explicit instead of being hidden in optimistic planning.
Validation should return guidance
Authority is more useful when it explains why a proposal failed and what would make it valid.
Trace completes the story
A successful execution is not fully discoverable until the approved path can be replayed as evidence afterward.
What discoverability looks like in practice
A discoverable system usually reveals a ladder of decision surfaces. First it exposes a capability projection or local view of the likely path. Then it emits a proposal that declares assumptions. Next, authority validates that proposal and returns structured feedback. If revision is needed, the revision stays bounded and inspectable. Once approval happens, execution follows the approved intent instead of silently replanning it. Finally, the trace shows enough evidence to explain the outcome after the fact.
That ladder matters because it separates useful local reasoning from final authority. Edge planning can still be helpful, but it becomes much safer when it no longer pretends to be the last word.
Why bounded revision matters
Many systems become hard to understand because validation and planning collapse into endless negotiation. Each side keeps revising the plan until execution finally happens, but no one can explain where the decisive authority really lived. UMA is stronger when revision stays explicit and bounded.
Bounded revision keeps the architectural roles clearer. Proposal stays proposal. Validation stays authority. Execution stays the resolution of approved intent, not a last-minute improvisation.
Why trace artifacts matter more than logs
Logs are often chronological but not architectural. A trace artifact is stronger because it tells the decision story in terms the model itself understands: what was proposed, what was rejected, what was revised, what was approved, and what executed. That makes post-execution review much more practical.
The difference matters for trust, governance, and change review. Teams can audit logs forever and still miss the actual architectural question. A structured trace turns the decision into something queryable instead of something merely recorded.
What makes a discoverable decision stronger than a hidden one
- The system can distinguish proposal from approval.
- Constraint failures are explicit enough to be acted on.
- Revision is limited and inspectable instead of endless.
- Execution resolves approved intent rather than silently changing it.
- Trace artifacts make the final path understandable after the fact.
Frequently asked questions
Is discoverability the same as observability?
No. Observability helps you inspect runtime behavior. Discoverability is narrower and more architectural. It is about whether the system exposes its decision path in a structured, queryable way.
Does every UMA system need the full decision ladder?
Not always. Smaller systems may not need explicit proposal and revision stages yet. The important part is that authority and execution still remain visible once decision complexity starts to grow.
Why not just let the planner decide everything?
Because proposal usefulness and execution authority are not the same architectural role. When they blur together, systems may look smart while becoming harder to govern.
This page names the structure. In the book, I take it further into runnable decision ladders so the difference between a hidden execution and a queryable decision path becomes concrete. On the site, the best next move is to connect this page to runtime authority, workflows, and the live reference application.