How OACP Maps Catalog, Price, Inventory, and Policy into Buyer-Safe Artifacts

Summary

Update, 20 October 2026. Since this post was written, Grantex signs every OACP artifact (ES256) and AgenticOrg's main branch checks each signature before caching. A fixed-rule arbiter now decides every purchase handoff, POS handoff and checkout completion, allow or refuse, without waiting for a person, and a ledger records each commerce change. UCP and ACP checkout, Grantex mandates and a Plural payment executor exist behind switches that default to off, so with the defaults nothing moves money. The AgenticOrg changes are not yet in its production deployment. The newer post 'OACP explained: one trust layer under UCP, ACP and AP2' has the current picture. The UCP-style capability list in the protocol adapters was replaced by the merchant's UCP business profile in the published shape.

In this reference model, OACP artifacts carry source references, timestamps, TTL, issuer, scope, hashes, revocation posture, risk tier, and blocked capabilities so a buyer agent can decide whether to answer, refresh, prepare, or refuse.

Artifact Families

The repository schema describes merchant profile, seller agent card, connector evidence, catalog, price, inventory, policy, public discovery state, mandate-capability evidence, protocol adapter profile, and request/status artifact families.

Cache Rules

The intended cache scope is buyer agent, seller agent, tenant, and merchant. A deployment should answer non-binding questions only when TTL and revocation checks pass, and should fail closed for expired, revoked, stale, mismatched, private, raw, or executable records.

What Artifacts Do Not Do

Artifacts do not create checkout sessions, orders, payments, refunds, returns, holds, shipping labels, or mandates. They provide trusted evidence and compatibility mappings. Execution remains with merchant, provider, bank, POS, or support systems.