Skip to content

tenantcommerce-control.boundary-model.md

Latest commit

 

History

History
74 lines (53 loc) · 3.04 KB

tenantcommerce-control.boundary-model.md

File metadata and controls

74 lines (53 loc) · 3.04 KB
Raw

Tenant Commerce Boundary Model

Purpose

This profile-testbed example describes the agentic boundaries for TenantCommerce Control.

It is not a repo-local production claim. The repository remains independent: it is not an AAIF project, not a Linux Foundation project, and not endorsed by either organization.

High-Risk Action Boundary

Tenant-scoped catalog edits, pricing changes, inventory changes, storefront publication, order operations, customer data access, and cross-tenant administrative actions.

Actors

Actor Responsibility
Tenant operator Owns catalog, storefront, and order decisions for one tenant.
Platform admin Manages shared policy, billing, and platform-level controls.
Commerce agent Proposes catalog, support, pricing, and order workflow changes.
Commerce adapter Connects to storefront, payment, inventory, and fulfillment systems.
Maintainer Reviews tenancy, policy, and audit evidence.

Identity Boundary

  • Every action must carry tenant id and human operator context.
  • Agents cannot cross tenant boundaries without platform-admin approval.
  • Payment and customer data scopes must be separated from catalog-edit scopes.
  • Provider credentials remain environment-owned and tenant-scoped where possible.

Tool And Action Boundary

Action Boundary
read_catalog Allowed inside one tenant scope.
propose_catalog_change Draft only until approved by tenant operator.
publish_storefront Requires human approval and preview evidence.
change_price Requires policy check, approval, and audit event.
manage_order Requires customer-impact classification and approval gate.

Human Approval Gates

  • Before publishing storefront changes.
  • Before price, discount, tax, shipping, or refund changes.
  • Before accessing customer PII beyond operational need.
  • Before cross-tenant analytics or administrative actions.

Audit Event Model

Event Minimum Evidence
tenant.context_loaded tenant id, operator id, scope, timestamp
catalog.change_proposed sku, change type, reason, risk class
storefront.publish_approved approver, preview id, diff pointer
order.action_requested order id, action type, customer impact
cross_tenant.access_denied requester, attempted tenant, policy reason

Local Proof Path

  • npm install to prove dependency resolution.
  • npm run lint to prove static project health.
  • npm run test for tenant and policy checks when available.
  • npm run build to prove the application compiles.
  • Use sample tenants, products, and orders in public proof.

OSS And Self-Hosted Fallbacks

  • Use PostgreSQL tenant tables before hosted-only commerce data stores.
  • Keep payment processors behind adapters and use sandbox keys only.
  • Use local queues for catalog publication and inventory sync tests.
  • Keep storefront rendering portable across self-hosted and hosted deployments.

Contributor Follow-Up

Add a repo-local docs/AGENTIC_BOUNDARY_MODEL.md after review and link it from agentic-readiness.json.