> ## Documentation Index
> Fetch the complete documentation index at: https://docs.grantex.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# OACP Architecture

> The Grantex view of the OACP four-party architecture.

# OACP Architecture

Canonical end-to-end flow: [OACP authority overview](./overview).

OACP separates facts, authority, runtime behavior, and payment rails so no agent has to invent commerce state.

```mermaid theme={null}
flowchart TD
  config[AgenticOrg merchant config] --> agenticSeller[AgenticOrg Seller Commerce Agent]
  shopify[Shopify and merchant systems] -->|catalog, price, inventory, policy facts| agenticSeller
  future[WooCommerce/ERP/bank/provider refs] -->|pending-adapter config only| config
  agenticSeller -->|redacted connector evidence| grantex[Grantex OACP authority]
  grantex -->|signed/internal artifacts or refusals| cache[AgenticOrg OACP cache]
  cache --> buyerAgent[AgenticOrg buyer agent]
  buyerAgent --> web[Web]
  buyerAgent --> mcp[MCP clients]
  buyerAgent --> openapi[OpenAPI clients]
  buyerAgent --> a2a[A2A card]
  buyerAgent --> search[Public catalog/search when enabled]
  buyerAgent --> wa[WhatsApp]
  buyerAgent --> tg[Telegram]
  buyerAgent -->|capability check only| provider[Pine Labs Plural/P3P, bank/POS/provider rails]
  provider -->|redacted evidence ref| cache
```

## Responsibilities

| Party | Owns | Does not own |
| - | - | - |
| Merchant systems | Catalog, price, inventory, order, policy, support, and source timestamps. | OACP artifact policy. |
| AgenticOrg | Merchant self-service config, Seller and buyer agents, Shopify connector runtime, pending-adapter setup refs, cache, buyer channels, public publishing, POS handoff orchestration, and capability verification. | Canonical OACP authority or payment/bank/POS rail execution. |
| Grantex | Policy, trust, artifacts, verification, and adapter authority. | Merchant connector runtime, buyer sessions, orders, or payments. |
| Provider/bank/POS rails | Mandate and payment execution, provider status, settlement, receipt evidence, and provider webhooks. | OACP trust authority or buyer-agent answers. |

## Why Grantex Is Not In Every Loop

Grantex signs and verifies authority artifacts. AgenticOrg can answer non-binding questions from valid cached artifacts until TTL, revocation, or policy state requires refresh. This reduces latency and avoids making Grantex a relay for every buyer question while preserving a hard boundary for commitment requests.

## Failure Shape

```mermaid theme={null}
flowchart LR
  request[Buyer request] --> classify{Commitment?}
  classify -->|No| cache{Valid cached artifacts?}
  cache -->|Yes| answer[Answer with source and freshness]
  cache -->|No| refresh[Refresh or refuse]
  classify -->|Yes| handoff{Provider and merchant approval present?}
  handoff -->|Yes| prepare[Prepare handoff only]
  handoff -->|No| refuse[Refuse with blocker]
```

## Ownership

Grantex is owned by Orchestrum Technologies LLP. Inventor and owner: Sanjeev Kumar. Ownership contact: [sanjeev@orchestrum.in](mailto:sanjeev@orchestrum.in) or [mishra.sanjeev@gmail.com](mailto:mishra.sanjeev@gmail.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.