Marketplace listings
“Do not allow weapons, counterfeit goods, or prescription drugs.”
Build custom marketplace moderation rules with a versioned policy and explicit decision handling.
Explainer
What is semantic policy enforcement?
Semantic policy enforcement is checking content against a policy written in natural language and turning the result into an explicit, versioned, testable decision. It applies when deciding whether a rule is met requires interpreting meaning.
The problem
Some rules are about meaning, not values.
A rule such as price > 0 can be checked by ordinary code. A rule such as “no counterfeit goods” cannot: a listing never contains a field called counterfeit. Someone, or something, has to read it and judge. Semantic policy enforcement makes that judgment explicit, inspectable, and testable.
User-generated content
“Send posts that target a person with harassment to human review.”
Compare moderation categories and custom policies, then use the Antaeus API for the decision.
Support and AI replies
“A reply must not promise a refund or give medical advice.”
Vendor onboarding
“Deny services in a prohibited category; approve complete, low-risk submissions.”
Where it fits
A different question from identity and permissions.
Authentication answers who. Authorization answers what they may do. Semantic policy enforcement answers whether a specific piece of content or state complies with a policy whose meaning must be interpreted. It complements the other layers; it replaces none of them.
| Approach | Question it answers | Decided by | Best for |
|---|---|---|---|
| Authentication | Who is making the request? | Credentials and identity providers | Proving identity |
| Authorization models and policy engines such as RBAC; OPA or Cedar | May this principal act? Does this structured request or configuration satisfy the rules? | Deterministic rules over structured attributes | Access control and structured policy checks |
| Business rules in code | Do these values satisfy exact conditions? | Ordinary program logic | Anything expressible precisely |
| Prompting a model directly | What does the model conclude about this? | The model decides both the judgment and the outcome, usually without a versioned policy or deterministic reduction | Exploration, drafting, and low-stakes classification |
| Semantic policy enforcement | Does this content comply with a policy that needs interpretation? | An evaluator judges each condition; the policy decides the outcome | Meaning-heavy rules that need attributable, testable decisions |
How a decision is made
Separate the judgment from the consequence.
- Write the policy as named rules. Each rule has a plain-language condition and a fixed outcome: allow, review, or deny. The policy is versioned and identified by a digest.
- Ask an evaluator only about conditions. A language model, or a deterministic fixture in tests, reports whether each condition is matched, not matched, or indeterminate. It never sees the outcomes.
- Apply the outcomes deterministically. Matched rules contribute their outcomes, deny takes precedence, and the policy’s default applies when nothing matches.
- Make failure explicit. Timeouts, refusals, malformed answers, and unresolved conditions produce a failure decision, unless a matched deny already applies, instead of a silent allow.
- Record the evidence. Each decision names the policy version, the evaluator (and model, when one is used), and its attempts, so it can be inspected and re-run against the same policy version.
defaultOutcome: review
rules:
- id: prohibited-item
when: Offers weapons, counterfeit goods,
or prescription drugs.
outcome: deny
- id: complete-listing
when: Clearly describes a legal item
with its condition and price.
outcome: allow
input "1:1 replica watch … fake certificate"
decision deny
policy marketplace-listing sha256:d1553c7d…
prohibited-item matched → deny
complete-listing not_matched
model gpt-5.4-mini-2026-03-17A real run of the open-source marketplace example, abbreviated; rule conditions are shortened.
Principles
What a trustworthy practice requires.
A model’s answer is one input to a decision, not the decision itself. These are recommended practices; Antaeus implements the first four today and treats evaluator comparison and measurement as open work.
Outcomes belong to the policy
Evaluators judge conditions. What happens next is written in the policy, reviewed, and versioned.
Uncertainty is visible
Indeterminate and failed judgments become an explicit failure (unless a matched deny applies) that your application can route to a person, never an automatic allow.
Decisions are attributable
Every decision identifies the exact policy version and the evaluator, model, and attempts that produced it.
Policies are tested like code
Named cases with expected outcomes catch regressions when a policy changes; running them against live evaluators when a prompt or model changes is recommended practice.
Providers are replaceable
A provider-neutral boundary should let teams compare evaluators on the same policies and cases.
Measure before enforcing
Quality, review burden, latency, and cost should be measured on representative cases before automation takes over.
Boundaries
When not to use it.
- The rule can be written exactly. Keep thresholds, formats, and lookups in ordinary code, which is cheaper, faster, and fully predictable.
- The question is identity or permission. Use authentication and an authorization system.
- The decision must be correct every time with no review path. Semantic judgments can be wrong, so a person or a conservative application fallback must handle uncertainty and failure.
- The action is irreversible and high-stakes. Use semantic decisions to route work to people, not to replace accountable human judgment.
Questions
Frequently asked questions.
Is semantic policy enforcement the same as content moderation?
Content moderation is one application. The same approach applies to any policy about meaning, including marketplace rules, support and AI replies, onboarding reviews, and internal compliance checks.
How is it different from OPA or Cedar?
Policy engines such as Open Policy Agent and Cedar evaluate deterministic rules over structured attributes, typically for authorization. Semantic policy enforcement handles conditions that require interpreting unstructured language. The two work well together: authorize the request first, then check the content.
Can a language model be trusted to enforce a policy?
Not blindly. A model’s judgment should be one bounded input: it answers conditions, the policy decides outcomes, uncertainty becomes an explicit failure your application can route to review, and quality is measured on representative cases before any decision is automated.
What happens when the evaluator is unsure or unavailable?
The condition is recorded as indeterminate or failed, and the decision becomes failure unless a matched deny already applies. Your application can then route it to a person or retry.
Do I need an account or a hosted service?
No. Antaeus is an open-source implementation that runs locally as a single binary. A credential-free quickstart shows the full decision contract. The experimental semantic evaluator uses your own OpenAI key and sends the policy conditions and input to OpenAI.
Try it
Run a semantic policy decision locally.
Antaeus is an early, Apache-2.0 open-source implementation of semantic policy enforcement. Install it with brew install antaeusio/tap/antaeusand follow the worked example. Its semantic evaluator is experimental and not yet measured; see the research boundary.