Documentation
Documentation/Core concepts

Governed actions

Turn a proposed decision into an explicit, reviewable change to a source system.

On this page

Define the capability

An action type describes a permitted operation and its parameters. The supported executors are a declared SQL update and a call to a live, governed function. A function is a reference to an implementation operated by the organization; its behavior remains the responsibility of that implementation.

Author the definition as a draft, review its target and mutation contract, and promote it through the catalog gate. A visible action definition is a description of a capability, not permission for every reader to invoke it.

Separate proposal, approval, and execution

Permission to invoke an action and permission to approve a proposal are separate. An action's policy determines whether execution may proceed automatically, supports the applicable undo path, or requires approval. Approval policies can require an independent approver or an interactive human session.

An invocation records one request and its outcome. Creating a proposal is not an approval; an approval is not evidence that the source write succeeded. Follow the invocation through to its execution result.

Review a decision

Open Decisions for requests directed to you. Read the context, target, parameters, and available options before deciding. Current authority is checked again when a proposal is approved and when queued work executes.

For object-action proposals submitted by external agents, the request must identify an existing readable object, its exact natural key, and the current action version. Function-backed proposals also pin the function version. These proposals always create a human decision card through the shared agent interface.

  • Check that the target is the intended object.
  • Review the proposed values and the operation they will trigger.
  • Confirm the current version and required approval policy.
  • Inspect the final outcome before treating a change as complete.

History and recovery

nondro records mutations and audit events together in its control-plane transaction. Source operations retain their execution status so teams can distinguish a failed attempt from completed work.

Undo is available only for supported, configured operations. It is not a universal rollback for arbitrary code or external side effects. Review the action's recovery behavior when designing the workflow, particularly when a function touches more than one system.