Human Approval Is a System Boundary

A recommendation is not an authorization

AI systems can rank options, draft actions, or assemble context. None of those steps establishes a right to change a record, move money, send a message, or deploy code. Authorization requires an accountable decision within the rules of the system and the organization that operates it.

The interface should make this distinction visible. A user needs to know whether they are reviewing a proposed action, approving a specific packet, or observing a result after execution. Combining those states in one vague confirmation button creates risk for both the user and the system owner.

• Bind approval to a specific actor, action, target, and relevant context.
• Show denial and unknown outcomes as first-class states.
• Expire or invalidate approval when its underlying action changes.

Policy should be deterministic where it matters

Consequential actions benefit from policy that can be evaluated consistently and explained after the fact. A policy decision may allow, deny, or require more review based on the action and its context. The important point is that a model's interpretation does not silently substitute for the governing policy.

LNSAT's public pre-release material describes exact packets, deterministic policy, scoped approval, one-time authority, receipts, and reconciliation. It is public source-level evidence for this design direction, not a statement that every possible action can be dispatched or that a hosted runtime is available.

• Keep policy inputs explicit and versioned.
• Record the approval scope and the decision result.
• Require reconciliation rather than assuming a request completed.

People retain consequential decisions

Human approval is not a bottleneck to be designed away. It is a deliberate boundary for actions that have legal, financial, security, or operational consequences. The right interaction gives a responsible person the context needed to decide, preserves what they approved, and makes later review possible.

For lower-risk automation, teams can still use bounded rules and clear rollback paths. The decision is proportional to the consequence, not a claim that all automation is unsafe.