Define the business loop before deciding what AI should automate
Abstract
Cross-border teams do not need another chat box that can rewrite a Listing. They need an operating system that preserves SKU truth, understands channel differences, connects sales to contribution economics, pauses before high-risk actions, and reads platform state back after execution. A page being built is not the same as a product being sellable; a submitted request is not a confirmed platform change; an expected lift is not a verified outcome.
1. Three business journeys, one shared control tower
A merchant does not buy eighteen Skills. A merchant starts from a concrete situation and needs a verifiable operating outcome. Skills are bounded execution units; the control tower connects them into a business loop.
JOURNEY 01 · SUPPLY TO BRAND
Supply chain to a transaction-ready brand
Start: factory, inventory or a product idea without cross-border operating expertise.
Accepted outcome: 1–3 exact SKUs pass truth, sample, unit-economics, packaging, channel, payment and fulfilment checks, with at least one real transaction path verified.
JOURNEY 02 · AMAZON DAILY OPS
Amazon daily operating diagnosis
Start: operators inspect sales, ads, keywords, Listing, inventory and profit in separate tools.
Accepted outcome: a five-minute daily verdict, object-level cause candidates, no more than five actions and post-execution verification.
JOURNEY 03 · ZERO TO FIRST ORDER
Zero-product sourcing to first-order fulfilment
Start: no product, with an intent to use CJ, DSers or AliExpress dropshipping.
Accepted outcome: evidence for the exact variant, three-destination shipping, sample, Product Truth, Shopify draft, non-zero payment, supplier acceptance, tracking and delivery.
SHARED MODULE · OPERATING CONTROL TOWER
Cross-channel operating control tower
Role: govern data coverage, operating facts, anomalies, diagnoses, action candidates, approvals, execution read-back, verified outcomes, enterprise seats and credits. It is neither a fourth customer type nor a universal dashboard.
Product decision: build Amazon daily diagnosis as the first usable slice because its data objects, diagnostic rules and action boundaries are clearest. Use it to establish the tower’s shared evidence, approval and read-back spine, then add brand launch and dropshipping journeys.
2. Every module must speak the same business language
Cross-border automation often fails because tools disagree about the meaning of product, launch, execution and success. The following shared chain constrains every module.
- 01 · PRODUCT TRUTHProduct Truth Card
- 02 · OFFERSellable offer
- 03 · ECONOMICSUnit economics
- 04 · SIGNALOperating signal
- 05 · DIAGNOSISOperating diagnosis
- 06 · ACTIONAction candidate
- 07 · READBACKExecution read-back
- 08 · MEMORYOperating memory
PRODUCT TRUTH CARDLock the exact SKU before generation
Records source, visual facts, functional boundaries, allowed and unsupported claims, unknowns and asset rights. Social references cannot overwrite it.
SELLABLE OFFERSelection evaluates a sellable combination, not an image
A product becomes a different offer when variant, warehouse, destination, shipping route, channel or price changes.
ACTION CANDIDATEA recommendation must become an approvable object
Every action names its object, before and proposed values, evidence, owner, risk, expiry, review window and rollback condition.
VERIFICATION RESULTExpected results are not achieved results
Only data read back under a predefined measurement contract can support keep, iterate, rollback or insufficient-data decisions.
Two status axes must remain separate
| Status axis | States | Question answered |
|---|---|---|
| Commerce readiness | PLANNED → DRAFTED → STAGED → PUBLISHED → TRANSACTION_VERIFIED → FULFILLMENT_VERIFIED | Can the product be seen, purchased, paid and fulfilled? |
| Operating action | DESIGN → DIAGNOSED → DRAFT ACTION → APPROVED → READ-BACK → VERIFIED OUTCOME | Has an operating decision been executed and verified? |
Hard boundary: a Shopify draft is not a sellable storefront; a connected payment app is not proof of capture; an API success response is not platform-state confirmation; traffic and carts are not completed orders; a paid order is not supplier acceptance and customer delivery.
3. Module one: supply-chain resources to a transaction-ready brand
This module serves teams that have supply but lack cross-border brand operations. A polished website is not the finish line. The accepted output is a minimum brand test unit that passes truth, compliance, economics, channel, payment and fulfilment checks.
- 01 · Launch constraintsConfirm entity, brand, target market, budget, account ownership and supply base; produce a Launch Charter and access-gap list.
- 02 · Supply factsTurn exact product links, specifications, material, MOQ, quote, lead time, packaging, certificates and warehouse data into a Supplier Dossier and Product Truth Card; unknowns remain unknown.
- 03 · Selection and economicsScore sellable offers using demand, competition, VOC, platform fees, shipping, returns and CAC ceiling. Compliance, fulfilment or negative-economics hard failures cannot be offset by a high score.
- 04 · Brand, packaging and claimsCreate a Brand Profile, visual rules, Claims Matrix, label checklist and print approval. AI does not replace regulatory confirmation or physical sampling.
- 05 · Channel launch packsGenerate channel-specific Listing drafts, variants, pricing, image briefs, video scripts, inventory mapping and policy checks for Amazon, Shopify and TikTok Shop.
- 06 · Multimodal marketing packRoute Product-Truth-grounded assets into Instagram, short video, blog, LinkedIn, X, Facebook, creator packs and GEO content.
- 07 · Transaction and fulfilment gatesIndependently verify domain, inventory, shipping, payment, tax, checkout, supplier payment, order sync, tracking, returns and notifications.
- 08 · Controlled launch and 30-day operationLaunch 1–3 SKUs first, verify a real non-zero order and fulfilment, then enter paid media, creator and scaling loops.
AI CAN PREPARECan be automated
Permitted reading, evidence normalization, deduplication, scoring, economic scenarios, Listing/content drafts, Shopify drafts, page checks, diffs and approval queues.
HUMAN MUST AUTHORIZEHuman authorization required
Final SKU, supplier, trademark, sample, claims, packaging print, publication, price/inventory, domain, payment, procurement, ad budget, creator outreach and outcome claims.
4. Module two: Amazon daily operating diagnosis
The first product slice is not a KPI wall. It is an operating decision layer that first establishes whether data supports a conclusion, then explains the sales and profit movement, and finally creates a small reviewable action queue.
Minimum data contract
| Data surface | Minimum grain | Boundary |
|---|---|---|
| Business Reports | marketplace × child ASIN × day | Unit Session % cannot be replaced by ad CVR. |
| Amazon Ads | campaign × ad group × target/search term × day | Separate SP, SB, SD and attribution windows. |
| Keywords and rank | ASIN × query × day | Third-party rank is observed evidence, not account truth. |
| Profit and inventory | SKU/FNSKU × day | Without costs, discuss revenue efficiency; parent rollups must not hide child stockouts. |
| Offer / Listing | child ASIN × snapshot time | Preserve price, coupon, Buy Box and Listing-version timestamps. |
The three core screens form one operating loop
SCREEN 01 · DAILY VERDICTDaily operating overview
Lead with an actionable verdict, then expand into the sales-to-profit bridge, risk contribution and prior-action verification.
- Show latest available date, missing sources, attribution maturity and quality grade.
- Every issue resolves to an ASIN, campaign, target or search term.
- No more than five actions today.
SCREEN 02 · CAUSAL WORKBENCHAmazon issue detail
Place signals, cause candidates, evidence for and against, excluded factors and missing evidence in one workstation.
- Show a causal route without turning coincidence into proven causality.
- Keep confidence separate from evidence completeness.
- Preserve explicit questions requiring human judgement.
SCREEN 03 · APPROVAL & READBACKAction approval center
Approvers see before/after diffs, permission scope, budget impact, rollback conditions and platform read-back—not a vague optimization suggestion.
- Read, execute and approve are separate permissions.
- Save a pre-execution snapshot and stage writes.
- Business validation starts only after successful read-back.
Cross-metric diagnosis must test counter-evidence
| Observed pattern | First hypothesis | Must check | Safe action |
|---|---|---|---|
| Sessions ↓ / Unit Session % stable | Traffic issue | Rank, ad exposure, budget, Buy Box, stock | Locate lost-traffic objects; do not rewrite Listing |
| Sessions stable / CVR ↓ | Offer, page or traffic mix | Price, coupon, rating, Listing version, broad mix | Prepare a field-level diff draft |
| Spend ↑ / Orders flat | CPC, relevance or handoff | Placement, target, search term, ad CVR | Object-level bid/negative draft, not account-wide pause |
| Sales ↑ / Contribution profit ↓ | Growth consumed by cost | Ads, discounts, fees, refunds, COGS completeness | Show profit bridge and stop blind scaling |
V1 automation boundary: automate import, normalization, recalculation, anomaly detection, diagnostic drafts, notifications and candidate files. Do not automatically change bids, budgets, negatives, campaign state, Listing, price, coupon or inventory.
5. Module three: zero-product sourcing to first-order fulfilment
This module is not one-click store creation. It is an evidence-driven launch state machine. AI can move forward only after the preceding hard gate passes.
EVIDENCE_MISSING→READY_FOR_SAMPLE→READY_FOR_DRAFT→READY_FOR_REAL_ORDER→FIRST_ORDER_DELIVERED→SCALE_ELIGIBLE
- 01 · Opportunity discoveryAggregate search, social, competitor sites, ad libraries and review pains into an Opportunity Card. Social attention shows demand direction, not sales.
- 02 · Exact-variant sourcingStore CJ/AE product ID, variant, supplier, source image, cost, weight, warehouse and destination. A title or similar image is insufficient.
- 03 · Hard reject and scoreStop immediately for undeliverable, unverifiable costs, IP/compliance risk, unsupported-claim dependency or negative base economics; then score demand, fulfilment, profit, content and differentiation.
- 04 · Three-destination shipping and economicsCheck shipping price, processing time, transit time, refund/reship reserve and CAC ceiling for three destination ZIPs and the exact variant.
- 05 · Sample and Product TruthVerify components, material, colour, packaging, safety, use and claim boundaries. AI lifestyle images do not replace a physical sample.
- 06 · Store and content draftsPrepare Shopify draft, PDP, policies, FAQ, Blog/GEO, Instagram, TikTok, YouTube, LinkedIn, X, Facebook and email assets; keep the state Draft.
- 07 · Independent connector gatesVerify CJ, DSers, AliExpress API, Shopify, PayPal, domain and logistics independently. App install or import is not proof of authorization, stock, payment, procurement or tracking.
- 08 · Single-SKU controlled launchOpen one real product and checkout, then verify non-zero payment, supplier payment and acceptance, tracking, notification, delivery and refund path before scaling.
Content timing: research social creative structure during discovery; create blog, GEO and page drafts after Product Truth; produce proof content after sample validation; enable purchase intent after domain, payment, shipping and policy gates; begin small paid tests only after first-order delivery and cost read-back.
6. Module four: cross-channel operating control tower
The tower does not force Amazon, Shopify and TikTok Shop into one store model. It only unifies evidence, operating decisions and action governance while preserving channel-specific metric contracts.
01 · DATA COVERAGEData coverage and confidence
Record source, object, time, timezone, currency, attribution, maturity, missing fields and access failures. Failed access is a coverage issue, not no change.
02 · DAILY VERDICTFive-minute operating brief
Lead with the global verdict, then drill into store, channel, SKU, campaign and issue contribution; retain no more than five actionable items.
03 · ACTION GOVERNANCEApproval, execution and rollback
Separate read, draft, execute and approve. Price, inventory, publication, budget, campaign state, outreach, refund and procurement require explicit authority.
04 · OPERATING MEMORYAccount-level operating memory
Persist evidence, diagnosis, action, approval, read-back and outcome so the system learns what worked under which account conditions, rather than storing chat history.
Enterprise safety is not an add-on
- Admin-owned connectionsEnterprise admins create and revoke store, ad, social, ERP and managed-browser connections. Seats receive scoped grants, not reusable credentials.
- ZiNiao is an access containerZiNiao or another fingerprint browser cannot become the authorization system. Do not export cookies, reuse profiles across tenants or infer authority from an existing login.
- Feishu and DingTalk are operations surfacesThey carry queues, approvals, owners, creator rosters and result read-back; a bot or CLI is not external-platform business authorization.
- Credits are governed separatelyAllocate enterprise credits by seat, store or project; reserve before paid work and settle once. No negative balance, silent retry or automatic top-up. Credits are not ad budgets.
7. A Skill is called only at the node that needs it
The map below shows how existing capabilities enter the product without turning Skill names into a customer-facing menu. Each Skill keeps its own input contract, output contract and stop conditions.
Takes Business Reports, Ads, rank, Listing changes, inventory, price and cost; returns data quality, verdict, cross-module diagnosis, Top 5 actions and a verification plan.
JOURNEY 02 + TOWERRoutes collection, Review/VOC, keyword library, Listing draft, ad initialization and single-report analysis when diagnosis requires them.
JOURNEY 01 / 02Turns Product Truth and DTC Desire Angle into source records, creative and look packs, a five-panel storyboard and script; no final-content claim without evidence and visual QA.
JOURNEY 01 / 03Handles SKU anchors, continuity, model routing, scripts, keyframes and delivery checks for brand films; not batch scheduling or platform publishing.
JOURNEY 01 / 03Normalizes public or authorized samples into trend signals, content angles and hypotheses. Attention metrics do not prove sales or profit.
JOURNEY 01 / 03 + TOWERConnects owned-store health, competitors, reviews, public ads, selection, creator queues, seats, managed-browser risk and credits. It is a design specification, not account control.
JOURNEY 01 / 03 + TOWERHandles creator fit, scoring, personalized multimodal packs, dedupe, frequency and approval queues; no blind sends, identity cloning or fabricated partnership.
JOURNEY 01 / 03 + TOWERConnects validated ChatGPT sessions and orders to Product Truth, crawl/feed, answer-ready pages, experiments and conversion quality; no citation, ranking or recommendation guarantee.
JOURNEY 01 / 03 + TOWERRouting principle: the tower determines the problem, evidence sufficiency and specialist capability required. The Skill performs the bounded task, then returns results to the evidence ledger and approval queue.
8. Delivery sequence: trusted decisions before execution
| Phase | Deliverable | Acceptance | Not included |
|---|---|---|---|
| 0 · Domain and data contracts | Canonical entities, metrics, states, evidence grades and action contracts. | Same data recalculates consistently; NA stays NA. | No production account writes. |
| 1 · Amazon MVP | Fixed CSV/XLSX import, baselines, 10–15 rules, three core screens, daily actions and seven-day verification. | Manager understands top risk in three minutes; every conclusion is traceable. | No automatic ad pause, Listing or price change. |
| 2 · Approval and read-back | Field-level diffs, expiring approval, least-privilege execution, idempotency, read-back and rollback. | Approved change matches platform state object by object. | Do not treat API success as business outcome. |
| 3 · Brand and dropshipping journeys | Product Truth, offer, economics, sample, channel, payment and fulfilment state machines. | At least one SKU passes real non-zero transaction and fulfilment read-back. | Do not treat a draft catalogue as a sellable store. |
| 4 · Enterprise control plane | Tenant, seat, store grants, audit ledger, credits, offboarding and cross-channel brief. | Out-of-scope access is denied; every material action resolves to actor and object. | No credential sharing or cross-tenant browser-profile reuse. |
Product success measures
TIME TO DECISIONTime to understand
Can a manager find the top risk in three minutes and an operator reach the right object in five?
TRACEABILITYConclusion traceability
Does every conclusion have source, object, time, metric contract, counter-evidence and gaps?
READBACK MATCHExecution read-back match
Do approved fields, objects and scope match actual platform state?
VERIFICATION COMPLETIONAction verification completion
Does each action reach keep, iterate, rollback or insufficient-data status after attribution matures?
9. What is evidenced and what still needs to be built
RUNNABLE / VERIFIED PARTSExisting capability
Amazon specialist Skills, Product Truth, Review/VOC, keyword work, Listing and ad drafts, report analysis, SKU storyboard/brand film, local web/video validation, plus DTC, GEO and creator methods.
DESIGN SPECIFICATIONSDesigned but not unified in production
Amazon daily diagnosis, DTC daily router, automated selection, cross-channel tower, seats, credits, managed-browser boundary, Feishu/DingTalk queues and dropshipping state machine.
MISSING PRODUCTION LAYERLargest current gaps
Official/ERP adapters, canonical entity map, daily snapshots, profit-driver decomposition, action ledger, production write adapters, read-after-write, seat enforcement and complete audit coverage.
CLAIMS NOT MADEClaims this page does not make
No claim of unattended brand launch, automatic publication, real ad incrementality, fully automated visual fidelity QA, GEO-caused ChatGPT orders or completed enterprise account control.
Related public implementations and methods
Next implementation scope: use Amazon offline reports to build the first operable loop—daily overview, issue detail, action approval, execution read-back and verified outcome. Expand production APIs and the other two journeys only after this loop is used and produces traceable outcomes.
Turn Skills into a verifiable operating system
Implementation starts with Amazon daily diagnosis and the shared tower: unify data and states first, then diagnosis, approval and read-back—not autonomous writes.