AIRCP v0.1 Specification

AIRCP — AI-Readable Catalog Protocol — is an open specification that defines how online product catalogs should be structured to be discoverable, parseable, and transactable by AI agents. AIRCP is to commerce what MCP (Model Context Protocol) is to AI tool use: a thin, semantic, agent-friendly layer over the existing commerce internet.

This document specifies AIRCP version 0.1. The protocol defines two tiers of product attributes (Core and Enhanced), a discovery mechanism using a well-known URL, transaction hooks for agent-initiated purchases, and a trust layer for merchant verification. AIRCP is designed to be implementable by any catalog system without modification of underlying commerce infrastructure.

AIRCP exists because the next decade of commerce will be conducted by AI agents acting on behalf of consumers, and the protocols that govern how those agents discover and transact against catalogs have not yet been standardized. AIRCP proposes a path.

1.1 The problem

The commerce internet was designed for human readers. Product catalogs are rendered as HTML pages optimized for visual consumption, with semantic structure encoded primarily in markup conventions (schema.org, Open Graph) that were retrofitted onto an architecture built for browsers, not agents.

AI agents acting on behalf of consumers face three structural problems when transacting against this catalog surface:

• Discovery: There is no standard way for an agent to discover which catalogs exist, what they contain, or how to query them. Agents resort to web scraping, search engine APIs, or per-merchant integrations.
• Interpretation: Product data is inconsistent across merchants. Attribute names differ, types are unspecified, important context like materials, sizing, and suitability is buried in unstructured description text or absent entirely.
• Transaction: Even when an agent identifies the right product, completing the purchase requires merchant-specific integration. There is no standard way for an agent to add to cart, check out, or confirm a purchase across catalogs.

AIRCP addresses these three problems by specifying a thin, semantic protocol that any catalog can implement without changing its underlying commerce infrastructure.

1.2 What AIRCP is

AIRCP is a specification, not a service. The protocol defines:

1. A discovery mechanism: a well-known URL pattern that any agent can query to find an AIRCP-compatible catalog.
2. A catalog format: a structured JSON representation of products with Core and Enhanced attributes.
3. A transaction interface: standard methods for agents to query, add to cart, check out, and receive purchase confirmations.
4. A trust layer: a verification mechanism for merchant identity and catalog integrity.

AIRCP is implementable by any catalog system. The protocol is content-agnostic and does not prescribe specific product categories, business models, or commerce platforms. A Shopify store, an enterprise PIM, a marketplace, or a single-product brand can all expose AIRCP.

1.3 What AIRCP is not

AIRCP is not a marketplace, a search engine, a payment processor, or a fulfillment system. AIRCP does not host catalogs, route transactions, or take a cut of sales. AIRCP is a specification of how catalogs and agents interact; the underlying infrastructure remains the responsibility of merchants, payment processors, and agents.

AIRCP does not require centralized registration. Any catalog publisher can expose an AIRCP endpoint without notifying any central authority. A registry of known AIRCP-compatible catalogs may emerge over time as community infrastructure, but is not required for the protocol to function.

1.4 Status of this document

AIRCP v0.1 is a draft published for public review and community feedback. The specification is expected to evolve based on input from implementers, agent developers, and merchants over a period of approximately 90 days following initial publication, after which a v1.0 specification will be released.

1.5 Relationship to other protocols

AIRCP is one layer of a multi-protocol stack that defines agentic commerce. It composes with — and explicitly does not duplicate — the following standards.

The agentic commerce stack

The two-layer model: open catalog, closed reasoning

AIRCP defines the Enhanced Catalog Layer — what merchants publish. It does NOT define the Relevancy Reasoning Layer — how agents match published Tier 2 attributes against a specific buyer to produce a personalized recommendation. This separation is deliberate.

• The Enhanced Catalog Layer is a coordination problem: every merchant should expose product data the same way, so every agent can read it. Solving coordination problems requires open standards. AIRCP is MIT licensed for this reason.
• The Relevancy Reasoning Layer is a differentiation problem: agents compete on how well they understand their users and how well they match products to users. Solving differentiation problems requires proprietary innovation. AIRCP intentionally does not standardize this layer.

Tier 2 attributes are published openly in the catalog, but they are interpretively useful only when matched against a buyer model — and the buyer model is the agent's proprietary asset, not part of the protocol. An agent without a sophisticated buyer model can still consume Tier 2 attributes, but it must rely on user-stated criteria within a single conversation rather than a persistent buyer profile. Agents with sophisticated buyer models (such as continuously-learning taste models built from quiz responses, revealed preferences, and purchase behavior) gain disproportionately more value from Tier 2 attributes than stateless agents do.

This separation means AIRCP can be fully open without commoditizing agents that build proprietary buyer reasoning on top of it.

Why the stack has a gap

UCP, AP2, A2A, and MCP each solve real problems and together cover most of the agentic commerce surface. But all four assume the catalog they are reasoning about is already AI-readable in the semantic sense — that fit profiles, persona compatibility, occasion suitability, and other interpretive attributes are present and machine-parseable. In practice, this is rarely true. The catalog data retailers expose today was designed for browsers and search engines. It is sparse, inconsistent across merchants, and missing the semantic dimensions an AI agent needs to make a taste-aware recommendation.

A concrete example: an agent helping a user find "a workplace-appropriate merino sweater that pairs with chinos and runs true to size" can complete the transaction via UCP and authorize payment via AP2 — but only if some catalog has already exposed the workplace_appropriate, pairs_well_with, and runs attributes in a structured form. Today most catalogs do not. AIRCP defines the standard for those attributes.

How AIRCP composes with each layer

• AIRCP and UCP: An AIRCP-compliant catalog publishes the semantic product layer. A UCP-compliant catalog publishes the transaction layer. The same merchant can — and is encouraged to — implement both. An agent that discovers a product via AIRCP and wants to complete the purchase should defer to UCP's checkout session format. AIRCP does not define a competing checkout flow; see Section 7.
• AIRCP and AP2: Payment authorization for AIRCP-discovered products should use AP2's Intent Mandate and Cart Mandate flow. AIRCP does not define a competing payment authorization mechanism.
• AIRCP and A2A: Agents implementing AIRCP discovery and reasoning can communicate with other agents via A2A. AIRCP does not define agent-to-agent communication.
• AIRCP and MCP: A catalog can expose its AIRCP endpoint as an MCP tool, allowing MCP-aware agents to consume AIRCP-formatted product data through the MCP interface. AIRCP and MCP are complementary.

Why AIRCP is published separately rather than as a UCP extension

UCP's three core capabilities at launch (Checkout, Identity Linking, Order Management) are oriented toward the transaction surface. The semantic catalog layer is a distinct concern with distinct authors — typically not the engineers who own checkout but the teams who own product information management, merchandising, and AI-driven recommendation. Conflating these layers in one specification would slow adoption of both. Publishing AIRCP as a thin separate standard that explicitly composes with UCP allows each protocol to evolve at the speed of its domain.

We expect — and welcome — future versions of UCP to formally reference AIRCP-compliant catalog endpoints as an input source, and future versions of AIRCP to formally reference UCP-compliant transaction endpoints as the recommended checkout layer. Section 7 of this specification reflects that intent.

The following principles guided the design of AIRCP v0.1. Future revisions of the specification should be evaluated against these principles.

Principle 1: Catalog-agnostic

AIRCP must be implementable by any catalog system without modification of the underlying commerce infrastructure. A merchant should be able to add AIRCP support to an existing Shopify, WooCommerce, BigCommerce, custom PIM, or single-page e-commerce site by adding a single well-known endpoint.

Principle 2: Agent-first, not human-first

AIRCP optimizes for AI agent consumption, not human readability. Attribute names are explicit. Types are strict. Edge cases are surfaced rather than hidden. Where this conflicts with human-readable conventions (verbose attribute names, redundant type information), agent-first wins.

Principle 3: Two tiers, one protocol

AIRCP defines two tiers of attributes. Tier 1 (Core) is mandatory and deterministic: every conforming catalog must expose Core attributes, and Core attributes have unambiguous types and meanings. Tier 2 (Enhanced) is optional and semantic: it includes attributes like persona compatibility, taste suitability, and pairing recommendations that require sophisticated production methodology.

The protocol defines Tier 2 as a set of interface contracts. Implementations are responsible for producing Tier 2 values. AIRCP does not prescribe how Tier 2 values are produced; competition on production methodology is expected and encouraged.

Principle 4: No central authority required

AIRCP is a specification, not a service. No party is required to register, pay, or apply for permission to implement AIRCP. The specification is MIT-licensed and freely implementable. A registry of AIRCP-compatible catalogs may emerge as community infrastructure, but is explicitly not required for the protocol to function.

Principle 5: Forward-compatible by default

AIRCP catalogs include a version field. Agents are expected to handle catalogs of older versions gracefully. The protocol defines a minimum compatibility envelope and a process for non-breaking extension.

This section uses the conformance keywords defined in RFC 2119 (MUST, MUST NOT, SHOULD, SHOULD NOT, MAY). When these keywords appear in capitals elsewhere in this document, they carry the meanings defined in that RFC.

3.1 Conforming catalog

A conforming AIRCP catalog MUST:

1. Expose a discovery document at the well-known URL defined in Section 4.
2. Include all Core (Tier 1) attributes for every product in the catalog.
3. Use the AIRCP JSON schema for all attribute values.
4. Declare the AIRCP version it conforms to.

A conforming catalog SHOULD:

1. Expose Enhanced (Tier 2) attributes where available.
2. Support transaction hooks for agent-initiated checkout.
3. Sign catalog responses for trust verification (see Section 8).

3.2 Conforming agent

A conforming AIRCP agent MUST:

1. Resolve catalogs via the well-known URL pattern.
2. Parse and interpret Core attributes according to their defined types.
3. Handle missing Enhanced attributes gracefully without failure.
4. Respect rate limits and conformance signals returned by catalogs.

AIRCP uses the well-known URL pattern defined in RFC 8615 for catalog discovery. Any HTTPS domain MAY expose an AIRCP-compatible catalog by serving a discovery document at the path defined below.

4.1 Discovery endpoint

The discovery document MUST be available at:

https://{host}/.well-known/aircp.json

Where {host} is the fully qualified domain of the catalog publisher. The response MUST be a JSON document with the structure defined in Section 4.2.

4.2 Discovery document structure

{
  "aircp_version": "0.1",
  "catalog_name": "Example Store",
  "catalog_url": "https://example.com",
  "catalog_endpoint": "https://example.com/api/aircp/catalog",
  "product_endpoint_pattern": "https://example.com/api/aircp/product/{id}",
  "search_endpoint": "https://example.com/api/aircp/search",
  "ucp_endpoint": "https://example.com/.well-known/ucp.json",
  "transaction_endpoint": "https://example.com/api/aircp/transaction",
  "verified": false,
  "last_updated": "2026-05-12T10:00:00Z",
  "contact": "aircp@example.com",
  "capabilities": [
    "product_attributes",
    "relevancy_attributes",
    "ucp_compatible",
    "search"
  ]
}

4.3 Discovery document fields

"aircp_version": "0.1"

"catalog_name": "Example Store"

"catalog_url": "https://example.com"

"catalog_endpoint": "https://example.com/api/aircp/catalog"

"product_endpoint_pattern": "https://example.com/api/aircp/product/{id}"

"search_endpoint": "https://example.com/api/aircp/search"

"transaction_endpoint": "https://example.com/api/aircp/transaction"

"verified": false

"last_updated": "2026-05-12T10:00:00Z"

"contact": "aircp@example.com"

"capabilities": ["product_attributes", "relevancy_attributes", "ucp_compatible", "search"]

Tier 1 attributes describe a product comprehensively — both its intrinsic properties (material, color, weight) and its relational properties (style classification, image projection, contexts where it works, products it pairs with). Tier 1 is buyer-agnostic: every Tier 1 attribute is true about the product itself, independent of who is buying it.

Tier 1 extends what UCP's catalog spec defines (title, description, price, variants, options, media, rating) with the enriched descriptive and relational attributes an AI agent needs to reason about a product before matching it to a specific buyer.

This section defines all Tier 1 attributes. Implementations MUST produce all required Tier 1 attributes for every product. Implementations SHOULD produce all optional Tier 1 attributes when the information is available. Implementations that wish to be UCP-compatible SHOULD also implement UCP's catalog schema; AIRCP Tier 1 is designed to nest cleanly inside a UCP-compliant catalog response via the metadata field, or to be published in parallel at a separate AIRCP endpoint.

"id": "prod_a47x9q"

"sku": "SHIRT-WHT-MED"

"gtin": "00012345678905"

"brand": "Patagonia"

"title": "Lightweight Merino Wool Crew Neck Sweater"

"description": "100% merino wool crew neck sweater. Lightweight 250gsm weight suitable for layering. Ribbed cuffs and hem. Machine washable on wool cycle."

"images": [
  {
    "url": "https://example.com/img/sweater_main.jpg",
    "alt_text": "White merino sweater, front view",
    "width": 1200,
    "height": 1600
  }
]

"category": "Apparel > Tops > Sweaters"

"tags": ["merino", "sweater", "layering", "fall", "winter"]

"price": {
  "amount": 145.00,
  "currency": "USD",
  "original_amount": 195.00
}

"availability": "in_stock"

"inventory_count": 47

"variants": [
  {
    "id": "prod_a47x9q_sm",
    "variant_attributes": { "size": "S" },
    "price": { "amount": 145.00, "currency": "USD" },
    "availability": "in_stock"
  }
]

"dimensions": {
  "length": 28,
  "width": 22,
  "height": 1,
  "unit": "in"
}

"weight": { "value": 350, "unit": "g" }

"materials": [
  { "name": "merino wool", "percentage": 100 }
]

"shipping": {
  "ships_from": "US",
  "available_destinations": ["US", "CA"],
  "free_shipping_threshold": { "amount": 100, "currency": "USD" },
  "estimated_days": { "min": 3, "max": 7 }
}

"returns": {
  "window_days": 30,
  "restocking_fee": null,
  "conditions": "Unworn, with tags"
}

"style_classification": ["minimalist", "scandinavian", "timeless"]

"image_projection": ["understated_confidence", "quiet_luxury", "professional"]

"context_suitability": ["workplace", "client_meeting", "smart_casual_dinner"]

"pairs_with": [
  { "category": "chino_pants", "strength": 0.9 },
  { "category": "tailored_trousers", "strength": 0.75 },
  { "product_id": "prod_b58y2r", "strength": 0.85 }
]

"substitute_for": [
  { "product_id": "prod_c69z3s", "reason": "same fit and weight, different color" }
]

"weather_suitability": {
  "temperature_range_c": { "min": 5, "max": 18 },
  "conditions": ["wind"],
  "seasons": ["fall", "winter", "early_spring"]
}

"aesthetic_compatibility": {
  "design_era": "contemporary",
  "color_family": "neutrals",
  "material_palette": ["wool", "cotton", "leather"]
}

Tier 2 attributes are buyer-relevant: they describe a product in terms designed to be matched against a specific buyer's profile, preferences, body, context, and history. Where Tier 1 says "this is a slim-fit merino sweater in oatmeal," Tier 2 says "this sweater fits petite-to-average builds well, suits a minimalist-professional persona, works for client-facing settings."

Tier 2 attributes are published openly in the catalog like Tier 1. They are interpretively useful only when matched against a buyer model. An agent without a sophisticated buyer model can still consume Tier 2 attributes — using them as filters against user-stated criteria within a single conversation — but agents with persistent, continuously-learning buyer models gain disproportionately more value.

This separation is deliberate. AIRCP defines what Tier 2 attributes are (Enhanced Catalog Layer). AIRCP does not define how an agent matches them against a specific buyer (Relevancy Reasoning Layer). The Relevancy Reasoning Layer is where AI agents differentiate from each other; standardizing it would erase that differentiation and slow innovation in the agent space.

Implementations that produce Tier 2 attributes MUST declare "relevancy_attributes" in the discovery document's capabilities array. Implementations MAY produce a subset of Tier 2 attributes (e.g., only fit_profile and persona_compatibility, omitting others).

"persona_compatibility": {
  "minimalist_professional": 0.92,
  "sustainable_aesthete": 0.78,
  "tech_forward_pragmatist": 0.45
}

"fit_profile": {
  "fit_type": "regular",
  "best_for_body_shapes": ["rectangle", "inverted_triangle"],
  "runs": "true_to_size"
}

"style_descriptors": ["minimalist", "workplace_appropriate", "timeless"]

"color_attributes": {
  "primary_color": "oatmeal",
  "color_family": "beige",
  "hex": "#D6CCBA",
  "warmth": "warm",
  "saturation": "muted"
}

"occasion_suitability": {
  "casual_daily": 0.9,
  "workplace": 0.85,
  "formal_event": 0.2,
  "outdoor": 0.6
}

"season_suitability": {
  "spring": 0.7,
  "summer": 0.3,
  "fall": 0.95,
  "winter": 0.95
}

"pairs_well_with": [
  { "category": "chino_pants", "pairing_strength": 0.9 },
  { "category": "denim_jeans", "pairing_strength": 0.85 },
  { "category": "tailored_trousers", "pairing_strength": 0.75 }
]

"complements": [
  "prod_b58y2r",
  "example.com:prod_c69z3s"
]

"quality_signals": {
  "construction_quality": "premium",
  "durability_score": 8.5,
  "expected_lifespan_years": 5,
  "origin_country": "IT"
}

"sustainability": {
  "certifications": ["GOTS", "Fair Trade"],
  "recycled_content_percentage": 0,
  "repairable": true,
  "end_of_life_options": ["recyclable", "biodegradable"]
}

"care_instructions": {
  "wash_method": "machine_cold_wool",
  "dry_method": "lay_flat",
  "iron_method": "low_heat",
  "dry_clean": false
}

"reasoning_summary": "A workhorse sweater for someone who prioritizes longevity. The 250gsm weight makes it versatile across seasons, and the merino composition handles a wider temperature range than most cotton or synthetic alternatives."

"extensions": {
  "shoop.verdict_color": "strong_buy",
  "shoop.taste_match_score": 0.91
}

The transaction hooks defined in this section are an optional fallback for catalogs that have not yet implemented UCP. They define a minimal transaction interface so that AIRCP-only catalogs can still be transacted against by AIRCP-aware agents. We expect this section to be deprecated in AIRCP v1.0, with formal redirection to UCP for all transaction flows.

Catalogs that support AIRCP transaction hooks MUST declare "transaction_hooks" in their discovery document capabilities and expose a transaction_endpoint. Catalogs that implement UCP SHOULD declare "ucp_compatible" in their capabilities instead, and link to their UCP discovery endpoint in the ucp_endpoint field of the AIRCP discovery document.

7.1 Transaction flow

The AIRCP transaction flow is:

1. Agent submits a transaction_intent to the transaction_endpoint, specifying the product, variant, quantity, and shipping/billing details.
2. Catalog responds with a transaction_session containing a session_id, total cost, and any required next steps (e.g., payment authorization URL).
3. Agent completes any required steps (e.g., payment) and submits transaction_confirmation to finalize the purchase.
4. Catalog responds with a transaction_result containing the final status, order ID, and any post-purchase information.

7.2 Transaction intent

POST to transaction_endpoint with the following structure:

{
  "action": "create_intent",
  "items": [
    {
      "product_id": "prod_a47x9q",
      "variant_id": "prod_a47x9q_md",
      "quantity": 1
    }
  ],
  "shipping_address": {
    "name": "...",
    "line1": "...",
    "city": "...",
    "postal_code": "...",
    "country": "US"
  },
  "agent_metadata": {
    "agent_id": "agent_xyz",
    "acting_on_behalf_of": "user_abc"
  }
}

7.3 Transaction session response

{
  "session_id": "sess_5x9q2v",
  "total": { "amount": 158.95, "currency": "USD" },
  "breakdown": {
    "subtotal": { "amount": 145.00, "currency": "USD" },
    "shipping": { "amount": 8.95, "currency": "USD" },
    "tax": { "amount": 5.00, "currency": "USD" }
  },
  "requires": ["payment_authorization"],
  "payment_url": "https://example.com/pay/sess_5x9q2v",
  "expires_at": "2026-05-12T11:00:00Z"
}

7.4 Transaction confirmation

POST to transaction_endpoint with:

{
  "action": "confirm",
  "session_id": "sess_5x9q2v",
  "payment_authorization": "auth_token_returned_from_payment_url"
}

7.5 Transaction result

{
  "status": "confirmed",
  "order_id": "ord_abc123",
  "order_url": "https://example.com/orders/ord_abc123",
  "estimated_delivery": "2026-05-19",
  "tracking_available_at": "https://example.com/orders/ord_abc123/tracking"
}

7.6 Error handling

Transactions may fail at any stage. Catalogs MUST return HTTP 400-class errors for client errors and 500-class for server errors, with a JSON body containing:

{
  "error": "out_of_stock",
  "error_description": "Product prod_a47x9q variant md is no longer available.",
  "resolution": "Try a different variant or notify the user."
}

Standard error codes: "out_of_stock", "invalid_variant", "shipping_unavailable", "payment_failed", "session_expired", "rate_limited", "unauthorized", "internal_error".

AIRCP includes an optional trust layer for merchant verification. v0.1 defines the verification mechanism but does not establish a centralized trust authority. Future versions of the specification may define community trust authorities or distributed verification mechanisms.

8.1 Self-asserted verification

In v0.1, catalogs MAY set the "verified" field in their discovery document to true if they have completed self-attestation. Self-attestation requires:

1. Publishing a verification document at https://{host}/.well-known/aircp-verification.json
2. Including a cryptographic signature over the discovery document using a publicly verifiable key (e.g., a JWS in the discovery document headers)
3. Listing the merchant's legal entity name, registered country, and a verifiable contact method

Agents SHOULD treat self-attestation as a weak trust signal in v0.1. Stronger verification mechanisms are expected in v1.0.

8.2 Catalog response signing

Catalogs MAY sign catalog responses to prove integrity. Signing uses standard JWS (JSON Web Signature). Agents that verify signatures MUST handle unsigned responses gracefully.

8.3 Rate limiting and abuse signals

Catalogs MUST include rate limit headers in API responses:

X-AIRCP-RateLimit-Limit: 1000
X-AIRCP-RateLimit-Remaining: 847
X-AIRCP-RateLimit-Reset: 1715520000

Agents that exceed rate limits SHOULD back off exponentially. Catalogs MAY return HTTP 429 with a "retry_after" field indicating seconds until the next allowed request.

AIRCP uses semantic versioning (MAJOR.MINOR). Changes within a MAJOR version are backward compatible. Changes that break compatibility require a MAJOR version increment.

9.1 Version negotiation

Catalogs declare their AIRCP version in the discovery document. Agents inspect this field and adapt their behavior accordingly. Agents MUST gracefully handle catalogs of versions they were not designed for, falling back to the highest common version.

9.2 Forward compatibility

Within a MAJOR version, agents MUST:

1. Ignore unknown attributes rather than failing.
2. Ignore unknown capability declarations in the discovery document.
3. Handle additional optional fields in transaction responses.

9.3 Deprecation

Attributes or capabilities marked for deprecation in a future version MUST be supported by implementations for at least one MAJOR version cycle (approximately 12 months expected). Deprecation announcements will be published on AIRCP.org and via the protocol's published changelog.

AIRCP publishes a public benchmark suite for testing implementations. The benchmark suite is hosted at github.com/aircp-org/aircp-benchmarks and may be run by any implementation to verify conformance.

10.1 Core benchmark

The Core benchmark tests:

• Presence of all required discovery document fields
• Schema validity of returned product data against the AIRCP JSON Schema
• Presence of all required Core attributes on every product
• Type correctness of all attribute values
• Pagination, rate limiting, and error response correctness

10.2 Enhanced benchmark

The Enhanced benchmark tests Tier 2 attribute quality against a public gold-standard test set. Implementations are scored on attribute coverage (what percentage of products have each Enhanced attribute) and attribute quality (alignment with the gold standard for that attribute).

The gold standard is maintained by the AIRCP community and reflects expert judgment in apparel, home, beauty, outdoor, and other categories. Implementations that produce Enhanced attributes are encouraged to publish their benchmark scores.

10.3 Reference implementations

Reference implementations of AIRCP-compatible catalogs and AIRCP-aware agents are listed at aircp.org/implementations. Reference implementations are encouraged but not certified by any central authority.

AIRCP is governed as an open specification. The current governance model is:

11.1 Specification maintenance

The AIRCP specification is currently maintained by the Shoop team, with input from the public community via GitHub issues and pull requests. Maintenance responsibilities include:

• Reviewing and merging proposed changes
• Releasing new versions of the specification
• Maintaining the official benchmarks
• Resolving disputes about specification interpretation

11.2 Future governance

As AIRCP adoption grows, governance is expected to evolve toward a multi-party model. Possible future structures include:

• A foundation modeled on the OpenJS Foundation or Cloud Native Computing Foundation
• A working group modeled on the W3C or IETF
• A community-elected steering committee

The Shoop team commits to transitioning AIRCP to a multi-party governance structure once the protocol reaches sufficient adoption (defined as: at least 10 production implementations from at least 3 distinct organizations).

11.3 Conflict of interest disclosure

The Shoop team is the primary author of AIRCP and operates a production implementation of AIRCP on shoop.world and (forthcoming) shoop.cloud. This creates a structural conflict of interest. We mitigate this by:

1. Publishing the full specification, including Enhanced attributes, openly under MIT license.
2. Not gatekeeping the protocol. Any party may implement AIRCP without registration or permission.
3. Publishing public benchmarks against which any implementation can be measured.
4. Welcoming community contributions and protocol critique via GitHub.
5. Committing to transition governance once adoption thresholds are met.

This section provides complete reference examples of AIRCP-compatible catalog responses.

12.1 Minimal Core-only product

{
  "id": "prod_min_001",
  "title": "Stainless Steel Water Bottle",
  "description": "24oz double-walled vacuum-insulated bottle.",
  "category": "Home & Kitchen > Drinkware",
  "images": [
    {
      "url": "https://example.com/img/bottle.jpg",
      "alt_text": "Stainless steel water bottle"
    }
  ],
  "price": {
    "amount": 32.00,
    "currency": "USD"
  },
  "availability": "in_stock"
}

12.2 Full Core + Enhanced product (apparel)

{
  "id": "prod_a47x9q",
  "sku": "SWTR-OAT-MED",
  "gtin": "00084012345678",
  "brand": "Northbound",
  "title": "Lightweight Merino Wool Crew Neck Sweater",
  "description": "100% merino wool crew neck...",
  "category": "Apparel > Tops > Sweaters",
  "tags": ["merino", "sweater", "layering"],
  "images": [
    { "url": "https://example.com/img/sweater.jpg" }
  ],
  "price": {
    "amount": 145.00,
    "currency": "USD"
  },
  "availability": "in_stock",
  "inventory_count": 47,
  "materials": [
    { "name": "merino wool", "percentage": 100 }
  ],
  "weight": { "value": 350, "unit": "g" },
  "shipping": {
    "ships_from": "US",
    "available_destinations": ["US", "CA"],
    "estimated_days": { "min": 3, "max": 7 }
  },
  "persona_compatibility": {
    "minimalist_professional": 0.92,
    "sustainable_aesthete": 0.78
  },
  "fit_profile": {
    "fit_type": "regular",
    "runs": "true_to_size"
  },
  "style_descriptors": [
    "minimalist",
    "workplace_appropriate",
    "timeless"
  ],
  "color_attributes": {
    "primary_color": "oatmeal",
    "color_family": "beige",
    "warmth": "warm"
  },
  "occasion_suitability": {
    "casual_daily": 0.9,
    "workplace": 0.85,
    "formal_event": 0.2
  },
  "pairs_well_with": [
    { "category": "chino_pants", "pairing_strength": 0.9 },
    { "category": "denim_jeans", "pairing_strength": 0.85 }
  ],
  "reasoning_summary": "A workhorse sweater for someone who prioritizes longevity. The 250gsm weight makes it versatile across seasons."
}

12.3 Sample discovery document

{
  "aircp_version": "0.1",
  "catalog_name": "Northbound",
  "catalog_url": "https://northbound.example",
  "catalog_endpoint": "https://northbound.example/api/aircp/catalog",
  "product_endpoint_pattern": "https://northbound.example/api/aircp/product/{id}",
  "search_endpoint": "https://northbound.example/api/aircp/search",
  "transaction_endpoint": "https://northbound.example/api/aircp/transaction",
  "verified": false,
  "last_updated": "2026-05-12T10:00:00Z",
  "contact": "aircp@northbound.example",
  "capabilities": [
    "core_attributes",
    "enhanced_attributes",
    "transaction_hooks",
    "search"
  ]
}

13.1 Acknowledgments

AIRCP exists as a semantic layer within a multi-protocol stack. We acknowledge and build on the following open standards:

• MCP (Model Context Protocol): Anthropic's protocol for AI tool exposure, which demonstrated that thin, agent-first protocols can compound community adoption rapidly. MIT licensed.
• A2A (Agent2Agent Protocol): Google's protocol for agent-to-agent communication.
• AP2 (Agent Payments Protocol): The open protocol for agent-initiated payment authorization via Intent Mandates, Cart Mandates, and Payment Mandates. Co-developed by Google with 60+ partners including Mastercard, PayPal, Coinbase, and Adyen. Apache 2.0 licensed.
• UCP (Universal Commerce Protocol): The open protocol for unified commerce transactions — checkout sessions, identity linking, order management — co-developed by Google with Shopify, Etsy, Wayfair, Target, Walmart, and endorsed by Stripe, Salesforce, Visa, and others. Apache 2.0 licensed. AIRCP-compliant catalogs SHOULD be UCP-compliant for transactions.
• schema.org: The web's structured-data vocabulary, which informed our approach to attribute naming and type specifications.
• OpenAPI: The widely-adopted API specification format, which guided our approach to the optional transaction hooks fallback.
• Web Application Manifest and /.well-known: RFC 8615, which provides the discovery pattern AIRCP uses.

AIRCP would not exist without the trail blazed by these efforts. Where AIRCP diverges from any of these conventions, the divergence is intentional and documented. Where AIRCP composes with these standards, the composition is documented in Section 1.5.

13.2 License

This specification is published under the MIT License. The full license text is available at github.com/aircp-org/aircp-spec/blob/main/LICENSE. Implementations of AIRCP are subject to their own licenses. AIRCP places no licensing requirements on implementations.

13.3 Contact

The primary channel for AIRCP communication is GitHub.

• GitHub Issues: github.com/aircp-org/aircp-spec/issues
• GitHub Repo: github.com/aircp-org/aircp-spec
• Website: aircp.org