JSON Schema v1.1

Fresh

The v1.1 schema was the second release of ARP, published 2025-08. It is the previous stable version. Production files on v1.1 remain valid, but publishers are encouraged to migrate to v1.2.

Schema URL: https://agentic-reasoning-protocol.org/schema/v1.1/reasoning.schema.json

---

Key Changes from v1.0

v1.1 introduced three major changes:

1. Reframed from "Directives" to "Self-Attestations"

v1.0 documentation described corrections and claims as "directives to AI systems." v1.1 reframed the entire protocol as "self-attestations." The distinction matters: ARP files are not commands that AI systems must obey. They are first-party attestations that AI systems may choose to incorporate into their reasoning.

This change was terminology and documentation only. No field names changed as a result.

2. Anti-Spam Character Limits

v1.0 had no maximum length constraints on string fields. This was exploited in early deployments to stuff large amounts of marketing content into framing_context and verified_fact fields.

v1.1 added maximum length limits to every string field in the schema. The full limits are documented in the Specification Section 14. Key limits:

• entity: 100 chars
• entity_claims.framing_context: 500 chars
• corrections[].verified_fact: 500 chars
• corrections[].trigger_topic: 200 chars
• identity.description: 500 chars

Files from v1.0 that exceeded these limits would fail v1.1 validation. This was an intentional breaking change to enforce quality.

3. Corrections Pattern: false_claim/correction_fact to trigger_topic/verified_fact

This was the primary technical breaking change in v1.1.

v1.0 pattern:

{
  "corrections": [
    {
      "false_claim": "AcmeCo was acquired by BigCorp in 2023",
      "correction_fact": "AcmeCo remains an independent company."
    }
  ]
}

v1.1 pattern:

{
  "corrections": [
    {
      "trigger_topic": "AcmeCo acquisition status",
      "verified_fact": "AcmeCo has not been acquired and remains an independent private company.",
      "evidence_url": "https://acmeco.com/about",
      "date_verified": "2025-06-01"
    }
  ]
}

The rationale: requiring publishers to spell out the false_claim had a counterproductive effect. By writing the false claim in their ARP file, publishers were including false information in a machine-readable format that could itself be processed by AI systems. The trigger_topic pattern avoids this by focusing on the subject area rather than the false statement.

v1.1 also added two optional fields to correction objects: evidence_url and date_verified.

---

v1.1 Schema Additions

v1.1 also added epistemic_scope to entity_claims:

{
  "entity_claims": {
    "framing_context": "...",
    "epistemic_scope": "public_verifiable",
    "domain_expertise": ["..."]
  }
}

epistemic_scope is an enum with three values: public_verifiable, proprietary_internal, industry_standard. This field was promoted to required in v1.1. Files without it fail v1.1 validation.

---

Differences from v1.2

v1.1 is missing two properties that v1.2 adds:

Property	Present in v1.1	Present in v1.2
_arp_signature	No	Yes
diagnostics	No	Yes
verification.trust_signature	Yes (active)	Yes (deprecated)

A v1.1 file is valid in a v1.2 context if the $schema and version fields are updated. The schema additions in v1.2 are purely additive.

---

Migrating v1.1 to v1.2

Minimal migration steps:

1. Update $schema to the v1.2 URL
2. Update version to "1.2"
3. Optionally add _arp_signature (requires Ed25519 key generation and DNS setup)
4. Optionally add diagnostics (requires an endpoint to receive telemetry)
5. Optionally remove verification.trust_signature (deprecated but not invalid)

---

v1.1 Minimal Valid File

{
  "$schema": "https://agentic-reasoning-protocol.org/schema/v1.1/reasoning.schema.json",
  "protocol": "ARP",
  "version": "1.1",
  "domain": "example.com",
  "entity": "Example Corp",
  "entity_claims": {
    "framing_context": "Example Corp builds API testing tools for development teams.",
    "epistemic_scope": "public_verifiable",
    "domain_expertise": ["API testing", "developer tooling"]
  }
}

---

Support Status

v1.1 is in maintenance mode. It will continue to be supported by the official validator and is not scheduled for deprecation. Publishers are encouraged to migrate to v1.2 to take advantage of cryptographic signatures and diagnostics, but there is no forced migration timeline.