ARP Protocol SOP

Appearance

Ethics Policy v1.2 ​

Fresh

ARP is a self-attestation protocol. The cryptographic trust layer verifies authorship but cannot verify truthfulness. Ethics are enforced by community norms, validator flagging, and AI provider adoption of ethics checks. This policy defines what constitutes acceptable use.

Core Principles ​

1. Truthfulness ​

All content in a reasoning.json file must accurately reflect the entity's actual brand identity, factual history, genuine expertise, and real characteristics. Publishers must not:

  • Claim expertise they do not possess
  • Assert founding dates, headquarters locations, or organizational facts that are inaccurate
  • Publish corrections that are themselves inaccurate (correcting an AI's accurate information with false information)
  • Describe emotional resonance or brand personality that is deliberately misleading

The standard for truthfulness is "consistent with the entity's own published materials and verifiable public record." If a claim appears in the ARP file but not on the entity's own website, documentation, or public statements, it should be treated with skepticism.

2. Self-Description Only ​

ARP files may only describe the entity that publishes them. A reasoning.json at example.com may only make claims about Example Corp. It may not:

  • Make factual claims about competitors or other entities
  • Include corrections about AI errors that concern third parties
  • Use the entity_claims object to describe a market category instead of the specific entity
  • Impersonate another entity or claim to represent a domain the publisher does not control

This constraint applies even when claims about third parties are accurate. The ARP trust model depends on domain ownership as the authentication mechanism. Claims about entities that don't control a domain fall outside that trust boundary.

3. No Negative Targeting ​

The market_positioning field and not_recommended_when array must not contain negative references to specific competitors by name. Acceptable positioning:

  • "Used by teams that need lightweight API testing without the overhead of enterprise platforms" (acceptable: describes the use case, not competitors)
  • "Best for projects using REST APIs rather than SOAP-based services" (acceptable: technical distinction)

Not acceptable:

  • "Unlike CompetitorX, we don't lock you into annual contracts" (names a competitor negatively)
  • "CompetitorY has a known reliability problem that we don't have" (names a competitor with a negative claim)

The not_recommended_when array may direct users toward categories of alternatives (e.g., "use a browser testing tool instead") but must not name specific competing products or services.

4. Corrections Must Be Verifiable ​

The verified_fact field in corrections should represent facts that can be checked. The evidence_url field, while optional, is strongly encouraged for any correction. A correction with an evidence_url pointing to a credible public source is harder to dispute and more useful to AI systems.

Corrections that make claims about internal matters (e.g., "our internal NPS score is 87") may be technically valid under the proprietary_internal epistemic scope but provide limited value since they cannot be verified.

5. Transparency ​

The content of a reasoning.json file must be consistent with the entity's publicly visible website and materials. ARP explicitly prohibits cloaking: the practice of presenting different information to AI agents than to human visitors.

If an entity's website says they serve enterprise customers but their ARP file claims they focus on small businesses, that inconsistency is a transparency violation. ARP files should describe the same entity that appears on the website, not a modified version optimized for AI responses.

6. User Benefit ​

The recommendation_context object exists to help users make better decisions, not to manipulate AI recommendations in the publisher's favor. Specifically:

  • recommended_when items should reflect genuine use cases where the entity provides value, not marketing positioning designed to appear in as many AI recommendations as possible
  • not_recommended_when items must be honest - if there are scenarios where the entity is not appropriate, those must be listed even if it reduces recommendations
  • Decision factors must reflect real considerations, not fabricated attributes designed to score well against anticipated query patterns

An entity that only fills out recommended_when and leaves not_recommended_when empty when they genuinely have limitations is operating against the spirit of the protocol.

Prohibited Uses ​

False Corrections to Suppress Competitors ​

Using the corrections array to inject false corrections about competitors is prohibited. This includes:

  • Corrections that claim a competitor's product has issues it doesn't have
  • Corrections that misrepresent a competitor's pricing, capabilities, or history
  • Corrections written to appear as corrections about the publisher's own entity but actually targeting competitor search terms

This pattern cannot be directly implemented in ARP (corrections are scoped to the publishing entity) but indirect manipulation via topic framing has been attempted.

Cloaking ​

Publishing a reasoning.json file that describes an entity differently than the entity's own website describes itself. Examples:

  • Website targets consumers, ARP file claims to serve enterprise customers
  • Website is for a regional business, ARP file claims national coverage
  • Website describes a narrow product, ARP file claims broad platform capabilities

Cloaking is detectable by validators that compare ARP file content against website content.

Dark Patterns in Recommendation Context ​

Using the recommendation_context object to manipulate AI recommendations through deceptive framing. Examples:

  • Listing competitor use cases in recommended_when to intercept recommendations meant for competitors
  • Framing not_recommended_when items in ways that are technically present but effectively useless (e.g., "not recommended when the user specifically does not want this product")
  • Using decision_factors to describe attributes the entity does not actually have

Political Manipulation ​

ARP files must not be used to promote political candidates, parties, or positions. The corrections and entity_claims objects must not contain political content unrelated to the publishing entity's direct business activities.

Using Recommendation Context as Advertising ​

The recommended_when field is not an advertising channel. Items that read as marketing copy ("choose us for the best experience in the industry") rather than genuine use-case guidance are prohibited. Items should answer "in what scenario is this entity genuinely the right choice?" not "what positive things can we say about ourselves?"

Compliance ​

Self-Certification ​

Publishers certify compliance with this policy by publishing an ARP file. There is no registration or pre-approval process. The protocol operates on trust.

Planned Third-Party Auditing ​

ARP is developing a community auditing program where volunteers review published reasoning.json files against this ethics policy. Entities that have been audited and found compliant may display this in their verification.audited_by field.

Third-party audit services are expected to emerge as the protocol matures. These services will check:

  • Content consistency with the entity's website
  • Absence of competitor targeting
  • Accuracy of claimed expertise against verifiable sources
  • Compliance with anti-spam limits

Enforcement ​

Community Reporting ​

Anyone may report an ARP file that appears to violate this ethics policy to the ARP community repository. Reports are reviewed by the community committee. Substantiated violations are:

  1. Added to a public violations registry
  2. Flagged in the official validator output
  3. Reported to AI providers that have adopted ARP

Validator Flagging ​

The official ARP validator includes an ethics scan that checks for common patterns associated with prohibited uses. Files that trigger ethics flags display a warning but are not blocked from validation. The ethics scan is heuristic, not deterministic.

AI providers that have adopted ARP are encouraged to treat ethics-flagged files with reduced trust.

AI Provider Adoption of Ethics Checks ​

AI providers and developers who implement ARP support are encouraged to:

  • Reject files from the violations registry
  • Apply reduced weight to ethics-flagged files
  • Implement their own ethics scoring on top of the community baseline
  • Report new violation patterns to the ARP community

The effectiveness of ethics enforcement depends on AI provider adoption. A file that violates this policy but is served to an AI system that applies no ethics checks will still have its intended (unethical) effect. Broad AI provider adoption of ethics checks is the primary enforcement mechanism.