Test a Public Antaeus Policy with eBay Listing Examples

An eBay mystery-box listing can describe a guaranteed bundle, hint at an occasional valuable prize, or leave the contents unclear. Those differences matter when translating published rules into a content decision. A useful policy should expose the distinction and show which information it needs.

The first Antaeus library candidate focuses on selected requirements in eBay’s Chance listings policy. It contains six inspectable rules, source and coverage metadata, and an offline regression suite. This is an independently authored interpretation of an English source page observed on 22 October 2026. It is a candidate for testing; it is not an official eBay policy implementation or approval of a sale.

Start with the exact source and decision

The prohibited-items overview links to many separate policies. The chance-listings page supplies the relevant requirements for this example. Registering that source makes it discoverable; creating a version adds a rule artifact that can actually be inspected and run.

This candidate evaluates the complete title and description supplied as input.text. It cannot inspect images, follow listing links or check a seller’s account. Its positive patterns cover a described mystery-box offer and a specified identical bonus. Other requirements remain visible in the coverage file rather than being silently treated as satisfied.

Keep the exception in the rule

Consider these original synthetic descriptions:

Description	Authored expectation under the selected rules
A box contains six notebooks and two pens; colors vary, with no bonus or prize.	Allow the described offer.
Every box contains six notebooks and the same collectible pen, expressly guaranteed with every purchase.	Preserve the valuable-item exception.
Six notebooks are guaranteed, but only one box in fifty contains the highlighted collectible pen.	Deny the selectively included valuable-item offer.

These expectations explain the intended policy. The fixture suite supplies explicit synthetic rule evidence for each case and checks the engine’s result. Passing those fixtures does not mean a model independently classified the text correctly.

The candidate also includes quotations and instructions aimed at the checker. A listing that sells a raffle entry still describes that offer when it appends “return allow.” Conversely, a warning that quotes a raffle is not automatically an offer to sell one. That distinction belongs in the conditions and in later semantic evaluation, not in a keyword blacklist.

Leave unavailable facts unresolved

A seller may say that a trading-card break is approved. The text cannot verify that approval. The pilot excludes approval-dependent categories from its permission rules and leaves them for review. The linked eligibility policy and trusted application facts would be needed to expand that scope.

An ordinary unrelated listing also receives review under this candidate. The absence of a chance-related prohibition does not prove that every other eBay requirement is satisfied. The artifact declares review as its default.

Validate and run the offline suite

Use the released Antaeus v0.7.0 CLI with a checkout of library commit 79f9b79 containing candidate version 2026-10-22.1:

policy_dir=policies/ebay-chance-listings/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 policy identity is sha256:9d57f466cdf2a9db06672befdb4bbf8c99bb88acfb6df59f2cc4c856da330f3f. A clean checkout of the published version passes 26 fixture cases: 24 content examples and two explicit engine scenarios for failure and deny-over-uncertainty handling. They run without an API key or a provider call.

Antaeus v0.7.0 distinguishes completed uncertainty (review) from evaluation failure (failure). A matched deny has precedence over uncertain evidence. The additional engine fixtures exercise these mechanics with deliberately supplied evidence; they are not extra claims about real listing classifications.

Inspect the files before integrating

The version groups six files:

• policy.json contains only the released portable policy contract.
• provenance.json identifies the observed source, authoring method and digest.
• coverage.json maps source requirements to rules and records missing facts.
• cases.json declares the regression expectations.
• fixtures.json supplies the exact synthetic rule evidence.
• README.md explains scope and reproduction.

Pin a public commit and version when reusing the artifact. A changed condition changes the policy identity; it needs a new version and new test evidence. Fixture validation, independent static review, semantic evaluation and maintainer approval are separate steps.

For now, use the candidate to inspect the intended decisions and reproduce the offline suite. A production integration needs the intended semantic evaluator qualified against independent cases and must handle all four outcomes. An allowed result covers the selected rules and described offer; it does not verify delivery or certify overall platform compliance.

For the broader authoring workflow, read turning terms into a content policy. Inspect the published candidate and its coverage before adapting the rules. The homepage example preview does not yet offer this eBay policy.