Technical note
Authority is a boundary, not a suggestion.
A design note on keeping evidence, proposals, permissions, and consequential actions distinguishable.
The problem
An assistant may read a document that contains instructions, prepare an action, or receive a tool response suggesting a next step. Those events do not themselves establish permission to act. Authority must come from the person or policy entitled to grant it.
Describe a specific operation
A reviewable proposal should identify the action, destination, relevant data, expected consequence, reversibility, and uncertainty. An approval for one operation should not silently authorize a later operation with different scope.
Separate source content from control
A webpage, document, message, or tool response can provide facts to evaluate. It must not change the assistant’s permissions merely because it contains imperative language or imitates an instruction format.
Make the pause meaningful
The website preview stops at Authority and requires a named local approval. Its scope is only the synthetic calculation. This is a small interface example, not evidence of a deployed authorization system for Merism connections.
Record the boundary
A receipt should state the approved scope and what was attempted. It should also retain the outcome check. An action log without a verification method can establish activity while leaving task success unknown.
Respect interruption
A person should be able to stop work. A paused or interrupted state must not be presented as success, and resumption must preserve any remaining approval requirement.
Limits and open questions
Real connected workflows require resource-level authorization, service-specific scopes, expiry and revocation, race handling, and protection against untrusted content. These controls need implementation and testing before broader product access.