Authority, approval and recovery
Proposed execution contract; unimplemented. These are product requirements to prove, not assurances about the current platform.
The merchant should approve concrete changes, and the system should enforce that approval independently of what the model says. Approval is a scoped authorization, not a conversation sentiment such as “looks good”.
Initial permission model
| Operation | Pilot rule |
|---|---|
| Read allowed product and stock fields | Available after connection consent; shop/role scope enforced on every request |
| Read order status | Minimized fields; respect staff permissions and hide unnecessary customer details |
| Prepare a draft or suggested action | Allowed; no external side effects |
| Change existing base prices | Explicit approval of a bounded, versioned job; additional per-row constraints enforced |
| Publish product copy or change inventory | Not enabled in the first paid workflow |
| Refund, delete, mark shipped, send customer messages, change taxes or credentials | Not exposed as executable MVP tools |
| Recurring automatic writes | Later opt-in, only after a job type and its recovery have been validated |
Reading is not risk-free: order data and credentials still require isolation and access controls. Untrusted descriptions, files and tool output are data, never instructions that may widen permissions.
The execution lifecycle
Draft → validated proposal → approved version → executing → verified receipt. Branches include rejected, expired, cancelled, blocked, partially completed and pending reconciliation.
The approval binds shop, actor, exact item IDs, before/after values, currency, tax basis, formula, limits and expiry. Changes invalidate approval. Immediately before applying each item, check permissions, current values and expiry again. A durable operation key must identify the intended mutation across retries.
The connector must enforce conditional writes where possible. A check followed by an unrelated write is not enough when another admin or feed can intervene. Test platform hooks, database transactions and competing writers on the supported version. If reliable conflict detection cannot be provided for a write type, do not enable that write type in the pilot.
Failure behavior is part of the product
| Event | Required behavior |
|---|---|
| Supplier SKU maps to multiple products | Request a decision or exclude the row; never guess a write target |
| Admin or ERP changed the price after review | Skip as a conflict; a replacement proposal needs fresh approval |
| Timeout after sending a write | Mark uncertain, reconcile using the operation record and a fresh read; no blind replay |
| Some rows succeed and others fail | Preserve per-row state; offer retry only for appropriate unresolved rows |
| Owner presses Stop | Cancel queued items and stop scheduling new mutations; reconcile any in-flight request |
| Credential revoked or scope narrowed | Fail closed on subsequent operations; preserve the historical receipt |
| Connection stale | Display last successful read; do not present cached values as current |
What undo can mean
A compensating price change may restore a previous value only if the live value still equals the value this job wrote, the same permission exists and the merchant approves the compensation. A later manual change must never be overwritten by “undo”. Previously placed orders, sent messages and downstream effects cannot be erased by restoring a field.
Audit and information handling
Record the input reference/checksum, mapping version, proposed diff, policy result, approval identity and time, attempts, platform responses and read-back values. Keep secrets out of prompts and receipts. Minimize customer fields before model access; choose retention, deletion/export behavior and model-provider data handling before pilot onboarding.
Use tenant isolation tests, bounded file sizes, request limits and an allowlisted store connection. A failure to reach a store must not trigger unrestricted browsing, direct SQL writes or a fallback to an administrator password.
The full implementation proposal assigns enforcement to the execution service and connector, rather than to a prompt.