Agentic Commerce Implementation PRD

This document explains what still needs to be built before merchants can self-serve into agentic commerce using Grantex and AgenticOrg. For the consolidated source of truth, read docs/guides/commerce-v1-agentic-commerce-prd.md. This implementation PRD is a supporting summary and must not diverge from that canonical document. It is written for founders, merchants, operators, product teams, and engineers. The short version is simple:

Merchants should connect the systems they already run today. Grantex turns approved public-safe facts from those systems into signed OACP artifacts and policy decisions. AgenticOrg runs the buyer and seller agents, connector workflows, local artifact cache, and channel UX. Provider and fintech rails own mandate and payment execution. Grantex must not become a toll booth for every non-binding agent interaction.

This document is not a rollout approval. It does not enable production Commerce V1, public discovery, checkout/payment creation, live payments, live Plural, or any production allowlist.

Current OACP Runtime Closure Boundary

The launch-closure implementation proves a non-executing OACP runtime vertical: AgenticOrg seller onboarding and read-only connector sync, Grantex internal artifact authority issuance, AgenticOrg durable cache consumption, buyer-safe answers, bridge adapters, and provider-owned capability metadata checks. It does not enable checkout, payment, order, mandate, refund, return, shipment, inventory hold, public discovery publication, live provider execution, or merchant-private API mutation.

1. Architecture In Plain English

Grantex is the trust, protocol, policy, and canonical-artifact authority. It owns artifact rules, public-safe fact validation, source/freshness policy, merchant approval state, consent/passport posture, protocol adapter mappings, and evidence requirements. AgenticOrg is the agent runtime. It owns seller-agent onboarding, connector sync initiation, buyer-agent sessions, local artifact cache across buyer agent, seller agent, tenant, and merchant, channel bridges, refusal UX, and seller/buyer education. It must not become the source of truth for merchants, products, inventory, price, policy, settlement, or refunds. Providers and fintech rails own mandate setup, mandate verification, payment execution, and payment/refund settlement. Grantex stores only non-sensitive evidence references when policy or artifact lineage requires them.

End-To-End Operating Flow

The detailed buyer and seller walkthrough is documented in docs/guides/commerce-v1-end-to-end-agentic-commerce-flow.mdx. Seller one-time setup:

Start in AgenticOrg Seller Commerce Agent and create a merchant onboarding packet for Grantex authority review.
Verify merchant identity and keep private artifacts outside repos.
Connect existing systems through AgenticOrg seller-agent connector workflows, merchant-owned connector platforms, approved external integration providers, or CSV/API.
Declare source-of-truth precedence for catalog, price, inventory, order, fulfillment, support, and payment data.
Configure category preset, required public fields, return/warranty policy, tax, shipping, payment, support, and rollback ownership.
Select allowed agent capabilities and buyer channels.
Run scans, readiness scoring, human review gates, sandbox rehearsal, and rollback checks.
Request the smallest approved rollout, usually read-only discovery first.

Buyer one-time setup:

Choose an approved chat or agent surface, such as ChatGPT, Claude, Gemini, WhatsApp, Telegram, web/mobile, or a future channel.
Link or sign in to create a buyer-agent session.
Set safe preferences such as locale, currency, delivery region, notification path, and accessibility needs.
See what actions the channel can support and what remains blocked.
Approve or deny each payment-affecting action through Grantex consent.

Regular transaction:

Buyer asks the agent to discover, compare, or prepare.
AgenticOrg uses cached signed OACP artifacts when TTL, revocation, and risk rules allow; otherwise it asks Grantex to refresh or verify authority artifacts.
AgenticOrg reads product, price, inventory, delivery, return, policy, and capability facts from artifacts and approved source evidence, not model guesses.
Non-binding discovery can continue locally without routing every message through Grantex.
Commitment-bound actions require boundary, prepared envelope, reconciliation, eligibility, and dry-run checks before future handoff.
Merchant-system confirmation uses approved connector handoff or merchant-owned systems.
Provider-owned mandate/payment capability verification stays with the provider/fintech rail and may be verified directly by AgenticOrg when approved.
Grantex keeps policy, artifact lineage, and non-sensitive evidence references only where required.
AgenticOrg shows buyer-safe status and refuses unsupported claims.

2. Current Implementation Snapshot

The repo already has important foundations:

Capability	Current implementation evidence	Current state
Merchant and tenant control plane	Commerce tenants, merchants, merchant API keys, operator and merchant caller resolution, emergency disable/re-enable, commerce dashboard pages.	Foundation exists; self-serve runtime onboarding is still incomplete.
Category presets	Commerce category preset migration and policy defaults.	Foundation exists; merchant-facing preset workflow needs hardening.
Catalog and variants	Product/variant create, list, search, item detail, bulk dry-run/upsert, patch, archive, CSV/JSON-oriented portal support.	Good V1 base; large async imports and real connector sync still pending.
Inventory	Variant availability buckets and freshness fields: `in_stock`, `out_of_stock`, `pre_order`, `back_order`, `unknown`, `last_synced_at`.	Enough for read-only discovery; not enough for reservations, location stock, delivery promise, or quantity accounting.
Consent and Commerce Passport	Consent request, exchange, verify, revoke, challenge flow, scoped passport checks.	Core trust layer exists; production delivery and AP2-style signed mandate evidence still pending.
Cart and payment intent	Cart draft and provider-neutral payment intent endpoints with idempotency and amount-cap checks.	Mock/sandbox path foundation exists; live provider path remains gated.
Provider evidence and webhooks	Provider capability evidence references, webhook intake metadata, replay metadata, reconciliation metadata, and ops-health posture.	Foundation exists; live provider rails still require approvals and stronger evidence, and provider/fintech rails remain payment authority.
Merchant webhooks	Signed merchant webhook source and `catalog.product.updated` intake.	Good first sync event; price-only, inventory-only, order, fulfillment, return, and support webhooks are pending.
MCP/native agent surface	`merchant.get_profile`, `catalog.search`, `catalog.get_item`, `inventory.check`, `cart.create`, `checkout.create`, `payment.create_intent`, `payment.get_status`.	Correct agent surface; public discovery remains fail-closed.
Docs navigation	Commerce V1 docs group exists in `docs/docs.json`.	Updated by this PRD pass to include this implementation PRD.
Deploy workflow guard	Auth-service and portal deploy workflows have path filters for runtime paths.	Docs-only changes should not trigger Grantex deploy workflows, but CI still runs broad validation.
OACP artifact foundation	C6W3-C6Z internal helpers, tests, docs, authority route, verifier, and AgenticOrg runtime handoff foundations define artifact families, adapter mappings, commitment boundaries, prepared envelopes, evidence reconciliation, eligibility packets, dry-run verifier results, authority requests, cache use, buyer answers, MCP/OpenAPI/A2A/WhatsApp/Telegram bridges, and capability checks.	Runtime implemented for the Shopify read-only OACP vertical; still no checkout/payment/order/mandate execution, public protocol publication, external certification, or live provider claim.

2.1 Current OACP Status Through C6Z

The current OACP implementation is a non-executing runtime vertical, not a live checkout product. The 2026-06-18 production closure run was blocked because the then-mounted AgenticOrg Shopify token returned 401 Unauthorized and the AgenticOrg-configured Grantex token returned 422 tenant_not_provisioned. AgenticOrg now has merchant-scoped Shopify credential storage, adapter payload generation, bridge routes, and purchase-preparation blockers; a real merchant launch still requires valid external credentials and tenant allowlisting.

implemented: internal artifact schemas, public-safe fixtures, adapter previews, commitment boundary resolver, prepared envelopes, response reconciliation, eligibility packets, execution-controller dry-run verifier, internal C6Z authority request route, artifact verifier, and non-enablement flags;
implemented in both repos: Grantex authority helpers/tests/docs and AgenticOrg local consumer/runtime helpers/tests/docs, including seller-agent packet creation, Shopify sync initiation, artifact cache, buyer answer, MCP bridge, and Plural/Pine capability verifier paths;
blocked in production: successful Shopify read-only sync with the mounted token and successful AgenticOrg-to-Grantex tenant provisioning for the configured internal token;
not implemented or not enabled: public OACP spec site, public endpoint, public discovery, execution controller, order/fulfillment/refund runtime, or live checkout/payment;
still blocked: publication, certification, conformance, standards submission, production readiness claims, and any real merchant approval.

3. Target Merchant Journey

The full self-serve journey should feel like this:

Merchant creates a Grantex Commerce account.
Merchant chooses a business category such as electronics, fashion, home, grocery, pharmacy, services, or B2B.
Merchant connects an existing system or uploads a catalog.
Grantex shows a preview of the merchant profile, catalog, prices, inventory, warranty, return policy, and public discovery text.
Merchant selects what AI agents may do:
- browse only;
- create cart drafts;
- request checkout consent;
- read order status;
- request support or return handling.
Grantex runs automated checks for secrets, private data, stale inventory, missing policies, overclaims, and unsupported live paths.
Legal, product, security, ops, rollback, smoke, and evidence owners approve the launch packet.
Merchant rehearses the sandbox flow with synthetic or sandbox data.
Merchant requests production rollout.
Grantex enables the smallest approved surface first, usually read-only discovery, then expands only after smoke evidence and rollback readiness.

4. Existing Merchant Systems

Merchants should not be asked to rebuild their businesses for agents. The merchant-facing connection experience should start in AgenticOrg Seller Commerce Agent. Grantex should validate canonical public-safe facts and evidence refs, not demand custody of every operational credential.

Existing merchant system	Data OACP needs	Correct custody and target model	Fast-track approach
Shopify, WooCommerce, Magento, custom storefront	Product, variant, media, price, availability, categories, collections.	AgenticOrg or merchant/external connector custody; Grantex validates public-safe catalog artifacts.	Start with CSV/manual plus one high-priority connector family. Add webhook freshness.
ERP or PIM	Product master, brand, attributes, tax codes, SKU hierarchy, category truth.	Merchant/external connector custody; Grantex validates source precedence and category artifacts.	Let merchant declare source-of-truth precedence. Record sync source and timestamp.
WMS or inventory system	Stock state, quantity, location, reservation, delivery feasibility.	Merchant/external connector custody; Grantex validates source/freshness and refusal policy.	Keep availability buckets for browse; require stronger model before checkout promises.
OMS	Order creation, order ID, status, cancellation, fulfillment, return status.	Merchant OMS remains operational owner; Grantex validates public-safe status evidence when needed.	Required before live checkout at scale. Start with create/read/status evidence.
Logistics provider	Delivery slots, pickup slots, tracking, failed delivery events.	Logistics/carrier owner remains source; Grantex validates delivery-promise artifacts only after approval.	Needed for order/fulfillment capability and buyer trust.
Payment or mandate provider	Provider-owned mandate capability, payment intent/order, hosted checkout, status webhook, settlement, refunds.	Provider/fintech rail owns mandate and payment execution; Grantex stores only non-sensitive evidence refs when policy requires them.	Start with provider capability verification and mock/sandbox evidence; no live execution.
CRM/support desk	Ticket ID, support conversation, refund request, return request.	Merchant support system remains owner; Grantex validates support/return evidence when needed.	Start with manual handoff/reference; automate only after policy gates.

Connector rule:

A connector imports data. It does not make a merchant live. Live agent access requires readiness checks, merchant approval, policy activation, consent, audit, and rollback ownership.

5. Standards And Protocol Fit

Grantex should maintain one canonical OACP artifact model and produce protocol views from it. The system must not create one separate database per protocol and must not turn protocol adapters into transaction authority.

Surface	Relevant external idea	Grantex implementation requirement
OACP artifacts	Internal trust profile for seller agents, buyer agents, merchant systems, and provider rails.	C6W3-C6Z are internal only; artifacts preserve TTL, source/freshness, refusals, and non-enablement flags.
Native Grantex API	First-party authority APIs for artifacts and policy.	Continue as authority surface, not as a mandatory toll booth for all non-binding cached interactions.
MCP	Agent tool transport. UCP also lists MCP among supported transports.	Expose tools that consume artifacts and preserve refusal semantics.
UCP-style capability profile	UCP discovery uses business/platform profiles, services, capabilities, negotiation, and transports such as REST, MCP, A2A, and embedded. See UCP overview.	Publish profiles only from approved merchant capability state. Do not claim UCP certification until conformance tests exist.
ACP-style checkout	Stripe ACP describes agentic checkout create, retrieve, update, complete, cancel, order, and refund concepts. See Stripe ACP specification.	Map Grantex cart/payment/order state into ACP-compatible shapes where provider and merchant support it.
AP2-style mandate evidence	AP2 secures agent-performed payments through authorization evidence and mandates. See AP2 specification.	Map provider-owned mandate evidence references and Grantex policy/artifact lineage into future evidence without claiming AP2 conformance.
schema.org	Product, Offer, shipping, and return policy metadata are represented by schema.org types. See Product, Offer, OfferShippingDetails, and MerchantReturnPolicy.	Generate public-safe JSON-LD/feed output from approved catalog and policy fields only.

Do not claim certified UCP, ACP, AP2, MPP, A2A, live-provider, or schema.org production readiness until implementation, tests, approvals, and release evidence exist.

6. Comprehensive Gap Register

Gap	User impact	Required implementation	Owning repo	Release gate
Self-serve merchant signup	Merchant cannot join without operator work.	Signup, tenant creation, merchant profile, owner invite, category preset, sandbox/live environment split, onboarding checklist.	Grantex	Merchant can complete sandbox profile without engineering support.
KYB/KYC and legal evidence	Real merchant identity cannot be trusted.	Private artifact references, legal/compliance decision, verification state machine, evidence retention.	Grantex plus external reviewers	No live mode without approved identity and evidence references.
Merchant role model	Owners, developers, ops, support, and finance users need different powers.	RBAC for owner, developer, catalog manager, ops, support, finance, auditor, rollback owner.	Grantex	Sensitive actions require correct role and audit.
Existing-system connector framework	Merchants need their existing stores to sync.	AgenticOrg seller-agent connector initiation, credential-custody selection, source-of-truth precedence, sync jobs, source health, retry, and Grantex artifact validation.	AgenticOrg + merchant/external connector owner + Grantex policy	Connector cannot expose agent capabilities by itself.
Large catalog import	Real merchants have many SKUs.	Async import jobs, dry-run diff, row-level errors, duplicate handling, rollback, idempotency, import history.	Grantex	Import can be retried and audited without data loss.
Catalog data quality	Agents need complete public-safe product facts.	Required field checks by category, image validation, brand/model/specs, warranty summary, return summary, tax/GST metadata.	Grantex	Readiness score blocks missing critical fields.
Inventory depth	Agents must not promise unavailable stock.	Quantity, location, stock confidence, freshness TTL, source system, future reservation/stock hold.	Grantex	Checkout blocked or warned when stale/unknown.
Delivery and pickup promise	Buyers need delivery confidence before checkout.	Delivery options, pickup slots, address serviceability, shipping fee/tax, delivery ETA, carrier/logistics evidence.	Merchant/logistics source + Grantex evidence policy	No delivery promise without fresh evidence.
Pricing, tax, offers, EMI	Agents need correct totals.	Price freshness, tax inclusivity, GST slab, shipping/handling, coupons, discounts, EMI/affordability evidence.	Merchant/provider source + Grantex policy	Agent cannot invent discounts or affordability.
Cart update lifecycle	ACP-style and real checkout need update/cancel flows.	Cart update, recalculate totals, fulfillment option selection, cancel/expire, buyer messages.	Future execution controller + Grantex policy	Idempotent update and audit coverage before any live path.
Order lifecycle	Payment without order operations is incomplete.	Order create/read/list, order status, order permalink/reference, status webhooks, manual review, cancellation.	Merchant OMS + future execution controller + Grantex evidence policy	Paid checkout creates or references an order only after separate approval.
Fulfillment lifecycle	Merchant ops need shipment and pickup tracking.	Fulfillment status, shipment tracking, pickup/delivery slots, partial fulfillment, failed delivery event.	Merchant/logistics source + Grantex evidence policy	Buyer-agent can read only verified status.
Returns and refund requests	Post-purchase trust needs a safe path.	Return/refund request, eligibility preview, manual approval, provider handoff, audit, future provider execution.	Merchant support/provider rail + Grantex policy	No automatic refund execution until separately approved.
Settlement and payouts	Merchants need to know when they are paid.	Settlement/payout read model, provider reconciliation, fee/tax summary, payout export.	Provider/fintech rail + merchant finance + Grantex evidence refs	No raw provider payload exposure.
Provider-owned mandate readiness	Buyers need provider-backed mandates or payment capability where allowed.	Provider capability verification, non-sensitive evidence refs, human approval, rollback, and separate live rail approval.	Provider/fintech + AgenticOrg verifier + Grantex policy	Live provider remains blocked until approvals exist.
Commerce Passport production delivery	Users need real consent challenge delivery.	Verified email/SMS/passkey challenge, revocation freshness, signed evidence, user-facing revocation history.	Grantex	No payment-affecting action without valid passport.
Policy simulator	Merchants need to understand agent permissions.	Simulate policy for product/category/amount/agent/channel before activation.	Grantex	Policy activation requires preview and audit.
OACP/UCP/ACP/schema.org adapters	Large agent platforms need standard surfaces.	Generate adapter previews from canonical OACP artifacts, conformance fixtures, versioned capability profile.	Grantex authority + AgenticOrg consumer	Adapter tests and no unsupported certification claims.
AP2-style evidence	Agent payments need non-repudiation.	Intent/cart/payment evidence mapping, hashes, signatures, key rotation, replay defense.	Grantex	Do not claim AP2 until deterministic verification exists.
AgenticOrg buyer workflow	Buyers need a safe assistant experience.	Grounded discovery, comparison, cart drafting, consent request, checkout state, refusal copy.	AgenticOrg	Agent never invents seller/product/price/inventory/payment state.
AgenticOrg merchant demo workflow	Merchants need to understand launch.	Demo scripts, status labels, capability preview, blocked-path examples, non-approval disclaimers.	AgenticOrg	Demo remains synthetic or sandbox until Grantex approves real data.
Ops and support dashboards	Teams need to fix failed runs.	Failed checkout, webhook replay, stale sync, stuck payment, policy denial, support handoff, incident runbook.	Grantex, AgenticOrg reads where needed	On-call and rollback owners assigned.
Analytics and attribution	Merchants need business value proof.	Agent channel attribution, funnel, conversion, refusal reasons, lost sale due to stale data, revenue by agent.	Grantex source, AgenticOrg contribution	Metrics are derived, not raw secrets.
Documentation coverage	Merchants and reviewers need a shared source of truth.	docs navigation, layman guides, API docs, runbooks, stop conditions, evidence templates, PRD links.	Both repos	Docs updated before implementation slices.
GitHub workflow safety	Docs-only planning should not build/push images.	Path guards for deploy-adjacent jobs, docs-only validation, workflow-change caveat handling.	Both repos	No cloud build/push on docs-only planning merges.
Landing page coverage	Prospects need clear positioning without overclaiming.	Merchant-facing page copy for “connect existing systems, preview agent surface, request approval”; no live/certified claims.	Product/web repos	Copy reviewed before public launch.

7. Fast-Track Plan

Slice	Goal	Merchant-visible result	Scope boundary
A. Seller-agent self-serve onboarding	Merchant creates seller commerce agent and Grantex authority request.	Merchant sees checklist, connector plan, artifact status, and “not live” state.	No public discovery or payments.
B. Catalog connector MVP	Merchant imports products from CSV/manual plus one priority connector through AgenticOrg seller-agent workflow.	Products and variants appear in OACP preview with source/freshness and Grantex validation.	No checkout promises yet.
C. Read-only discovery preview	Merchant sees what agents can read.	Public-safe profile/catalog preview and schema.org draft.	Fail-closed until approved.
D. Inventory freshness	Agent can warn/refuse stale stock.	Merchant sees stale SKUs and freshness score.	No quantity reservation yet.
E. Sandbox cart and consent	Buyer can rehearse cart and consent.	Commerce Passport demo with mock/sandbox provider.	No live provider.
F. Order and fulfillment backbone	Paid flow has operational home.	Order reference, status, cancellation, fulfillment events.	Required before broad checkout.
G. Return/refund request	Support has safe post-purchase path.	Manual return/refund request and audit.	No automatic refund execution.
H. OACP and protocol adapters	Agent platforms see standard surfaces.	OACP artifact previews plus UCP-style profile, ACP-style checkout shapes, schema.org JSON-LD, AP2 evidence draft, A2A/MCP-style bridge metadata.	No certification claim until tests and approval.
I. Controlled real merchant pilot	One merchant, category, geography, provider, and rollback owner.	Minimal approved live surface.	Separate rollout approval only.

8. Implementation Requirements By Surface

Surface	Minimum implementation requirement	Acceptance criteria
Merchant dashboard	Onboarding checklist, category preset, connected systems, readiness score, preview, approvals, rollout state, rollback owner.	A non-engineer merchant can see what is missing and why launch is blocked.
Merchant API	Tenant-safe create/read/update for profile, catalog, inventory, policy, connector source, webhook source, and readiness status.	Every UI action has an equivalent API or is explicitly documented as operator-only.
Connector framework	Source type, credential reference, sync status, last run, last success, stale state, row-level errors, retry, disable.	A failed sync cannot silently publish stale facts to agents.
Catalog model	Product, variant, media, category, price, tax, warranty, return summary, source system, freshness.	Agent answers are grounded in exact product/variant IDs.
Inventory model	Availability bucket now; future quantity, location, reservation, confidence, TTL.	Unknown or stale inventory produces warning/refusal, not a guarantee.
Cart/checkout model	Cart draft, cart update, fulfillment option, consent request, passport, payment intent, checkout link, cancel/expire.	Checkout cannot progress without consent, policy, idempotency, and audit.
Order model	Order reference, status, line items, payment reference, fulfillment status, cancellation, support link.	Paid checkout has an operational record merchants can act on.
Return/refund model	Request, eligibility, manual approval, provider handoff, status, audit.	Refund execution remains blocked until separate provider approval.
Settlement model	Provider-neutral payout/settlement records, fees, taxes, reconciliation status, export.	Merchant can answer “when do I get paid?” without raw provider payloads.
Protocol adapters	UCP-style profile, MCP tools, ACP-style checkout/order mapping, schema.org feed, AP2 evidence draft.	Generated from canonical objects with conformance fixtures and no unsupported claims.
External buyer channels	Capability-safe channel metadata for ChatGPT, Claude, Gemini, WhatsApp, Telegram, web/mobile, and future agent surfaces.	A channel cannot show checkout/payment capability unless Grantex approves the merchant, tool scope, consent, and policy state for that channel.
Audit and observability	Append-only audit, redacted logs, metrics, runbooks, replay controls, incident severity.	No protected action is acknowledged without durable audit evidence.
Security and privacy	Credential isolation, secret redaction, tenant filtering, role checks, webhook signatures, rate limits.	Cross-tenant and secret-exposure tests fail closed.

9. Release Acceptance Criteria

Before any real merchant pilot, all of these must be true:

The merchant completed self-serve sandbox onboarding and selected a category preset.
Legal/compliance, product wording, security, ops/support, rollback, smoke, and evidence retention owners are recorded as non-secret references.
Existing-system connectors are either connected and healthy or explicitly replaced by approved manual/CSV maintenance.
Catalog, price, tax, warranty, return policy, and inventory freshness checks pass for the selected category.
schema.org output is generated only from approved public-safe fields.
AgenticOrg sees only OACP-authorized capabilities with source/freshness labels and refusal semantics.
Checkout/payment creation remains blocked until Commerce Passport consent, policy, audit, idempotency, provider readiness, and rollback checks pass.
Orders, fulfillment, support, and refund handoff are available for any paid flow in the pilot category.
UCP/ACP/AP2 compatibility language is backed by implementation and tests, or clearly described as planned/future compatibility.
GitHub checks pass or skip by documented policy, and docs-only changes do not trigger cloud auth, image build, image push, deploy, or indexing jobs.

10. Public Landing Page And Blog Plan

Use this as the safe public positioning once product/web owners approve landing page updates. This older PRD section is historical; it did not publish the pages.

Grantex Commerce helps merchants prepare for agentic commerce by connecting approved merchant facts, policies, and source evidence into signed OACP artifacts. AgenticOrg runs the seller and buyer agents. Merchant systems stay the operational source of record. Provider rails own mandates and payments. Agents can use cached artifacts for non-binding discovery and must refresh or refuse when facts are stale, risky, or unsupported.

Grantex landing page planning blocks:

Hero: “Trust layer for agentic commerce”, with a simple four-party workflow.
Section 1: “What Grantex owns” - artifacts, policy, protocol adapters, refusal semantics, source/freshness, revocation, audit evidence.
Section 2: “What Grantex does not own” - seller agents, buyer chat runtime, merchant operational systems, provider mandate/payment execution.
Section 3: “OACP status” - internal C6Z foundation, blocked production vertical, no public standard claim.
Section 4: “Protocol adapters” - schema.org, UCP-style, ACP-style, AP2-style, A2A-style, MCP-style previews generated from artifacts.
Section 5: “Pending before live” - persistent cache, real connectors, provider-owned mandate verification, execution controller, public governance.

Blog series plan:

Blog	Audience	Visual workflow
The Clean Four-Party Architecture For Agentic Commerce	Founders, architects, merchants	Merchant systems -> AgenticOrg seller agent -> Grantex artifacts -> AgenticOrg buyer agents -> provider rails.
Why Grantex Must Not Be A Transaction Toll Booth	Product and engineering	Cached artifact lifecycle with refresh/refuse points and risk tiers.
OACP Artifacts Explained	Developers	Artifact family map from merchant profile to dry-run verification.
How AgenticOrg Seller Agents Connect Shopify, WooCommerce, And ERP	Merchants and integrators	Connector credential-custody choices and source/freshness flow.
Provider-Owned Mandates In Agentic Commerce	Fintech and risk teams	Buyer mandate setup at provider rail, AgenticOrg verification, Grantex evidence refs.
From schema.org To ACP To AP2: Adapter Previews Without Overclaiming	Standards and developers	OACP artifact -> adapter preview fan-out.
What Still Blocks Autonomous Commerce	Leadership and operators	Gap map from C6Z blocked production vertical to live pilot.

Avoid claims that imply:

live payment capability already exists;
UCP, ACP, or AP2 certification already exists;
public discovery is already active;
automatic refunds are available;
human or source review is unnecessary;
every merchant system is already supported.

Detailed page and blog plan lives in docs/internal/commerce-v1/commerce-v1-oacp-landing-blog-plan.md.

11. Documentation And Workflow Coverage

The implementation should update these surfaces as slices land:

Surface	Required update
`GRANTEX_COMMERCE_PRD.md`	Keep target-state requirements and gap register current.
`GRANTEX_COMMERCE_V1_BUILD_SPEC.md`	Add only committed V1 contracts, not aspirational roadmap claims.
`docs/docs.json`	Keep merchant/developer/operator docs discoverable under Agentic Commerce V1.
Commerce overview guide	Link to this PRD and show current posture, allowed paths, and blocked paths.
End-to-end flow guide	Keep seller one-time setup, buyer one-time setup, regular transaction, exception paths, and source-of-truth rules current.
Developer guide	Document API and connector contracts after implementation exists.
Merchant/operator guide	Explain self-serve, approvals, category presets, and existing-system connectors.
Operations guide	Document rollback, incident, webhook replay, stale sync, and support handoff.
OpenAPI	Add endpoint contracts only when runtime endpoints exist or are approved for implementation.
GitHub workflows	Keep docs-only changes away from cloud auth/build/push/deploy jobs.
Landing pages	Use public-safe copy: “connect existing systems and preview agent-ready commerce.” Avoid live, certified, or approved claims.

12. Stop Conditions

Stop implementation or rollout if any of these occur:

A real merchant identity is missing or unapproved.
Private contracts, contacts, pricing terms, customer data, credentials, raw payloads, tokens, JWTs, DB/Redis URLs, private keys, or provider secrets enter Git or public docs.
AgenticOrg gains a direct provider, Plural, Stripe, merchant private API, or payment credential path for payment execution or unapproved merchant execution. Approved provider capability verification and approved connector sync must stay separate from execution.
Checkout can happen without user consent, Commerce Passport verification, policy approval, idempotency, and audit.
Catalog, price, tax, inventory, delivery, warranty, or return data is stale or unverifiable but presented as guaranteed.
Paid checkout is enabled before order, fulfillment, support, and refund handoff paths exist for the selected pilot category.
Production flags, allowlists, public discovery, live provider paths, or live Plural are changed without a separate approved rollout.
UCP, ACP, AP2, schema.org, A2A, MPP, or provider certification is claimed before implementation and conformance evidence exists.

​Agentic Commerce Implementation PRD

​Current OACP Runtime Closure Boundary

​1. Architecture In Plain English

​End-To-End Operating Flow

​2. Current Implementation Snapshot

​2.1 Current OACP Status Through C6Z

​3. Target Merchant Journey

​4. Existing Merchant Systems

​5. Standards And Protocol Fit

​6. Comprehensive Gap Register

​7. Fast-Track Plan

​8. Implementation Requirements By Surface

​9. Release Acceptance Criteria

​10. Public Landing Page And Blog Plan

​11. Documentation And Workflow Coverage

​12. Stop Conditions