This is the seventh post in Problems Cotomy Set Out to Solve. This continues from Runtime Boundaries and Operational Safety . In the first six posts, I focused on how to keep UI behavior stable as systems grow: HTML and CSS boundaries, submission boundaries, screen lifecycle boundaries, state continuity boundaries, API protocol boundaries, and runtime boundaries. The goal there was predictability. Here, I want to move to a different question: who should decide business outcomes.
In many systems, this question is never stated directly. Decisions grow in the UI through convenience. Conditions spread through handlers. Authority moves without being named. At first, this feels practical. Later, the system cannot explain why two screens make different decisions for the same operation.
This is where separation of concerns stops being a naming preference and becomes an operational rule.
Introduction: Why UI Intent Matters
Most long-lived business UI breakdowns are not caused by missing features. They are caused by unclear responsibility. When screens own too much decision logic, each local optimization creates another private rule.
The symptoms are familiar:
You see error message policy differ by screen for the same domain failure, and validation decisions drift between create and edit pages. Over time, event handlers become the place where business decisions quietly accumulate.
That drift is not random. It appears when the role of the UI is undefined. So the core question is simple:
What should the UI actually do?
The answer in this series is simple: UI should declare intent for an operation, but not become the source of business authority.
Common Patterns Where UI Becomes Authority
Responsibility leakage usually looks reasonable in isolation. A developer adds one branch to improve user experience. Another branch is added for role-based visibility. Another one controls a transition based on a status. Soon, the screen is making decisions that belong to business logic.
Common patterns include:
It often starts with event handlers deciding whether an operation is allowed, then grows into UI branches that encode approval transitions. Role conditions end up implemented only in rendering logic, and success or failure policies quietly diverge by page.
Typical examples:
“Disable the submit button when stock is zero”. “Show this operation only for administrators”. “If approval stage is X, then do Y in this click handler”.
None of these are wrong as presentation concerns by themselves. The problem appears when the UI becomes the final authority for those rules. At that point, business decisions are no longer governed by a shared Operational contract. They are governed by whichever screen the user happened to use.
Intent vs Authority — Defining Responsibility
This distinction needs explicit terms.
Intent means the UI declares that a user wants to perform an operation. Authority means the business layer decides whether that operation is valid and how it should be handled.
UI owns intent. Business logic owns authority.
Intent says, “attempt this operation with these inputs.” Authority says, “this operation is valid under current business rules.”
If intent and authority are merged into one layer, the system loses a stable Structural boundary. It becomes difficult to keep every entry point aligned to the same rule set.
A practical framing is this: authority lives in backend business logic and its operation contracts. The UI communicates with that layer through explicit contracts, but should not replace it.
Concrete Failures of Blurred Boundaries
When UI holds authority, failure modes become systemic.
Boundary ambiguity spreads first. Business conditions appear in many screens, and rule changes require screen-by-screen patching. A single domain update becomes a UI migration problem.
At the same time, duplicated rule systems emerge. The UI applies one condition while the API applies another. Both look correct locally, yet they diverge over time. This creates hidden conflict:
UI says operation is invalid, API would accept. UI says operation is valid, API rejects with domain failure.
Testing quality also drops around decision logic. Business decisions encoded in handlers are hard to isolate. You can test click outcomes, but not authoritative rule behavior at the right abstraction level. Regression risk increases with each UI variant.
These are operational failures that appear when authority is assigned to the wrong layer.
Cotomy’s Position: UI as Intent Layer
Cotomy’s position is not that UI should be passive. It is that responsibility must be explicit.
The model is:
- UI declares operational intent
- Business authority is decided through business protocol and backend logic
- Runtime boundary preserves consistent execution semantics at the UI edge
This preserves intent handling in the screen while keeping authority in a single operational domain.
Cotomy’s architectural stance treats UI as intent and backend as authority (see Cotomy Reference – Overview ).
That model is what keeps the UI predictable without turning it into a decision engine.
Implementation Reality — How Cotomy Supports This
The implementation shape in Cotomy aligns with this boundary. No hidden authority transfer is introduced.
At a high level:
In the current implementation, form.ts centralizes submission entry through CotomyForm and related API form types. api.ts provides structured exceptions and response objects for failure handling. view.ts provides DOM-state handling, event registration, and lifecycle-related behavior.
What this means in practice:
UI collects values and declares an operation attempt. Operation outcomes are evaluated from API status and domain error responses. Runtime provides consistent structure for execution, not business judgment.
This is why the series has repeatedly emphasized boundaries. Cotomy does not position the UI as a business rule engine. It presents UI as an intent layer operating against explicit contracts.
In other words, the UI can validate usability and guide users, but final business acceptance should stay outside the UI layer.
Misunderstandings to Avoid
This boundary model is often misread. The following clarifications are essential:
UI-side validation still matters for usability and early feedback. This is not a backend architecture argument, and it also works with server-light or server-optional implementation patterns.
The point is responsibility separation, not feature prohibition.
UI validation remains useful for user guidance and early feedback. But authoritative acceptance criteria should remain in the business logic enclave so all operation paths remain coherent.
This is also not a claim that every app must adopt one technical stack. The model is architectural: intent boundary in UI, authority boundary in business logic, and runtime structure between them.
Conclusion: Operational Safety Through Responsibility Separation
Operational safety is not achieved by adding more checks to every screen. It is achieved by assigning the right layer to the right responsibility.
The UI should express intent clearly. The business layer should decide authority consistently. The runtime should preserve a predictable execution boundary between them.
That is the practical meaning of Intent vs Authority. It is also the reason this series moved from local UI structure to operation protocol and runtime boundaries.
When intent and authority are separated, change remains tractable. When they are merged, behavior drifts and trust erodes.
Cotomy’s contribution is not “automatic business logic.” It is architectural discipline: clear Separation of concerns, a stable Structural boundary, and a runtime model that keeps UI behavior aligned with operational contracts.
Problem Series
This article is part of the Cotomy Problem Series, which examines recurring structural failures in business UI design.
Series articles: HTML and CSS as One Unit , Form Submission as Runtime , Screen Lifecycle and DOM Stability , Form State and Long-Lived Interaction , API Protocols for Business Operations , Runtime Boundaries and Operational Safety , UI Intent and Business Authority, and Binding Entity Screens to UI and Database Safely .
