Skip to main content
You connected an AI assistant to Hoard. You’re sitting on the defaults. Every change asks for confirmation, and so far you’ve clicked yes to every reasonable request. The confirmations are starting to feel like ceremony. That’s the right moment to start loosening. This page is a 4-week plan for moving from defaults to a power-user configuration. Weeks 1 and 2 change no settings; they are for watching what the assistant does. Weeks 3 and 4 each loosen one grant. If anything looks off, hold the current setting for another week or drop back one step.
Self-serve editing of permission grants isn’t in the UI yet — it’s on the roadmap. Today the modes are seeded when you enable assistant access. This plan is the intended progression for once per-action editing ships; until then, email support@tryhoard.com to move a grant, and use the weekly cadence below to decide what to ask for.
The assistant is not perfect. The goal is to find the level of trust that matches its actual behavior on your account, not too tight (every click is noise), not too loose (you stop reading what it’s doing). Before you start, one thing governs everything below. Every plan an assistant creates previews by default, and a preview requires your approval on the Hoard review page regardless of the grant mode. A grant mode only decides what happens on plans where the assistant explicitly turns the preview off, and the connector instructions tell assistants to leave it on. Loosening a grant widens what is allowed to commit without a click; it does not remove the review page from the default flow.

​
Week 1: live with the defaults

Don’t change a thing. Just use Claude or ChatGPT through a normal workweek of store work. Approve reasonable requests. Reject anything that looks off. What you’re collecting: data on what the assistant tends to suggest. Most sellers find that the first week feels chatty, every preview asks. By the end of the week you have a feel for the pattern. What to note as you go:
  • Were any of the suggested changes obvious mistakes? (Should be rare.)
  • Did the assistant suggest the same kind of change repeatedly? (Pricing rule edits are common.)
  • Did you reject anything? Why?
At the end of the week, review your activity log. There is no Activity tab in Settings yet, so you read the log by asking your assistant (for example, “show me everything you did this week and how each one ended”). Ask it for the rows with outcome rejected_by_user. If that count is high (>20% of confirmations), the assistant is suggesting things you don’t want, fix that first before loosening anything. Tell it the constraint in plain English: “I never want you to change my price source automatically.” Most assistants will hold onto that for the rest of the conversation.

​
Week 2: review the rules it drafts

There is no quantity step. The inventory.update_quantity grant you see in the seeded list is a placeholder. The only write actions that run through the permission grant and risk flow are pricing.edit_rule, pricing.suggest_rule and pricing.change_set. Any other namespace sent to that flow is rejected with unsupported_action. Assistants do have other write bindings that never enter the plan flow, including creating, renaming and deleting card lists, adding and removing cards from a list, marking orders shipped, submitting order feedback, requesting a sync, starting a pull session, and watching, dismissing or snoozing buy candidates. The permission modes in this plan do not govern any of those. So week 2 changes no grant. pricing.suggest_rule is already seeded at auto_low_risk, the loosest mode any seeded grant starts at. Use the week to check what the assistant drafts before you loosen anything that touches a rule already in use. What to do this week:
  • Ask the assistant for new pricing rules as you normally would.
  • At the end of each day, ask your assistant for pricing.suggest_rule rows with outcome: committed, then open Settings > Rules and check each draft against something you remember asking for.
  • Delete any draft you did not ask for. The assistant is capped at 20 suggested rules per 24 hours, so a runaway conversation cannot flood the tab.
End of week: if every draft the assistant produced matches a request you made, the same judgment is likely to hold on rules that are already live. That is the week 3 step.

​
Week 3: trust low-risk price edits

This is the meaningful one: set pricing.edit_rule to auto_low_risk. (Email support to make the change until self-serve editing ships — see the note above.) What this does: rule edits the server classifies as low risk no longer need a per-call confirmation, on plans where the assistant turns the preview off. On a default preview the review page still appears. A rule edit only scores low risk if the multiplier change is 0.05 or less (a 1.10 → 1.15 bump), the price source is unchanged, and no flight-check protected cards match. Everything else still requires confirmation. A multiplier change larger than 0.05 is at least medium, past your change_cap_pct at least high, and more than twice your change_cap_pct critical. Flipping the price source is at least medium. Turning never-go-down off is at least high once the rule covers more than 100 cards. Enabling or disabling a rule is scored on its own scale rather than by the multiplier change. Floors still gate. Risk scoring still runs. The only thing that changes is the per-call confirmation prompt for the smallest edits. What to do this week:
  • Use the assistant for pricing edits as you normally would.
  • At the end of each day, ask your assistant for pricing.edit_rule rows with outcome: committed. Most of these committed after you approved them on the review page; any that did not are ones where the assistant turned the preview off and the loosened grant allowed the commit. Make sure each one looks right.
  • If anything committed that shouldn’t have, hold this setting and ask the assistant why it made that call before reviewing further.
End of week: a clean activity log of committed low-risk edits, all of which look right, means you’re ready to keep going. Any false positives, edits you wouldn’t have approved if asked, mean stay at this setting for another week, or drop pricing.edit_rule back to ask_for_mutations.

​
Week 4: full trust except critical

If week 3 was clean, push further. Set pricing.edit_rule to auto_unless_critical. This drops the per-call confirmation at every risk level except critical, again only on plans where the assistant turns the preview off. For a rule edit, critical means a multiplier change of more than twice your change_cap_pct, or turning never-go-down off on a rule that covers more than 1,000 cards. Change sets never auto-commit. A pricing.change_set plan, where the assistant proposes several rule edits and new rules as one unit, has no grant of its own, so it falls back to always_ask. You approve it by hand on the Review pricing changes page (Approve and apply N changes, or Reject with an optional reason) no matter how pricing.edit_rule is set. Floors still gate. Server invariants are unchanged. The assistant still cannot violate your per-card floor, your per-rule aggregate cap, your per-session cap, or the absolute $0.01 minimum. What to do this week:
  • Use the assistant the way a power user would. Ask for sweeping changes, ask for end-of-day audits, batch your work into the conversation.
  • Review your activity log at the end of the day rather than in real time.
  • Watch the rejected_by_floor count. It should be very low. A handful per week is fine, those are the safety net working. A flood means the assistant is groping at the limits of what’s allowed, which usually means the conversation is set up wrong; restart with clearer constraints.

​
Common end states

The configurations to choose between:
  • Week 3 (auto_low_risk for pricing.edit_rule, defaults everywhere else). Most of the throughput benefit with most of the confirmation safety net. Stop here if you are unsure.
  • Week 4 (auto_unless_critical). Minimum friction, on the assumption that you review the activity log.
  • The defaults. Some sellers experiment and go back. They like the confirmations and don’t mind the clicks.
  • Tighter than the defaults, with account.settings: deny and some pricing namespaces denied. Read-only-plus configurations.
None of these is wrong. Pick the level that matches how you actually want to work.

​
When to roll back

The signal that you’ve loosened too far:
  • Two false-positive commits in a week. A false positive is a committed change you would not have approved if asked. One is a fluke; two is a pattern. Drop one tier (week 4 → week 3, or week 3 → defaults).
  • A rejected_by_floor cluster in one session. If the assistant is probing the limits 5+ times in one conversation, either the conversation is set up wrong (start fresh with clearer constraints) or the assistant has been talked into bad ideas by something in its context. Tighten temporarily.
  • You stop reading the activity log. This is the quiet failure mode. Audit-log-as-safety-net only works if somebody is reviewing the log. If a week goes by and you haven’t looked at it, retighten one notch, get the confirmation prompts back as a forcing function until the habit comes back.
Rolling back is the same route as loosening: email support to move the grant back. There’s no penalty.

​
Limits of the progression

The assistant does not replace your judgment. Widening the grants reduces the per-call friction on routine work. It does not hand over the store. Review your activity log at the end of each week, including at week 4. The assistant will sometimes make calls you would not have approved. Floors catch the dangerous ones. Your review catches the rest. If at any point that arrangement stops feeling right, retighten. The defaults are always there.