Policy-Controlled Automation: Approval-Gated Execution

“Improve the product data” is a goal, not permission to overwrite a catalog. A usable action policy identifies the destination account, permitted products, fields, allowed change types, and required source evidence. Each proposed action must satisfy that policy.

Governance rules can define permitted change types, such as a factual description correction rather than a price change. But a policy description is not evidence that a particular product supports unattended execution. In Paz, Routines save recurring checks; a custom Routine agent cannot change products on its own. Product changes use the required draft approval and supported destination workflow.

1. Proposed action: the exact records and values are identified with evidence.
2. Authorization: the action satisfies the configured approval policy and permissions.
3. Execution: a supported workflow attempts the destination update.
4. Acceptance: destination processing and readback establish what changes.
5. Outcome: a separate measurement checks issue clearance or the business goal.

These are verification criteria, not interchangeable status labels. A destination rejection, changed source value, or invalid field can prevent an authorized action from succeeding. Retain the failure reason and prevent repeated attempts that ignore the unresolved cause.

A workflow proposes adding “750 ml” to a bottle description. The policy permits the description field for that product collection and requires agreement between catalog and product-page specifications. If the sources conflict, the affected change stays blocked. Neither a missing price nor an inferred insulation duration belongs in this correction.

The task specification defines the goal and the business context supplies relevant priorities and constraints. Neither replaces destination permissions or required approval. A shared follow-up retains investigation evidence and next checks; a question answered in Inbox supplies context, not authorization to publish. An agent payment mandate is different: it concerns a shopper authorizing a purchase, not a merchant changing product data.