Tutorials
Test the Intent Behind an X Reporting Request
Inspect good-faith reporting, explicit reporting abuse and missing context in an authored X policy, then reproduce 28 offline Antaeus cases.
A request to report an account leaves a policy checker with a question: what is the reporter proposing to do, and why? The word “report” alone cannot answer it.
The selected X authenticity candidate in the Antaeus public policy library makes that question testable. It contains six authored rules, coverage and synthetic cases for a small text-based interpretation. Its purpose is to expose the intended boundary so another developer can inspect and challenge it.
Write the cases before trusting the condition
The official X Authenticity page addresses both reporting misuse and permitted good-faith reporting. A useful interpretation needs to preserve that distinction. It also needs to avoid treating a self-applied “good faith” label as proof.
Our candidate accepts English proposal text in input.text. These original synthetic cases express the intended outcomes under its selected checks:
| Described proposal | Authored expectation |
|---|---|
| Manually report something the reporter believes may violate the rules, in good faith | allow, when no other selected abuse or trade is proposed |
| Encourage genuine good-faith customer-support queries through reporting features | allow, under the same narrow scope |
| Coordinate thousands of false reports against someone known not to have broken the rules, while calling it good-faith customer support | deny |
| “Report that X account.” | review: belief, purpose and abuse context are missing |
The third case is a useful adversarial boundary. A reassuring label and an explicit malicious plan appear in the same input. The intended judgment follows the described plan. The fourth case checks a different problem: missing information must remain visible rather than becoming an invented finding of abuse.
These are authored expectations. No qualified model run has classified this expanded suite, and the table does not report measured semantic accuracy.
Keep the question inside the available evidence
This screen evaluates a described proposal. It cannot verify that an account actually broke a rule, that reports were submitted, or that a person has authority to act for an organization.
A claim of organizational permission alone leaves an automated-reporting proposal for review; it does not excuse an explicit abusive plan. The claimed exception needs evidence that text alone cannot establish. Account identity, account history, media and destination safety also remain outside the selected text checks.
The same discipline applies to account access. A text describing an account sale or access barter has a selected deny expectation. A social media manager describing delegated work without a transaction remains review under this screen. The candidate does not turn collaboration into trading, and it does not verify authorization just because the input claims it.
An allow means the described proposal satisfies the selected positive conditions. It is not whole-platform compliance, proof that a target violated rules, or X approval.
Reproduce execution before evaluating a model
Use the released Antaeus v0.7.0 CLI and the exact public artifact commit:
git clone https://github.com/antaeusio/policies.git
cd policies
git checkout 26316e04a874f5636fd654f3cbae16bae06ad940
policy_dir=policies/x-authenticity/versions/2026-10-23.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 26 synthetic content cases and two separate engine scenarios. The fixtures supply authored rule evidence without network access or credentials. They check case bindings and reduction of that evidence; they do not ask a model to decide whether each rule matches.
The engine scenarios separately test that failed evaluation remains failure despite an allow match, and that a matched deny takes precedence over uncertain evidence. Those are execution properties, distinct from the quality of a model’s interpretation.
Inspect the version as a complete package
Read the policy, coverage, provenance and cases together. The coverage identifies 18 source groups, including deferred requirements and linked dependencies. Six selected rules do not imply that six rules implement the whole source.
The provenance records a manual public browser observation on 22 October 2026, with a selector, text method, hash and size. It retains no full source snapshot and makes no automatic freshness claim. The version date identifies authored packaging, not a new X policy announcement.
The candidate is independently produced, has no platform endorsement and remains not_evaluated for semantic qualification. It is unavailable as a hosted X policy selection. The Facebook exception example shows another boundary worth preserving before encoding a rule.
Inspect the exact candidate and its cases, then contribute an original synthetic case if its reporting boundary needs correction. A small, inspectable interpretation gives the next review something concrete to test.