Three pieces, cleanly separated.

There are no duplicate customer records to reconcile. EEI identity mints eei_user_id and stays the system of record; SSO carries that ID into Sharetribe as the OIDC subject, Stripe stores it in account metadata, and the wallet ledger and gallery key on it natively. Sharetribe's user record is a projection of ours, not a second customer — full entity map with every key on the Data Map briefing.

Every listing is machine-inspected before a human ever sees it. Photos run through the vision API — does the wheel in the photo match the catalog part claimed, does visible rash contradict the condition report, what's the DOT date stamped on that sidewall, are there counterfeit tells. Listing text and messages run through text moderation for scam patterns and off-platform-deal attempts (surfaced via Integration API events).

The pipeline: new listing → vision + text checks → auto-pass clean matches, auto-reject rule-breakers, route ambiguity to the moderation queue in the ops console. Humans judge only what machines can't — that's what holds the ~10-minute spec-check promise and the lean ratios on the Team & Ops Plan. Sellers get the assist too: one-click listing descriptions generated from the VCDB match, condition grade, and photos — Gemini Flash-Lite (Google's cheapest model), server-proxied with rate caps (10 per page load, 100/day per IP) so the button can't become a bill. Per-image costs on the Costs brief (~1–3¢).

We deliberately don't sell used tires — tires age out, wheels don't. That gap is a brand integration, not a missing feature: new tires sell right on the Exchange — the first-party Tires category, stocked and shipped by Only Tires, sized to the wheels being bought — and Treadsy books local installation at a shop near the buyer, the same Treadsy integration already running on onlytires.com.

The flywheel gets a third spoke: used wheels sell on the Exchange → new tires sell at Only Tires → install books through Treadsy → and the seller's store credit comes back through EEI retail. Promo bands are already designed into the PDP, the upsell step, and the order confirmation.

The honest constraint: the marketplace engine is single-provider per transaction — there is no native multi-vendor cart, and no amount of front-end cloning changes that (the pages were never the problem; the checkout flow is). The unlock is that Only Tires is family: tires ride the used-wheel order as custom line items on ONE charge to the buyer. Buyer experience: one checkout, one payment, two clearly-labeled shipments (tires from the OT warehouse, wheels from the seller — which is physically true no matter what).

What's platform-native vs. ours: custom line items with includeFor semantics (charge the buyer / credit the provider) are stock Sharetribe — it's how their own commissions and shipping fees are modeled — so the seller's payout automatically excludes the tire lines and that portion accrues to the operator (us) in our Stripe balance. Transaction events over the Integration API: also native. Ours is one thin webhook step (the same service already scoped for credit payouts and labels): on the order event it posts the tire order to OT's platform — or directly into NetSuite as a sales order — and books the internal settlement (wallet-ledger entry + NetSuite journal). Because the split is EEI-to-EEI money already sitting in EEI's account, settlement is accounting, not payments engineering.

Phasing: Launch = the first-party Tires category (designed in the demo — Only Tires catalog, sold-by badging, retail terms) with per-listing checkout. Fast follow = tires as line items on used orders with internal settlement, reusing the FI add-on split already scoped above. Fallback if line-item settlement stalls: OT as a first-party seller account — checkout chains two transactions behind one review screen (card entered once). Only works this cleanly because both sides of the split are EEI companies.

Why not the reverse — clone the OT site and build the Exchange on the retail cart? Because the platform must follow the risky money. Host checkout on the retail cart and EEI becomes merchant of record for peer-to-peer sales — rebuilding escrow, seller KYC/1099-K, offers, facilitator tax, and used-goods chargebacks in-house on the legacy cart: the exact build this project avoids. The marketplace platform owns the money; the retail platform owns the shelf. One checkout, two warehouses.

Transaction reviews are native to the marketplace — Sharetribe's built-in engine: double-blind (neither side sees the other's review until both post or the window closes), tied to verified completed orders only, and surfaced hard in the product — seller ratings on every listing card, review quotes on the PDP, full breakdowns on seller profiles. Trust is earned deal by deal and can't be imported or bought.

Birdeye handles the property level — the same reputation platform EEI already runs everywhere: the Exchange gets its own Birdeye profile, post-transaction review requests follow the family playbook, and the aggregate rating shows on-site (see the About page). Seller reputation stays native and un-gameable; site reputation compounds with the rest of the family.