An answer is not a completed action

A proposal expresses what should be done. Authorization determines whether the operation is allowed for the present actor and task. Verification checks whether a meaningful postcondition actually holds.

The model can assist with the proposal. It does not create permission by being persuasive. And a tool returning HTTP 200 is not always enough to prove the business operation succeeded.

A purchase order may be prepared without being submitted. A payment may be recommended without being executed. An invoice may be found but not corrected.

Interfaces must name these distinctions precisely. 'Draft prepared' and 'Order updated' are different claims. The second needs a stronger receipt and usually a read-back against the system of record.

This is especially important when a product introduces generated interfaces: a visually polished confirmation is not evidence.

A durable work record should retain references to observations, validations, authorizations, meaningful actions and verification outcomes. A later reviewer should be able to ask why the system reported success.

Not every low-risk action warrants the same overhead. Opening a table is different from changing a payment destination. The verification bar should rise with impact.

A task is done when its requested output or postcondition has been satisfied to the appropriate evidence standard, not when the model writes a confident final paragraph.

If a dependency is still pending, the truthful state is pending. If the attempted write was denied, the truthful state is blocked. If only part of the work succeeded, the record should stay partial.

The cost is more state and more checks. The benefit is that an assistant can be treated as part of a business system rather than a persuasive narrator.

Take an order whose delivery date needs updating. A model may correctly identify the desired date, a tool may accept a request, and the business record may still not show the change. The request could have created a draft, been queued for approval, failed asynchronously or conflicted with a later edit. Each state warrants a different user-visible message.

A durable action record should connect the intent to a specific target, principal, authorization decision and operation receipt. Verification should compare the observed postcondition with the requested change, preferably through a fresh authoritative read. For a pure analysis task, a sourced report may be the postcondition; for a business mutation, a nice-looking report does not suffice.

This is not about demanding a heavy audit protocol for every click. A harmless view preference needs far less scrutiny than an invoice submission or supplier bank-detail change. The verification bar ought to scale with potential impact.

A denied action is not a failed model. The system may understand the request perfectly but lack authority to carry it out. A missing capability is different again: no permitted operation exists in the connected provider. A stale observation means the model reasoned from a previous world state. And a partial effect means some requested steps completed while others did not.

Collapsing these into a single 'something went wrong' error prevents useful recovery. A permission failure should surface a legitimate approval path, not trigger a larger model. Missing capability may require a provider or integration change. A stale record demands a new read and perhaps a new decision. Partial effects require reconciliation before retrying.

The same distinctions matter during wake/resume: a permission held before an external wait may no longer be valid after the event arrives.

Operational explainability should let a reviewer reconstruct the meaningful chain of evidence and business operations without pretending to reveal a model's private reasoning. Which record was inspected? Which fact justified the proposed transition? Who authorized it? What operation ran, and what postcondition confirmed the result?

This causal trail is not equivalent to dumping prompts and traces into a dashboard. Evidence identifiers, outcomes and status transitions have a different role from debug information. They should remain meaningful even if the language model or orchestration implementation changes.

These principles are a vNext design direction; a write-shaped capability contract in Artemis should not be mistaken for unrestricted live ERP mutation. The architecture discussion is available at https://github.com/sarooo17/artemis-architecture/blob/main/docs/07-AUTHORITY-AND-VERIFICATION.md.