Command surface
43 command packages. One governed write path.
Every domain your operations team touches — inventory, orders, fulfillment, customer service, sourcing, channels, connectors, payments, analytics, and platform — runs through the same command boundary. One receipt shape. One approval model. One audit trail.
Ten domains
The operational domains in the command surface.
Each domain is one or more command packages. Every package in every domain uses the same CommandMetadataInput envelope, writes to command_receipts, and emits at least one domain event.
Inventory truth
8 pkgsOn-hand, reserved, incoming, allocated — one answer your team can defend
- Inventory adjustment
- Stock reconciliation
- Snapshot import
- Cycle count
- Oversell policy
- Future inventory
- Safety stock
- Stock transfer
Orders and reservations
2 pkgsHold inventory against real orders, not promises
- Reservation create/cancel
- Order lifecycle
- Allocation preview
- Fulfillment handoff
Fulfillment orchestration
1 pkgGoverned handoff at every step from order to shipment
- Fulfillment order
- Shipment
- Return
- Exception routing
Customer service
1 pkgDelivery questions, cancellations, refunds, with context, not guesswork
- Order hold
- Cancellation
- Refund initiation
- Delivery-status resolution
- Agent-assisted support
Sourcing and allocation
3 pkgsSimulate and commit before allocation runs
- Allocation strategy
- Substitute sourcing
- Dropship routing
- Account allocation
- Simulation preview
Channels and commerce
3 pkgsChannel availability with freshness guarantees
- Channel publication
- Marketplace feeds
- Commerce market config
- Freshness enforcement
Connectors and ingestion
4 pkgsGoverned intake from any source with source authority
- Connector lifecycle
- Source ingestion
- File drop pipeline
- Ingestion authority
- Replay and retry
Payments
2 pkgsPayment facts beside the operational actions they affect
- Payment capture
- Refund initiation
- Provider event receipt
- Billing export
Analytics and signals
4 pkgsReceipts and events as the base for every downstream system
- Event rollups
- Metric snapshots
- Alert rules
- Incident signals
- Analytics export
Platform fabric
15 pkgsApprovals, automation, identity, webhooks, and agent surfaces
- Approval gates
- Scheduled jobs
- Webhook delivery
- Agent actions
- Identity and roles
- Tenant management
- Onboarding
- Feature flags
- Progressive actions
- Workflow automation
The write boundary
Four facts that apply to all 43 packages.
The write boundary is not per-domain. These four properties apply uniformly. A command from the inventory domain and a command from the agent domain share the same receipt shape, the same idempotency model, and the same audit path.
Idempotent by design Every command carries an idempotency key. Re-sending the same command is safe — the receipt deduplicates on (tenant_id, command_type, idempotency_key).
CommandMetadataInput envelope Every command carries idempotencyKey, correlationId, causationId, actorType, and policyContext. The same envelope shape applies to all 43 packages.
Version-aware State-changing commands carry an expectedVersion. Optimistic concurrency is enforced server-side; stale writes are rejected, not silently overwritten.
Receipt on every execution command_receipts rows are append-only. Actor, scope, payload hash, policy decision, and version applied stay queryable for the life of the tenant.
Build against it
The GraphQL API is the contract.
Every command domain exposes its writes through GraphQL mutations and its reads through GraphQL queries. The MCP catalog exposes the same commands as typed tools for agent clients.