Does proposing an interface grant permission to act?

AI can suggest a screen’s layout, the information to display and the actions to offer. Implementing the suggestion, establishing the data’s accuracy and authorising an operation require separate decisions. How do I approach this boundary in Muhit?

Imagine that we want to review a research note. We ask the system for a view that brings the sources together and shows what is missing.

The model suggests a summary, a source table and a few actions. The screen might include buttons such as “Review note”, “Apply correction” or “Publish”.

So far, what has been proposed is a workspace. But once the buttons become visible, other questions arise: Which record will change? Who will be able to change it? How will the user’s choice be understood? When the operation finishes, on what evidence will we say so?

In Muhit’s work on AI-generated interfaces, I want to keep these questions from remaining unresolved behind the screen.

A suggestion needs an understandable form

Starting from a user’s request, a model can suggest which pieces of information would make sense together. It can divide a long answer into sections, arrange records in a comparison table or describe a form for fields that need editing.

This is useful especially for content whose presentation has not yet been decided. As the need changes, the view can change too.

Muhit’s JSON interface adapter is the layer that turns such a suggestion into defined components. The application owns the model connection; the adapter contains no model running on its own or autonomous operation service.

The incoming definition is validated first. Component types, required fields and supported values are checked. A valid definition is rendered using the allowed components.

The model’s proposed view therefore enters a space of expression defined in advance by the application. The definition cannot carry arbitrary code or permission to perform an operation.

But we need to understand what this validation actually tells us.

A correctly structured heading does not establish the truth of the claim beneath it. A table made of valid rows does not prove that its records are current. An action appearing in a definition does not mean that performing it is permitted.

A valid interface definition cannot, on its own, decide whether content is true or an operation is authorised.

In the research-note example, the application must therefore also make clear where the sources came from, which version they belong to and which information is the model’s interpretation. An orderly screen should not stand in for these distinctions.

The path from a button to a real operation

In Muhit, a card action can send the application an event carrying the component and action identifiers. The application maps that event to behaviour it recognises.

For example, “Review note” might open the details of a record designated by the application. The adapter does not read the action’s name and independently generate an address, save data or start publication.

This boundary has a practical consequence: a model labelling a button “Publish” does not give the application a new publishing capability. The application must recognise the operation, determine which record it applies to and check the necessary permissions.

A publishing application could establish this path as follows: the user reviews the proposed change, the application shows the affected record and scope, and the server checks permission and the record’s current state. Success is reported after the actual operation returns its result.

This flow is not a publishing system that Muhit provides on its own. It is an example of application behaviour that could be built with Muhit’s components.

There is also a distinction between an event and user intent. An event arriving from a component is not, by itself, proof of an authorised human command. Some state events can also result from changes made by application code. The presence of an event handler does not replace identity and permission checks.

Tying authority to the visibility of a button is therefore insufficient. Permission must also be evaluated at the layer where the operation is performed.

In the second essay, I discussed the distinction between local confirmation and persistent storage. The same principle applies here: the result reported by the interface should describe the scope of what actually happened.

Human control begins with understanding

It is easy to reduce control to a confirmation button. But if someone cannot understand what they are approving, having the button is not enough.

In the research-note example, the proposed change should be visible before choosing “Apply correction”. Which sentence is changing? Does the change rely on a source, or does it come from the model’s interpretation? Which version of the current text is being used?

This information forms the context of the decision.

An interface that preserves human control should keep open the paths for reviewing a suggestion, changing it when needed and deciding against it. Rather than asking for equally weighty confirmation for every operation, we need to consider control in proportion to its consequences. A filter that narrows a view and an action that changes published text have different effects.

A new suggestion from the model should not break this continuity either. If the screen is rebuilt while someone is editing a field, what happens to their writing should be decided in advance.

Muhit’s adapter preserves the current view when an update is invalid. A successful update rebuilds the view; the previous table’s filters and selection are not carried over automatically. If user state needs preserving, the application must manage it separately.

This technical detail directly concerns human control. Users should be able to distinguish their own changes from the model’s new suggestion and return to the work they started.

This is the boundary I am trying to establish in Muhit: define the model’s space for suggestions clearly, while keeping the application’s responsibility and the human decision visible.

Being able to generate a screen is a significant possibility. Using it with confidence depends on understanding the path from suggestion to actual outcome.

When someone can say, “The system suggested this; I changed this part; I chose this operation; this result actually happened,” the interface makes room for creation while preserving the trace of the decision.

---

Source: Muhit’s JSON interface contract and the design principles in the local development source. The research note and publishing flow are illustrative scenarios used to explain responsibility boundaries.

Previous Muhit essays: Muhit: What makes an interface consistent? · Muhit: How does a design decision work on screen?

Atlas concepts: Design · Software · Context · Systems · Intelligence