Guardrails

Security answers who can reach what. Guardrails answer a different question: what the platform declines to do even when the caller is authenticated, authorized, and asking correctly. A valid secret key with full permissions can still be used to sell below cost, take a payment through a test processor, or run an automation into the ground, and each of those is refused. Every guardrail below is checked where the write happens rather than in the interface, so a request made directly against the API meets the same refusal a form would.

---

​

Human approval on anything worth money

The in-app assistant can prepare gift cards, promotions, and pricing rules from what it sees in a store. It cannot issue any of them. Each one is written as a draft — a real row, inert until approved — and surfaced where the merchant already manages that kind of thing. Approval is a separate, explicitly granted permission, checked on the server at the moment of approval rather than assumed from whoever created the draft. The limits are re-validated then too, against the row as it stands: a draft that was within bounds when prepared is checked again before it goes live, and a plan that lapsed in between blocks it. The same rule governs dynamic workflows. A workflow can rotate a collection or retag products on its own, because those are reversible. It cannot run a discount — it prepares one and waits. A rule that runs on a schedule carries further limits beyond approval. A workflow that drafts a gift card for every customer meeting a threshold is bounded on both how many it may prepare in one run and their combined face value, and a run matching more than that stops and reports it rather than choosing a subset. A cooldown prevents the same customer being rewarded again on the next run, which would otherwise compound at every cadence. These ceilings live in the database and are re-clamped on every call, so a rule can narrow them but never widen them, whatever the request asks for. A markdown pricing rule is bounded differently, by scope: it covers only the products it actually identified rather than the whole catalogue, and only one such draft is outstanding at a time so a weekly rule cannot stack duplicates while a merchant is deciding.

​

What the model decides, and what code decides

The assistant is used for judgement, and only for judgement. It writes copy, drafts a rule, and chooses which of a store’s products a change should cover. Everything that bounds it is ordinary code: how many gift cards a run may prepare, how much a budget may move, whether a schedule is due, how much credit an action costs, whether a store has spent past its cap. The division is not stylistic. A limit expressed in a prompt is a request; a limit expressed as a constraint is a rule. The second kind can be tested, holds under a request written to talk past it, and behaves the same whichever model is answering. So a store’s ceilings live in the database and are re-checked at the moment of use, rather than being described to the assistant and trusted. The same reasoning applies to counting. Whether a standing rule has produced anything over its last several runs is a question about records, so it is answered by reading them — not by asking a model to summarise. Reserving inference for the parts that genuinely need judgement is also what keeps an automatic process cheap enough to run on a schedule.

​

Autonomy changes who maintains a rule, not what a rule may do

A store can hand the assistant a standing job: rather than being asked for each rule, it keeps the set of standing rules current — adding ones worth running, retuning ones whose thresholds have drifted, and retiring ones that have stopped producing anything. This widens nothing about money. Every constraint above still holds, unchanged: a discount, a gift card and a pricing rule are still prepared as drafts and still wait for a person with the approval permission. What becomes automatic is the upkeep. Three further limits apply to the upkeep itself:

• A rule a person paused stays paused. Pausing is an instruction, not an untidy state to be corrected, and it is never reversed automatically. The same holds for a rule stopped by the failure breaker: that is a fault for a person to look at.
• A rule that has ever acted is never retired. Retirement is reserved for rules that have produced nothing across a sustained run of evaluations, counted from the record rather than asserted, and it pauses rather than deletes — so a wrong call costs one click.
• Every adjustment is recorded with its evidence, in the same log as the actions themselves and distinguishable from them, so “what changed in my shop” and “what changed about my rules” stay separate questions.

Autonomy is also funded explicitly rather than silently: it stops when a store’s credits run out, and says so, instead of quietly doing less.

​

Advertising spends nothing a merchant has not bounded

Where a store lets Galactic Core manage its advertising unattended, every automated write passes one checkpoint before it reaches the ad platform, and that checkpoint answers with one of three outcomes: proceed, ask, or refuse. A write is refused outright when it would carry the month past the spend limit the merchant set — there is nothing to approve, because approving would breach a limit they already expressed. A write at or above their per-change approval figure is held for a person, recorded as the exact change it would make so that approving replays it rather than reconstructing it. Everything else proceeds. Two details matter more than they look. A store that has set no limit is treated as the most cautious case, not the least — every spending change is held for approval, because a merchant who has configured nothing has expressed no appetite for unattended spend rather than an unlimited one. And a change that spends nothing is never measured against a spending limit: pausing a campaign is the safe direction, and a cap that blocked it would keep a losing campaign running precisely because the store was near its limit.

​

Cost coverage before any pricing action

Any automated action that affects price first checks that the store’s cost data is complete enough to reason about. When a cost price is missing, margin arithmetic treats it as zero, which reads as 100% margin — a discount computed on that basis looks comfortably profitable and can be sold below cost. When coverage is too thin the action is refused, not merely flagged, and the response names the products whose costs are missing. The check applies to the assistant, to standing workflows, and to advertising rules alike.

​

Test credentials cannot serve a real customer

A store can be live while a payment provider is still configured with test credentials, in which case a shopper would complete checkout against a sandbox processor, see a confirmation, and pay nothing. On a production request, a provider whose credentials are not live-grade is hidden from the available payment methods and refused at initialization. The shopper cannot select it, and a direct API call gets an explicit error rather than a phantom success. The check applies to production requests only. A sandbox key sees every provider, including ones still on test credentials, since hiding them would make the mode useless for the testing it exists to support. A sandbox checkout listing providers marked test or sandbox is therefore the system working; point a live key at the same store and those providers are gone. The same asymmetry holds for every integration below. The merchant’s own in-store point of sale warns rather than blocks, because that is the merchant’s own device and they may be mid-setup. What differs between the two cases is who is transacting: a customer is never allowed to pay into a test account, while a merchant may test their own till. The same rule extends past payments to every integration a merchant connects themselves, because every one of them has a test mode and a merchant can be live to shoppers while still holding test credentials:

• Tax. A store connected to a sandbox tax account is not used to price real orders — a test engine’s rates are not the ones that get filed. The store’s own configured rates apply instead, so the shopper is still charged a number the merchant chose.
• Shipping. A test carrier token cannot buy a label for a production order. A test label is not accepted by any carrier, and buying one would mark the order shipped and send the customer a tracking number that never moves. Live rates are simply not offered, and the store’s own delivery pricing stands.
• Subscription billing. A billing processor configured with test credentials is not offered and is refused if named directly.
• Advertising. Automation rules run against a real ad account and move real budget, so only rules created in production ever execute. A rule authored while testing stays inert.
• Accounting. Ledger entries are never posted into a sandbox accounting company. When the connection is not pointed at a real one, entries stay queued rather than being sent, so nothing is lost and the queue delivers once the connection is corrected. An entry posted into a test book would be indistinguishable from a successful sync.

Where a sensible fallback exists the request degrades to it rather than failing. Where a soft failure would leave a false record — an order marked shipped, a tracking number sent, a journal entry filed in the wrong book — it is refused outright. Either way the merchant is told, on a cadence set by what the state is costing them: daily when nothing can be sold, weekly when the store still trades correctly but not the way they configured it. A guarded action is also withheld from the interface, so a merchant meets a sentence explaining the state rather than a control that fails. That state is shown on the surface whose owner can fix it: never to a shopper, to the merchant for their own integrations, and in full to the operator, who is the one who corrects it.

​

The environment boundary

The key prefix decides the environment, and with it which partition is read and written and which mode payment providers run in — described in Security & Compliance. No request reads across that boundary and no flag relaxes it. The boundary extends past data into behaviour. Notifications, automated actions, and scheduled work are all production-scoped: a sandbox order does not email anyone, and a sandbox automation does not act on a live store.

​

Automatic shutdown, with notification

Anything that runs on its own carries a circuit breaker. Repeated consecutive failures disable it rather than letting it retry indefinitely; a single success resets the count, so a brief outage costs a few failed runs instead of the automation itself. When something disables itself the merchant is notified, so a stopped automation is not mistaken for a working one until something expected fails to happen. Autonomous action is announced the same way: an advertising rule that moves a budget or pauses a campaign reports the change and the figures behind it. Every automated run is recorded with the figures that triggered it, so a change can always be traced to its cause. A standing rule also stops when its output is not being used. A rule that writes content pauses once three of its drafts are sitting unread, and resumes on its own once some are published or discarded — further runs would spend a model call and image credits producing more of what is not being read. Nothing has to be re-enabled by hand. A rule scoped to a season behaves the same way: out of season it is skipped rather than switched off, which is what lets it come back the following year with its settings and history intact.

​

Nothing is written until it is asked for

The assistant can prepare things, but the merchant’s words decide whether it does. A question about a capability — “can you write a blog post?”, “what would that look like?” — is answered, not performed, even though the same verbs appear in both. An explicit instruction to hold off (“just asking”, “not yet”, “don’t create it”) outranks everything else in the turn, including a request that would otherwise read as a command. The assistant errs toward answering rather than acting, since a question mistaken for an instruction leaves the merchant with something to undo while an instruction mistaken for a question costs one more message. Where the reading is genuinely ambiguous, the assistant asks. Written content is never published on the merchant’s behalf, whether a person asked for it or a schedule produced it. It is their public voice, so it lands as a draft and stays there until they publish it.

​

Server-side prices and stock

Order totals are computed from the catalog, the store’s pricing rules, and any promotion that applies — never from amounts supplied by the caller. A client that submits its own price for a line item does not get that price. Availability is decided the same way, at reservation time inside a single-writer path, so two shoppers racing for the last unit produce one sale and one refusal rather than an oversell.

​

Ceilings on cost

Requests are rate-limited per key, and per-store quotas cover the work that costs real money — API traffic, assistant usage, generated media. Crossing a quota is recoverable rather than terminal, but the ceiling is always present and enforced server-side. Automated work carries its own bounds: a maximum number of steps per run, a timeout per call, a cap on how many standing rules a store can hold. None of these are configurable from the client.

​

The business schema the assistant reads through

The assistant never queries your store directly. It reads through a business schema — a fixed, named layer of business concepts that sits between it and your data. A product’s margin, the items running short against their recent sales, what a promotion currently offers, how traffic converts: each is a defined concept with the store already fixed inside it. The concept decides what comes back. The assistant chooses which one to ask for, never how it is answered. Three properties follow, and together they are the point of the arrangement. A concept cannot be widened. There is no phrasing that returns another store’s figures, because the store is not something the assistant supplies — it is bound from the session before any concept is read. A confused or manipulated model can pick the wrong concept and get an unhelpful answer; it cannot reach data belonging to someone else. Cost stays behind the arithmetic. Margin arrives as a computed figure, never as the underlying cost of a product. The assistant can tell you a discount would sell below cost and refuse to prepare it, without the cost itself ever entering the conversation — which also means it cannot repeat one back to you, or to anyone reading a shared transcript. The schema is stable while the storage beneath it is not. Concepts are the contract; how they are stored and computed can change underneath without the assistant being taught anything new, and without widening what it can see. That is what keeps the boundary fixed as the platform evolves. Answering is read-only throughout. The ability to change anything is a separate, narrower surface: reversible catalogue work — creating a subcategory, retagging, arranging a collection — is written directly and recorded in your activity log, while anything touching money is prepared as a draft and waits, as above. Every write there carries the store it belongs to and re-checks the merchant’s existing permission at the moment it runs. The assistant supplies the intent; Galactic Core’s own code decides whether it is allowed. This is why the same answer arrives whether it is asked in the app or reached through the API. The boundary is the business schema, not the interface in front of it.

​

What an integration sees

A correct integration rarely meets these. When it does, the response is an explicit error naming the guardrail rather than a silent partial success, so a refusal is never mistaken for a completed action. It reports the state of the store rather than a transient failure, and retrying an identical request produces the same refusal.