Preserve Policy Exceptions Before You Encode the Rule

Two community groups sharing each other’s event announcements can resemble an engagement exchange. A policy interpretation needs to preserve the exception that makes those situations different.

The selected Facebook spam candidate in the Antaeus policy library makes that boundary explicit. It interprets parts of Meta’s Spam policy, including platform-asset trades, paid or bartered platform privileges, engagement exchanges and claimed engagement gates before promised content. It also preserves conditional exceptions for unpaid cross-promotion and interest-based moderation handovers.

This is an authored interpretation of selected rules. It does not implement the whole source, establish facts about an account or grant platform approval.

Start with the exception

A rule that denies every reciprocal engagement arrangement would be too broad for this selected interpretation. Meta’s source permits cross-promotion that is not triggered by payment to a third party. Reciprocal promotional sharing can fall within that exception; reciprocity alone cannot settle the decision.

The case suite separates three original synthetic proposals:

Described proposal	Expected under selected checks
Follow my page and I will follow yours in return	deny: pure metric trading
Two garden clubs voluntarily share event announcements, without third-party payment, rewards or access gates	allow: described unpaid promotional sharing
Promotional sharing described as an engagement exchange, with payment and purpose unspecified	review: unresolved overlap

These are authored expectations. A model has not classified these cases in a qualified semantic run. The table explains the intended boundary, not measured accuracy.

The distinction belongs in the portable rule conditions and coverage, as well as the examples. An application should not have to guess whether a broad deny rule silently erased an exception.

Preserve what the text can establish

The candidate accepts English proposal text in input.text. It evaluates the activity the text describes; it cannot verify that an account actually sold a page, posted repeatedly or received permission from Meta.

The same distinction matters for moderation handovers. A proposal to transfer responsibility because of a member’s interest, without exchanged value, has a selected positive expectation. Calling a paid admin-role sale an interest-based handover does not remove its value exchange. A vague transfer without the relevant facts remains review.

An engagement gate has another boundary. The selected condition includes a claim that a user must like or share before accessing promised content. The textual claim is enough for that selected check; proving a working technical gate is a different task.

Warnings and quotations are interpreted in context. A warning not to buy likes is not itself an offer to sell them. Instructions telling the checker to output allow or deny remain input data.

Leave deferred requirements visible

The source covers more than these six rules. The coverage file leaves the whole monetary-content-exchange category and its branded-content exception for separate linked-policy review. A creator fee alone is not a selected violation. Account activity, frequency, cloaking, destinations, deceptive interfaces and actual authority also need other evidence.

A relevant unverified claim of Meta approval or a newsworthiness exception requires review; it never grants permission. This candidate does not authenticate approval claims or decide platform enforcement.

An allow therefore concerns the described proposal under selected checks. Other requirements can remain unresolved. It is not proof of full Facebook compliance and does not qualify ads, Marketplace or other Meta products.

Reproduce the execution tests

Use the released Antaeus v0.7.0 CLI and a checkout pinned to the verified public candidate commit:

git clone https://github.com/antaeusio/policies.git
cd policies
git checkout b4d662bf8ef0bcc0d206c0aaca2bb41c27deb482
policy_dir=policies/meta-spam/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"

There are 26 synthetic content cases and two separate engine scenarios. The fixtures supply exact rule evidence without credentials or network access. They test bindings and the engine’s reduction of supplied evidence, rather than asking a model to classify the text. The engine scenarios preserve operational failure and matched-deny precedence over uncertainty.

The candidate’s provenance records a manual public browser observation in English (US), including the selected current policy tabpanel, method, size and hash. It retains no source snapshot and claims no linked HTTP response, automated retrieval qualification or ongoing freshness certification.

Inspect the exact policy, coverage, provenance and cases together before adapting them. If an exception is missing or a case needs correction, contribute an original synthetic example against that immutable version. The useful starting point is a specific boundary another developer can reproduce.

The Amazon listing-policy tutorial explains how an omitted requirement can limit an allow result. Read both examples with their coverage records before adapting a policy.

The X reporting-intent example distinguishes described good-faith reporting, an explicit abusive plan labeled good faith and a request with missing purpose. Use its authored cases to inspect that boundary.