Skip to main content
AI Business Rules is the seller Page for deciding what your storefront accepts and how review happens. It brings together Brief Acceptance, which sets the content rules for advertisers, categories, and creatives; Creative Policy; approval gates; and approval routing. Brief Acceptance is the content half of Govern: it says what is acceptable, while your approval settings say whether a human reviews eligible work. During product discovery, Brief Acceptance is checked by storefronts that compose their own products. A Listing storefront forwards eligible briefs to its connected sales agent without composing products, so it does not check Brief Acceptance at discovery. A storefront using an Apostra-managed manual media-buy approval workflow, Listing or not, evaluates the submitted buy against the policy before Approval Mechanics determines whether it can proceed. Provider-policy-owned social adapter storefronts pass transactions through to the social platform without an Apostra-managed approval queue. The current cohort is LinkedIn, Meta, Pinterest, Reddit, Snap, and TikTok. The social platform owns acceptance in those paths, so these storefronts do not need an Apostra acceptance policy for readiness or transaction admission. The provider’s own review rules still apply. Adapter-routed storefronts outside this cohort — including Amazon, Google Ads, and Spotify — retain their configured Apostra approval behavior and need a policy when that workflow is enabled.
Did a request fail with “Request declined by platform policy.” or did a media buy or creative stop at Platform review? That is the platform safety policy, not your Brief Acceptance policy. See Request declined by platform policy.
You can author it either way:
  • Open the portable AI Business Rules page from Apostra, Claude, ChatGPT, or another MCP Apps host to create or edit the full policy inline.
  • Tell Apostra the exact rules you want. Apostra shows you the complete markdown for confirmation, then writes it through the same typed configuration contract.
Creating or activating policy versions requires an account administrator. Other storefront members can review the active policy and immutable history without receiving a hidden mutation path through the Page or MCP API. Saving also requires an active Listing profile. If a save cannot complete, the Page keeps the draft. The Page shows the server’s safe reason and recommended action when available, otherwise it uses generic guidance. Every save attempt has a correlation ID that remains visible for support even if the host loses the server response. You don’t pick from a fixed menu of categories. You describe your rules, and the agent reads what you wrote. Every save creates an immutable version and can activate it atomically, so version history never contains a half-applied update.

​
Edit and restore versions

The AI Business Rules page always reads the current active Brief Acceptance policy and its version history. Save and activate creates a new version without overwriting the old one. If versions exist but none is active, the history remains visible so an administrator can preview, reactivate, or reuse a version as a new draft. The page performs those operations directly; it does not turn a button click into a new chat prompt or depend on a particular host model.

​
Test a brief against your rules

Before you rely on a rule, you can see how it treats a real buyer brief. On the AI Business Rules page, Test a brief lists the briefs your storefront received, taken from your Sessions: your latest 25 discovery briefs and 25 RFPs, most recently active first, each with its advertiser and its last activity. Pick one and run the test. A brief received before your storefront kept a copy of it can’t be tested; picking it says so. To test an older brief that isn’t in the list, choose Paste a request instead and paste the buyer’s AdCP get_products request (JSON); Use an example fills in a small one to start from. On the main view the test uses your active policy; while you edit, it uses the Brief Acceptance rules you have not saved yet, so you can change a rule, test it, and then save. Any member of your seller account can run a test. After a test, All brief fields shows the complete request that was tested. Each test shows two answers side by side:
  • Production is what product discovery does with that brief today: whether it returns products, the reason the check gave, and the rule a decline quoted. The discovery check reads only the first 4,000 characters of the brief’s text, and it can decline only on Brief Acceptance rules of up to 4,000 characters or 80 rules; the result says when either limit applied. When discovery does not run the check, the result says so instead of guessing. That covers a Listing storefront, a storefront that answers through a sales adapter, and a wholesale or refine request.
  • Beta is the answer from Cloudflare Clef, the evaluator that may replace today’s check: Pass, Needs review, Does not pass, or Inconclusive. Clef reads the complete brief, up to 128 KiB, against Brief Acceptance rules of up to 12,000 characters or 80 rules. It gives an answer and its confidence, never a written reason. An inconclusive result is never a pass.
The two can disagree, and when they do, both are shown. A test changes nothing: it approves, declines, saves, and publishes nothing, and it does not affect discovery or media-buy decisions. Credentials in the request are removed before either evaluator sees it, and the result lists what was removed. Model answers can shift slightly between runs.

​
Policy vs. approval mode

These are two separate dials. Keeping them straight is the most common point of confusion: Brief Acceptance has two enforcement points. During product discovery, on a storefront that composes its own products, a confident conflict with the seller’s written policy returns no products; an unavailable or inconclusive qualifier fails open so discovery remains available. A Listing storefront does not run this discovery check. At create_media_buy, manual mode evaluates the submitted buy again: clearly on-policy buys auto-forward, while ambiguous results, evaluator errors, and deterministic hard findings queue for an operator. Live auto-rejection requires a separate seller opt-in or versioned rollout. auto mode preserves the established auto-forward contract and does not add a second create-time evaluator gate.

​
How the agent reads your policy

The manual create-time pre-screen reads your written policy against the buyer’s submission. It is not a fixed category list — a rule like “we don’t accept fast-food advertisers” is honored even though “fast food” isn’t a built-in category, because the agent derives the subjects you wrote and matches them against the submission. It also recognizes common evasion (look-alike characters, light obfuscation) so a rule isn’t sidestepped by spelling. When it cannot judge a submission with confidence, it errs toward holding it for you. When no policy document is available, the AI Business Rules Page starts with a conservative draft: no category is pre-cleared, every advertiser, category, and creative needs review, and illegal, malicious, deceptive, discriminatory, exploitative, phishing, impersonation, or destination-concealing submissions are flagged for operator rejection. This draft has no effect until an account administrator reviews, saves, and activates it. While that starter remains active, its review-all contract also makes the deterministic pre-screen hold every submission for an operator; it is not just instructional copy.

​
The three verdicts

The manual-mode create-time pre-screen sorts a managed-storefront media buy into one of three buckets:
  • Clearly on policy → eligible and auto-forwarded without operator review.
  • Needs a look → queued for an eligibility decision. Evidence is thin, the policy is ambiguous, or a rule says this category needs review.
  • Clearly against an explicit rule you wrote → queued with a strong operator-facing rejection signal, without exposing private policy text to the buyer.
No create-time verdict auto-rejects a buy in the current rollout. Deterministic matches can block product discovery and supply a strong queue signal; an AI-judged conflict can only escalate or fail closed.

​
The second opinion

On top of the deterministic manual-mode pre-screen, an AI layer gives a second opinion. It can only downgrade a proposed clear result to “needs a look” if it spots a policy conflict the rules missed (for example, a competitive- exclusivity clause you wrote in prose). It can never approve a buy on its own, never reject one, and never overrides a hold. It also fails closed within the manual approval path: if the AI layer is unavailable, errors, or is uncertain, the buy stays with the operator rather than being cleared by the evaluator.

​
How creatives are evaluated against your policy

Creative review applies the same content rules to a buyer’s submitted creative, plus a rendered-image check that looks at the actual pixels for brand cues, prohibited categories, and third-party marks. As with media buys, the AI layer can route a creative to human review but cannot approve one over a clear policy violation the policy check already found. That check reads the text of the creative against your Creative Policy in any language, and counts a violation only when it clearly breaks a rule you wrote. If it cannot decide or does not finish, the creative goes to a person.

​
Automatic approval

Every storefront on automatic creative approval (creativeApproval: auto) that has a written Creative Policy gets an automated reviewer. It approves a creative when it is definite and every check passes. It rejects a creative only when a separate policy check confirms that the creative breaks a rule you wrote. Otherwise it leaves the creative in your review queue for a person, so a creative it is unsure about waits there instead of going straight to your sources. Apostra can switch the reviewer off for an individual account. On an account where it is off, creatives on automatic approval go straight through and the Creative Policy is not applied to them. A storefront on automatic approval with no written Creative Policy is unchanged: its creatives go straight through, because the reviewer needs a policy to judge against. A storefront on manual approval keeps every creative in the queue. For locked assets — a product shot, logo, or book cover you’ve marked as exact-fidelity — there’s a stronger, deterministic guarantee that the AI layer cannot override:
  • A creative whose final render goes through the platform’s locked-asset compositor preserves your supplied asset exactly, and clears that check.
  • A final-stage creative that carries your locked asset but did not go through that deterministic path — for example, one that re-generated or edited your product from a reference — is blocked from auto-finalizing and held back for a human to inspect. A buyer’s generated creative cannot quietly substitute a look-alike stand-in for your locked product at final approval.
These fidelity checks are deterministic and run independently of the AI layer, so a crafted creative or brief can’t talk the reviewer into clearing them — they err toward human review whenever exact fidelity isn’t deterministically guaranteed.

​
What the agent never does on its own

  • It never hard-rejects a submitted media buy in the current rollout. Deterministic Brief Acceptance conflicts can block product discovery and supply a strong operator-facing queue signal; AI judgments can only escalate.
  • It never changes an approval gate for you.
  • Within manual create-time evaluation, it never promotes an uncertain result to eligible. If the AI layer can’t corroborate, the buy stays with the operator. Automatic storefronts do not run this second create-time evaluator.

​
Request declined by platform policy

Apostra checks some requests against a platform safety policy before it acts on them. The check reads text in any language. It is separate from Brief Acceptance, the policy a seller writes for their own storefront.
Apostra is switching this check on gradually, one place and one account at a time. Until it is on for your account, nothing in this section changes what you see. This page describes how it behaves once it is on.
A refusal never says which rule matched and never names a category. It links to this page.

​
What you see at each step

​
Discovery and campaign writes

When you send a brief to product discovery, or create or update a campaign with a brief or name that the check declines, the request fails with INVALID_REQUEST and the same message every time. Over REST the HTTP status is 422. Through MCP the result has isError: true and the error is in structuredContent.adcp_error.
Test for details.reason equal to safety_refused, not for the message text. The check applies to every way of reaching these operations, including the REST API, the MCP tools, and Apostra’s own assistant.
  • Discovery returns no products. The brief is not used to look for products.
  • A campaign write saves nothing. The campaign is not created or changed.
  • A refusal can also appear while Apostra writes results or a proposal for your brief. In discovery it looks the same as above. For a proposal, no pitch is produced. If your brief caused it, support can clear it for that brief. If the text Apostra generated from your brief caused it, nothing clears it: revise the brief and retry.
Discovery and campaign writes can also fail in a different way: SERVICE_UNAVAILABLE (HTTP 503). For discovery, details.reason is safety_check_unavailable; for a campaign write, the message is “Campaign moderation is temporarily unavailable”. Apostra could not run the check. That is not a finding about your content, and nothing is recorded for support to review. Retry the same request after a short wait. If it keeps failing, contact support. While Apostra writes results or a proposal for your brief, an outage also stops generation, and nothing is recorded for support to review. A separate 422 with the code CONTENT_MODERATION_BLOCKED comes from Apostra’s structural content checks. It is a different refusal with a different cause.

​
Media-buy approval

On a storefront that reviews media buys manually, a buy whose text the check holds is not forwarded automatically and is not rejected. It waits in the media-buy approval queue for a person. A seller sees one check on the buy:
  • Label: Platform review
  • Status: warn
  • Detail: “This media buy requires manual review before it can be approved.”
  • Recommendation: escalate to a person
The seller decides as for any queued buy. The check does not say what triggered it. The buyer sees the buy as PENDING_APPROVAL, the same as any buy waiting for review, and gets no refusal. Brief Acceptance and the AI second opinion do not judge a held buy. If Apostra cannot run the check, the buy is held in the same way.

​
Creative review

When a seller asks for an evaluation of a creative and its text is held by the check, the evaluation returns the same Platform review check: status warn, “This creative requires manual review before it can be approved.”, with manual review recommended. Apostra does not approve or reject the creative on the strength of it. The seller decides in the creative review queue. The check does not say what triggered it, and rendered-image evaluation never turns it into an automatic approval. If Apostra cannot run the check, the evaluation is held in the same way.

​
What to do about a refusal

  1. Revise and retry. Remove or reword the part of the brief, name, media buy, or creative text you think could be read as unsafe, then send it again. Apostra does not tell you which part.
  2. Ask for a review if you think it is wrong. Email support@apostra.com with your account name or ID, the time of the request, and the error code and message. Include the IDs of any campaign, media buy, or creative involved. Do not paste the content itself into the email.
  3. Wait for an answer. A Scope3 staff member reviews the refusal. If it was wrong, staff can clear it for that exact text, and your next attempt goes through. The clearance can have an end date.
A clearance covers only the exact text that was reviewed, for one account. If you edit the text, it is new content and needs its own review. If Apostra changes the check itself, the check runs again. For a discovery brief, the account is the buyer’s. One clearance applies at every seller, so you do not need a separate review for each one. It also covers that brief text through every later step of the same request, including composing results and writing a proposal. When a seller previews their own storefront without a buyer account, the check and any clearance use the seller’s account instead. Support cannot clear a refusal of text Apostra generated: revise the brief and retry. When the check could not run, nothing is recorded, and retrying later is the only fix. A request that passes the check still goes through the rest of the process: Brief Acceptance, approval rules, and structural content checks all still apply.

Prepare inventory source inputs

Request creative policy, approval ownership, and lifecycle evidence together.

Approvals overview

The two settings and the lowest-risk posture.

Media-buy approvals

The queue and the auto-clear vs. escalate decision.

Creative reviews

How submitted creatives move through review.