Concept Narrative

Status (2026-05-13): Late discovery / transitioning to v0 build planning. Several early hypotheses have been confirmed (see below). The product's load-bearing design thesis — the layered canonical + transformation model — has stabilised enough to anchor a v0 build. Items marked Hypothesis are still unvalidated; Out of scope items are deliberate exclusions for v0.

The problem

AU music retailers receive product data from many suppliers in inconsistent forms: spreadsheets with different column names, PDFs, marketing emails, portal exports, attached price lists. To list a product on their ecom site, in their POS, or in their ERP, each retailer cleans, normalizes, categorizes, and enriches that data independently. Across the industry, the same products from the same suppliers are processed N times, by N retailers, in N slightly different ways.

This is repeated structural cost that grows with catalog size and supplier count. It eats staff time, agency fees, and accuracy. It slows down new-product onboarding and new-supplier integration. No single retailer or supplier can fix it alone.

Who it's for

Primary: AU music retailers

Retailers carrying products from multiple suppliers, where catalog operations are a known cost and a known source of friction. Most acutely:

Retailers currently using APIC / MusiPOS (the legacy centralised attempt — incumbent target).
Smaller retailers without an internal data team or custom tooling.
Retailers with growing catalogs and limited ops headcount.
Retailers whose ecom and POS catalogs have drifted out of sync.

Secondary: AU music suppliers and distributors

Suppliers maintain product data in their own formats and have to support many retailers' differing requirements. Some have built dealer portals; some have not. Each retailer asks for slightly different fields, schemas, or update cadences. Suppliers either tolerate the overhead or under-serve some retailers.

The design thesis — layered canonical + transformation model

The product is two distinct layers working together:

Shared canonical layer. Standardised categories, standardised facets/specs (Sweetwater-grade — see below), clean primary fields. Identical for every consumer. This is the work the platform does once on behalf of everyone, and it is the moat: APIC doesn't have it, MusiPOS doesn't have it, no AU retailer has solved it for themselves.
Per-retailer transformation layer. Configurable mappings that produce retailer-shaped outputs (Cin7-shape, Shopify-shape, MusiPOS-shape, custom CSV, etc.) and accommodate retailer-specific choices (variant grouping policy, field naming, display value forms, etc.). The retailer's freedom layer.

Retailers consume the canonical layer with as much or as little transformation as they want. They can adopt the platform's taxonomy directly, map it onto their own, or pass it through. They can take the variant-grouped view, the SKU-per-colour view, or both. The platform does the work; the retailer chooses the shape.

Sweetwater as design reference

Sweetwater (US best-in-class music retailer) is the design north star — particularly their ~300+ facet system with standardised values per category. Their categories and facets are publicly observable and have been scraped as a reference (research input).

This anchors a concrete target: facet coverage, value normalisation, and category depth that approximate Sweetwater's quality, scoped to the AU supplier set.

What it does, conceptually

Ingests product data from suppliers in whatever form they currently send it (files, dealer portals, eventually direct push).
Normalizes into the shared canonical record: standard fields, standardised facet values, deduplicated identifiers.
Maps into the shared taxonomy and clean category structure.
Exposes the canonical record back to consumers via APIs, file exports, and retailer-configurable transformations.

What value it unlocks

For retailers

Hours back per week from manual data wrangling.
Faster supplier onboarding (opt in, not redo).
Faster product onboarding (often already in the canonical layer).
Higher data accuracy, fewer cross-channel inconsistencies.
Foundation for the ecommerce experience competitors can't reach: faceted filtering, consistent spec display, clean category browsing.
Choice in how data lands in their stack — transformations are configurable, not opinionated.

For suppliers

Send data once in their own format; reach many retailers.
Reduced cost of supporting individual retailer integrations.
Consistent representation of their products across the AU market.
Visibility into how their data flows downstream.

For the broader industry

A reduction in duplicated effort across the segment.
Lower barrier to entry for new retailers who don't want to build catalog ops from scratch.
An eventual integration substrate for tools that sit above catalog data.

Where GMI fits

GMI's role is co-designer, sanity-checker, and likely reference customer — not "the wedge target." Greg Sher (co-founder) is also product co-lead on this build, contributing industry expertise and the eventual sales motion.

GMI is useful as a design surface because:

Supplier-side surface. Receives raw product/import data from overseas boutique builders — shows what supplier-shaped data looks like at the small-supplier end.
Retailer-side surface. Runs a D2C catalogue on Shopify (not Cin7) — shows what a small, niche-catalogue retailer needs.
Both sides at once. One relationship, two test surfaces. GMI's own catalogue flows through the same canonical layer as anyone else's.

What GMI cannot validate alone: the typical AU distributor-mediated retailer profile (Cin7 + Shopify + POS, full priority distributor mix). That validation happens via other retailer profiles the v0 design accommodates and via post-v0 evidence gathering.

Hypotheses

Confirmed via industry knowledge / behavioural signal

H1. Retailer pain is severe, frequent, and fundable. Confirmed via Tyler's domain expertise plus the observable fact that retailers fund custom solutions for this rather than living with the status quo.
H2. Cross-retailer overlap in supplier base. Confirmed: in Australia, every brand has a single exclusive distributor. Any two retailers stocking the same brand get it from the same source. This makes a shared normalised layer not just feasible but the structurally correct shape.
Generalisability beyond music instruments. Confirmed broadly — adjacent retail behaves similarly enough that the design isn't instrument-specific.

Still hypotheses

H3. Suppliers will participate in a centralised platform (not just send data to individual retailers). The individual-retailer case is positive; the centralised-platform case is the open question. APIC supplier meeting (week of 2026-05-12) is the next signal.
H4. Retailers will pay for canonical-layer access. Pricing model deferred until v0 demonstrates value.
H5. A retailer-configurable transformation layer can absorb retailer divergence cleanly without bleeding back into the canonical layer. This is the design hypothesis the v0 build proves or breaks.

What is deliberately out of scope (for v0)

Multi-tenancy. Single-tenant first.
Auth beyond admin-only. No retailer self-serve, no supplier portal.
Billing, pricing model, commercial terms.
Comprehensive distributor coverage. 2–3 deliberately-varied distributors at v0; broader coverage is a later workstream.
Support tooling, ops monitoring, polish.
Public-facing surfaces.

These are excluded by intent, not by oversight.

What we are not trying to be

Not a marketplace.
Not a retailer.
Not a replacement for POS / ERP / ecom platforms.
Not a vertical PIM tool sold to individual retailers (it is shared infrastructure).
Not a wholesale platform.

Building Sweetwater-grade facet coverage is content/curation work, not software. The Sweetwater reference shortens the design phase but AU-specific curation still has to happen. This workstream runs in parallel with software and is likely the bottleneck on perceived data quality. v0 software can land with thin facet coverage; richer v0 outputs require curation done first.

Suggested next step

The v0 scope memo (../v0/scope.md) is the next artifact. It locks down the layered-model thesis as the build target, names the deliberately-varied distributor set, identifies the consumer profiles v0 will design against, and lists what's explicitly out of scope.