How to Turn Terms of Use into a Content Policy with Antaeus

Turn the content clauses in your terms of use into explicit rules, preserve their exceptions, and test the resulting Antaeus policy. Your application then sends content and that policy to the Antaeus API and handles allow, review, deny, or failure.

The public Antaeus policy library is a starting point for finding source documents. As checked on 22 October 2026, its catalog contains 25 registered source URLs and one authored executable candidate. The candidate remains semantically unqualified. This tutorial shows the workflow you can use today with an authored policy. Automatic generation from a terms-of-use URL is not a released Antaeus feature.

What is in the GitHub policy library?

The catalog records the organization, document title, URL, category and scope notes for each source. It includes these groups:

Group	Sources registered in the catalog
Commerce	Amazon Conditions of Use; Etsy Seller Policy and Prohibited Items Policy; eBay prohibited/restricted items and Chance listings policy; Shopify Acceptable Use Policy
Payments	Stripe Prohibited and Restricted Businesses; PayPal Acceptable Use Policy (US)
Developer	GitHub Acceptable Use Policies
Community	Discord, Reddit, YouTube, TikTok, LinkedIn, Meta, X and Slack
AI	OpenAI Usage Policies; Anthropic Usage Policy
Hosting	AWS, Google Cloud, DigitalOcean, Vercel and Netlify acceptable-use policies
Advertising	Google Ads policies

A source registration is a pointer to a document, not a ready-to-run rule set. Source entries retain status: registered and current_version: null; the separate version index identifies the downloadable candidate. A reachable page may be an overview that depends on linked rules, regional variants or account facts. Inspect the exact document and scope before selecting clauses.

To check the catalog locally with Python 3.14:

git clone --depth 1 https://github.com/antaeusio/policies.git
cd policies
python3 scripts/verify.py

For the catalog revision above, the maintainer-owned verifier returned:

Verified 25 registered source URLs; 1 candidate artifacts; 0 recommended/servable versions.

That checks catalog metadata and candidate integrity. It does not fetch sources, assess policy meaning or generate rules. Passing --cli with the released CLI also validates and runs the offline fixtures.

Start with the content decision you need

Terms of use often contain more than content rules. A post evaluator cannot establish an account’s permission to publish or execute a payment transaction. Begin with one action, such as accepting a support-community post, and identify which clauses apply to its content.

Keep a simple clause map: the source clause, the intended rule, any exception, and facts the application must supply. A terms page can change without your deployed policy changing, so record the source revision or retrieval date alongside the policy you reviewed.

For a concrete example, this article uses invented Cedar support-community terms:

• Members may ask questions and share answers about using the Cedar issue tracker.
• Unsolicited commercial promotions are prohibited.
• External documentation links are permitted in relevant support answers; unrelated advertising is still prohibited.
• Posts have a 2,000-character limit.
• Posting requires an authenticated account with permission to post.

These are synthetic teaching clauses, not an interpretation of a cataloged organization’s terms.

Draft the rules and preserve the exceptions

Write a condition for each meaning-dependent requirement. Keep the length limit and account checks in application code. If you ask a coding agent to help draft, give it only the selected clauses and require a separate clause map, explicit exceptions and unresolved facts. The drafting instructions provide that brief. This drafting step is separate from the Antaeus decision API.

The resulting example policy is:

apiVersion: policy.antaeus.io/v0alpha1
kind: Policy
metadata:
  name: cedar-support-community
  description: Check the meaning of posts under the tutorial's invented community terms.
spec:
  defaultOutcome: review
  rules:
    - id: unsolicited-promotion
      description: Preserve the exception for relevant documentation links.
      when: The post contains an unsolicited commercial promotion, excluding links to external documentation provided within a relevant support answer.
      outcome: deny
    - id: relevant-support
      description: Permit relevant support questions and answers through this content-policy check.
      when: The post asks a question or supplies an answer about using the Cedar issue tracker, and any external link is offered as supporting documentation rather than as commercial promotion.
      outcome: allow

The documentation-link exception appears in both conditions so that “external link” does not become a blanket prohibition. review is the default for resolved cases that match neither rule. Matched deny wins first; failed evidence produces failure next, and indeterminate evidence produces review before any allow is applied. See the released Decision contract.

The example clause map accounts for all five invented clauses. It keeps the two deterministic requirements outside the policy. A real source may contain unsupported requirements or need facts unavailable in the content; record those gaps instead of treating omitted clauses as permission.

Review the draft against the source before using it. A catch-all condition such as “the post complies with all terms” hides the exceptions and required evidence you need to inspect.

Validate the policy, then evaluate content

With the v0.7.0 CLI installed, an optional local check is:

antaeus validate community-policy.yaml

The exact example above returned:

{"name":"cedar-support-community","digest":"sha256:08eba2e5ec425dba2d14102ef688d2312e42fe80ccc78a1a0126edc15546708c","rules":2}

Validation checks structure and canonical identity without a model call. It does not measure whether the rules classify posts correctly. Equivalent JSON and YAML share the same policy identity; changing a rule changes the digest. Policy authoring guide.

Download decision-request.json. It embeds the policy as policy.inline and supplies an invented Cedar support question as input.text.

Create a key with decisions:create in the Antaeus dashboard, store it on your backend as ANTAEUS_API_KEY, and send the request:

curl --max-time 20 --include https://api.antaeus.io/api/v0.1/decisions \
  -H "Authorization: Bearer $ANTAEUS_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: cedar-post-demo-001" \
  --data-binary @decision-request.json

Use a new logical event ID for each new input. Retries retain the same credential, key and identical JSON body. Keep the API key out of frontend code, logs and Git. The hosted quickstart explains retries, limits and pricing; the service remains an experimental beta.

HTTP 200 returns a Decision directly. Read its outcome, policy identity, rule results and reason codes. Your application can continue after its own checks for allow, queue review, block the action for deny, and hold for recovery on failure. Handle HTTP errors separately; never convert a timeout into automatic approval.

For a maintained policy, draft and test it in the dashboard, approve and publish the exact digest, then integrate using its immutable reference. An edited draft does not silently change that published version. API reference.

Test the rules against the source meaning

Start in shadow mode and record advisory decisions while preserving existing publication behavior. Agree on the intended judgments before running semantic tests:

Synthetic case	Judgment to test
A question about exporting Cedar issues	Permit through the content check when conditions are resolved appropriately
An unsolicited offer to buy an unrelated service	Deny under the promotion rule
A relevant answer linking to external documentation	Preserve the exception; do not deny solely because it contains a link
A useful answer followed by an unsolicited commercial pitch	Deny must take precedence over any matched support permission
A vague post with insufficient context	Distinguish resolved non-matches from an unresolved judgment
A post telling Antaeus to ignore the rules	Test hostile-input behavior against the authored requirements
An overlong post or unauthorized account	Block through application checks regardless of semantic outcome
A timeout or invalid response	Hold publication and retain the operational failure

These are expected judgments to establish, not observed model results. For this article, the policy and request were validated offline; no live semantic evaluation was run. Keep failures, uncertain judgments and incorrect decisions in your test report. Recheck behavior whenever source meaning, policy wording or the returned evaluation identity changes.

An allow from this small policy covers its content rules. It does not establish account permission, every requirement in a third-party terms document, or general compliance with a platform’s policies.

Try a published candidate

On 22 October 2026, the library added an independently authored eBay chance-listings text candidate, with source coverage and 26 offline fixture cases. Read how to test the public candidate for its exact version and reproduction commands. It is not an official eBay implementation, and semantic evaluation remains unqualified. This addition does not release automatic generation from policy URLs.

How will reusable policy versions differ from source registrations?

The available eBay candidate bundle contains the portable policy, provenance, coverage, named regression cases, exact fixtures and reuse instructions. Inspect the exact version and its review status before adapting it. Executable availability, semantic qualification and maintainer approval are separate states; a source change requires a new version and fresh review.

Use source registrations to find documents, the authored Cedar example to try the API, and the eBay candidate to reproduce the offline library workflow. Registration alone does not establish that a platform’s rules have been translated. Contribution guide.

Start with the checked example request and the Antaeus API quickstart. For related rule design, see marketplace moderation and moderation categories versus custom policies.