Testing the Limits of an Amazon Listing Policy

An allow result has a scope. Before reusing a policy, check which rules produced that result and which requirements the policy leaves out.

The Amazon candidate in the Antaeus policy library makes this boundary visible. It packages two selected text checks adapted from Amazon.com’s Product detail page rules for the United States: contact or outside-ordering content, and a clear physical-product description without those issues.

It does not implement the whole source document. That makes it useful for learning how to inspect and test a policy before adopting it.

Start with the selected rules

The candidate denies listing text that includes a phone number, mailing address, email address, website URL, or instructions to order or pay outside Amazon. The outside-ordering/payment wording is a conservative adaptation; it also screens instructions without links.

The positive rule allows a clear physical-product description with features or specifications when none of those selected issues is present. Other text defaults to review. An evaluation problem remains failure.

The physical-product boundary is a deliberately narrow demo choice. It does not mean Amazon prohibits other product types. The policy’s coverage file explains this distinction and identifies the source requirements that remain deferred.

Test an omitted requirement

Consider this original synthetic listing:

A steel water bottle with a 750 ml capacity and screw-top lid. Price: USD 12.

The case price-outside-selected-scope expects allow under the two selected checks: it describes a physical product and supplies none of the selected contact or ordering content.

Amazon’s source separately restricts price details in listing content. The candidate omits that requirement. An allow here therefore cannot mean the listing meets all of Amazon’s rules.

This is an intentional scope test, included alongside ordinary positive and negative examples. It lets another developer see the boundary before using the artifact in an application.

Inspect the boundary cases

The suite includes measurements and a labeled model number that are product specifications rather than contact numbers. It also includes an email address, a postal address, a care URL, outside-payment instructions, and an ambiguous description.

Quoted warnings do not create an exception in these selected rules. A listing that says not to call a literal contact number still includes that number. A same-platform URL also remains a URL. These expectations are explicit in the case descriptions instead of being left for an application to guess.

The coverage file leaves images, category requirements, claims and truthfulness, identifiers and rights, catalog duplicates, editing history and account authority for separate checks. Listing text alone cannot establish all of those facts.

Reproduce the execution tests

Use the released Antaeus v0.7.0 CLI and a checkout of the public candidate at commit 9883fa0 below.

git clone https://github.com/antaeusio/policies.git
cd policies
git checkout 9883fa01d225003c68b9c25f4dfaaf9130a98e7c
policy_dir=policies/amazon-product-detail-rules/versions/2026-10-22.1
antaeus validate "$policy_dir/policy.json"
antaeus test --policy "$policy_dir/policy.json" \
  --suite "$policy_dir/cases.json" --fixture-set "$policy_dir/fixtures.json"

The suite contains 22 synthetic content cases and two engine scenarios. The fixtures provide exact rule evidence. Running them verifies identities and how the engine reduces that evidence to an outcome; it does not ask a model to classify the listing or measure semantic accuracy.

The additional engine scenarios show that failed evidence can produce failure despite a matched positive rule, and a matched deny takes precedence over uncertain positive evidence.

The candidate preserves the existing fixed demo’s exact portable policy digest:

sha256:a638ac46976967809b263c17c0b6baef8df9128bf81a13f7043cf03d7afcab3e

Its expanded public case suite requires its own semantic qualification. The public version remains an authored, unqualified candidate; it is not an eligible homepage library selection or a generated, model-checked policy release.

Read the source record too

The Amazon article was publicly readable in English-US and identified United States applicability. The provenance file records a manual browser observation of the primary article, including its selector, text method, size and hash.

It does not claim that an ordinary HTTP response supplied that rendered text. The observation does not qualify automated retrieval or certify that the source is still current. No full third-party page snapshot is redistributed.

Before adapting the candidate, read its policy, coverage, provenance and cases. Choose the extra requirements your application needs, obtain the required facts, and add original synthetic examples before changing rules. Changed policy bytes need a new immutable version and fresh evidence.

Inspect the immutable Amazon candidate and its coverage before reuse. The eBay chance-listings tutorial shows another source-specific artifact and its offline workflow.

The Facebook policy-exception tutorial shows how to preserve unpaid cross-promotion when it overlaps engagement-trading wording, and when missing facts require review.