Fictional Retailer Profile — Capital Music & Sound

A design forcing function for v0. Treat as if onboarding a real customer: every v0 scope question should have a forcing answer here. This is the second of the v0 retailer profiles, paired with joe-bloggs-music-profile.md (JBM).

Status

Authored: 2026-05-17. Stage: v0 scoping. Provisional. Catalogue shape and identity fields filled from an AU single-location music retailer reference — taxonomy adopted as CMS's own, brand mix and category weighting used as a realism check. Name is a placeholder.

Gaps from JBM that this profile is built to fill

JBM exercises the broad-mainstream Shopify-native pattern. CMS deliberately picks the opposite point on every load-bearing axis so the v0 layered model has to prove itself on real diversity rather than two near-identical profiles.

Canonical data lives in Cin7, not Shopify. JBM's canonical data lives in Shopify; v0 outputs a single Shopify-shaped CSV. CMS's canonical data lives in Cin7 Core (their ERP/inventory hub), with Shopify Web and an outside POS as downstream consumers. v0 must produce a Cin7-shape CSV — a different schema than Shopify's — from the same canonical record.
Grouped multi-variant packaging. JBM packages near-1:1 (one Shopify product per SKU, one variant each). CMS packages aggressively: a single product carries multiple finish / size / colour variants. The platform must support both packaging styles in its output, and CMS is the test case for the grouped-variant side.
Non-Shopify POS at retail. JBM uses Shopify POS, so its POS and web share a catalogue natively. CMS runs Lightspeed POS in-store, separate from Shopify Web. Cin7 is the merge point. v0's job ends at producing the Cin7 import; the retailer's existing Cin7-to-Lightspeed sync handles downstream.
Different catalogue weighting. JBM's catalogue is print-music-heavy and gear-mainstream. CMS's catalogue skews toward band, orchestral strings, woodwind/brass, and AMEB-driven sheet music — driven by a substantial schools/education channel. Useful texture for the platform's category mapping editor.

Supporting (non-load-bearing) differences:

Single store + small adjacent warehouse, vs JBM's three retail + warehouse.
Trade-ins and pre-owned inventory mixed with new-from-suppliers — sharpens the v0 boundary on retailer-managed-unique items.
Schools/education side-channel (account billing, quotes, no public portal) — clarifies that v0 doesn't need B2B-portal features even when the retailer has B2B-adjacent revenue.

Identity

Capital Music & Sound (CMS). One retail store in Canberra (ACT), plus a small warehouse on the same site for receiving, repairs, and online dispatch. Active in the local schools/education market — band programs, instrument hire/sale to schools, AMEB exam materials.

SKU count: ~11,500 active SKUs grouped into ~6,800 products. Average ~1.7 variants per product, but heavily bimodal: most accessories and sheet music are 1 variant; instruments, hardware, and apparel-like items routinely carry 4–12 variants (finish, size, left/right-handed, body wood). This shape is the load-bearing contrast with JBM.

Team size: ~25–35 staff. Rough split: 12–18 on the retail floor (sales, service, repairs); 4–6 in the warehouse (receiving, online pick/pack, dispatch); 6–10 in head office covering web/ecommerce, marketing, finance, buying, product data, and the schools channel.

Web presence: single Shopify storefront, AU-only, with a "schools & education" landing page that funnels enquiries to a sales contact (no self-serve B2B portal, no published trade pricing). One unified product catalogue powers web and Lightspeed POS, fed from Cin7. No marketplace presence.

Catalogue shape

Approximate scale: ~11,500 SKUs across ~6,800 products and ~280 populated merchandising collections. Roughly 22% of products are print music / sheet music (heavily AMEB-weighted), 18% are band/orchestral/woodwind/brass (a meaningful contrast to JBM's gear-dominant weighting), and the remainder spans the mainstream gear and accessories catalogue. Catalogue is single-location-deep, not multi-location-broad.

Top-level categories (CMS's own taxonomy, used for both site navigation and as the target shape for the platform's category mapping):

Electric Guitars — Solid Body, Hollow & Semi-Hollow, Extended Range (7/8-string), Baritone, Left-Handed, Boutique, Acoustasonic
Acoustic Guitars — Dreadnought, Concert / Grand Concert, 12-String, Cutaway, Beginner, Travel, 3/4 Size
Bass Guitars — 4-String, 5-String, 6-String+, Acoustic Bass, 3/4 Length, Left-Handed
Amps — Guitar Combos / Heads / Cabs, Bass Combos / Heads / Cabs, Acoustic Instrument Amps, Keyboard Amps, Drum Amps
Guitar Pedals & Effects — Distortion/Overdrive/Boost, Delay/Reverb, Modulation, Compressor, Buffer/Preamp, Wah/Filter/EQ, Loopers, Tuners, Multi-FX, Bass Pedals, Acoustic Pedals, Pedalboards & Power
Pianos & Keyboards — Digital Pianos, Stage Pianos, Synthesizers, Workstations, Home Keyboards, MIDI Controllers, Desktop Synth Modules, Drum Machines, Accessories & Pedal Units
Drums & Percussion — Acoustic Kits, Electronic Kits, Snare Drums, Cymbals (Crash, Ride, Hi-Hats, China, Splash, Packs), Hardware (Stands, Pedals, Clamps), Drum Heads, Sticks/Brushes/Mallets, Hand Percussion (Cajons, Congas, Bongos, Djembes, Doumbeks), Bells, Blocks, Boomwhackers, Drum Accessories
Studio Gear — Audio Interfaces, Studio Monitors, Microphone Preamps, Control Surfaces, Recording Microphones, Closed-back Headphones, Acoustic Treatment, Studio Accessories
Live Sound — PA Speakers (Passive, Powered), Mixers (Analog, Digital), Cabinet Speakers, DI Boxes & Utility, Stands, Cables, Live Sound Accessories
DJ & Electronic Music — DJ Controllers, Turntables, DJ Mixers, DJ Media Players, DJ Headphones, DJ Accessories
Band & Orchestral — Brass (Trumpet, Trombone, Tuba, Cornet, Baritone Horn, French Horn), Woodwind (Saxophone family, Clarinet family, Flute family, Bassoon, Recorders, Harmonicas), Orchestral Strings (Violins by size 1/4 / 1/2 / 3/4 / full, Cellos, Double Basses), Bows, Reeds, Mouthpieces, Maintenance, Stands, Cases & Bags
Sheet Music — AMEB (Piano, Violin, Vocal, Guitar, Brass & Woodwind, Other; multiple Series), Method Books, Songbooks, Choral, Band, Bass, Single Sheet, Blank Manuscript
Ukulele & Folk — Soprano / Concert / Tenor / Baritone Ukuleles, Banjos, Mandolins, Folk Accessories
Guitar Accessories — Strings (Electric, Acoustic, Bass, Classical, 12-String), Picks, Straps, Cases & Bags, Stands, Tuners, Capos, Slides, Pickups, Power Supplies, Strap Locks
Cables & Connectivity — Instrument Leads, Speaker Leads, Patch Cables, Adapters, Connectors
Pre-Owned / Trade-In — retailer-managed, out of v0 platform scope (see below)

Depth signal: the heaviest top-level categories by SKU count are Sheet Music (~2,500, AMEB-driven), Band & Orchestral (~2,000), Drums & Percussion (~1,800 once de-duped across sub-collections), and the combined Guitars family (~1,700). Pedals & Effects (~900) and Pianos & Keyboards (~900) sit mid-pack. DJ and Live Sound are long-tail (<400 each).

Brand mix. Top non-sheet-music brands by SKU count, in rough order: Boss, Fender, Behringer, Yamaha, Audio Technica, Cort, Casio, Ampeg, D'Addario, Denis Wick, Bach, Blackstar, Roland, Korg, Shure, AKG, Pearl, Sabian, Zildjian, Gibson, Epiphone, Ibanez. Brass & woodwind brings in a distinct brand slice: Bach, Buffet, Denis Wick, Yamaha (brass models), Conn-Selmer, Besson. Sheet music dominated by AMEB-publisher imprints, Hal Leonard, Wise, Alfred, Boosey & Hawkes. Roughly ~320 unique brands total — long-tail, consistent with the AU norm of distributors carrying many brands. Same note as JBM: "brand" here is Shopify Vendor / Cin7 Brand, not supplier.

Catalogue characteristics relevant to v0:

Grouped multi-variant packaging is the default. Electric guitars and basses are packaged as one product per model with finish + left-handed variants. Drum kits are packaged as one product per series with size/wrap variants. Strings sets are packaged as one product per line with gauge variants. Cases and bags are packaged as one product per series with size variants. The platform's Shopify-shape output must support multi-variant grouping, and the Cin7-shape output must emit a product-family + variant-code structure that matches Cin7's import schema. Variant grouping is a retailer-side transformation-config choice, not a canonical-layer decision. Suppliers can opt in to expose grouping hints in their data (model identifier + variant axes); when present, the canonical record carries those hints as an available option that retailer transformations can use to group or ignore. CMS's transformation uses them aggressively (group wherever possible); JBM's transformation ignores them and emits SKU-per-product. Same canonical record, different packaging.
AMEB sheet music depth is a category-specific attribute (facets) stress case distinct from JBM's print-music section. AMEB items carry exam-grade, syllabus-year, instrument, series, and edition attributes that don't map onto JBM's publisher/composer/arranger shape. Useful evidence for whether the v0 facet design generalises to a different sheet-music sub-pattern.
Band & orchestral facets (reed strength, mouthpiece cut, string gauge, instrument size 1/2/3/4/full) introduce a facet shape the JBM-priority categories don't cover. Out of scope for v0 facet curation (the four v0 categories are Electric Guitars, Pedals & Effects, Print Music, Drums), but in scope for category-mapping editor coverage — these categories must exist in the starter taxonomy and be mappable, with thin or empty facet sets.

The emulated catalogue should also include some products exclusive to CMS:

Products imported directly from suppliers unique to CMS (small AU brass/woodwind importers, schools-program suppliers).
Pre-owned and trade-in instruments — every item is genuinely unique (serial-anchored, single-quantity, condition-graded).
Schools-program bundles assembled in-house (e.g. starter clarinet kit = clarinet + reeds + case + cleaning kit, repriced as one SKU).

These exclusive products are out of v0 scope for the platform — CMS manages them directly in Cin7. They're noted here to make the emulation realistic, and to make the v0 retailer-overlay boundary concrete.

Stack

Confirmed: Cin7 Core (ERP / inventory / canonical product data hub) + Lightspeed Retail POS (in-store, single location) + Shopify Web (ecommerce only, no Shopify POS).

Cin7 holds the canonical retailer record. Product data is created and edited in Cin7 first. Cin7's existing integrations push product data to Shopify (via Cin7's Shopify connector) and to Lightspeed (via Cin7's Lightspeed connector). Stock levels and orders flow back to Cin7. The retailer treats Cin7 as the source of truth.

Implications for v0 output:

The primary v0 deliverable for CMS is a Cin7-shape CSV that imports cleanly into Cin7 Core. Different schema than Shopify's CSV: product-family + variant-code structure, brand/category as Cin7-recognised values, supplier reference fields, tax rules, units of measure, internal vs public notes.
A Shopify-shape CSV is also useful — for the head-office team that occasionally bypasses Cin7 for catalogue edits, and for content / SEO fields that don't round-trip cleanly through Cin7's connector. This is a secondary output, not the primary, but it's the same canonical record transformed two ways.
Lightspeed output is not in v0 scope — Cin7's existing Lightspeed connector handles that side. The platform's job ends when Cin7 has the data.

Xero for finance, Microsoft 365 tenant for email/collaboration. Cin7 pushes invoicing to Xero; doesn't affect v0 product-data output.

Current product data workflow

Product data managed inside Cin7. Catalogue creation is done by 1–2 staff in head office (web/ecommerce + buying), with Cin7 as the central editor.

Supplier data arrives in mixed formats: a small number of distributors provide CSV/Excel pricelists with reasonable structure; most arrive as PDFs, email attachments, or "log in to our portal and download." Enrichment content (descriptions, specs, images) is rarely included — staff manually source it from brand websites, supplier dealer portals (where available), or scrape it together.

Once in Cin7, the staff member tags the product to internal categories, brands, and suppliers; Cin7's Shopify connector pushes a subset of fields (title, description, images, price, basic categorisation) to the Shopify storefront. SEO / collection tagging / web-specific copy is handled in Shopify directly after the push.

Pre-owned and trade-in items are entered in Cin7 manually, one at a time, with serial numbers and condition grades. They're flagged as one-of-a-kind so the Shopify connector doesn't try to deduplicate or merge them.

The primary pain points:

Enrichment effort scales with new-product count. Sourcing descriptions and specs is the slow step.
Variant grouping is error-prone. Deciding whether a new model should be a new product with finish variants, or several new products, and getting Cin7's product-family + variant-code structure right, takes operator judgement.
AMEB and sheet music re-issues generate constant small SKU churn — new edition years, new syllabus series — that staff have to track manually.
Brass & woodwind specs vary by supplier, with no consistent attribute set, making category-driven attribute population slow.

Supplier-side catalogue changes (new products, EOL, price updates) almost always have to be actioned manually.

What this retailer wants from the platform

CMS wants Cin7 to remain their canonical hub but stop being their data-cleaning workshop. They want supplier products to arrive in Cin7 already enriched (descriptions, specs, images), already mapped to their internal categories and brands, and already grouped into the variant structure they use. They want the same canonical record to also produce a clean Shopify-shape file for the occasional direct-to-Shopify edit. They want standardised facets so the Shopify storefront can power proper category filters (instrument size, reed strength, exam grade) without manual tagging.

Strategic positioning (Scenario B): the platform replaces CMS's enrichment work, not their ERP. Cin7 stays. Cin7 receives clean platform output and continues to push to Shopify and Lightspeed downstream. Long-term, the platform may absorb more of the Cin7 product-data editing surface, but v0 only needs to deliver clean CSVs into Cin7's import path.

v0 output success criterion

CMS can import a v0 Cin7-shape CSV into Cin7 Core without further cleanup, and the resulting Cin7 records are fully enriched, correctly mapped to CMS's category tree, grouped into the variant structure CMS uses, and matching CMS's current data requirements. Cin7's existing Shopify and Lightspeed connectors handle downstream propagation. Separately, a Shopify-shape CSV produced from the same canonical record imports cleanly into the Shopify admin for the side cases that bypass Cin7.

Cadence — v0 supports two output modes:

Full re-download — complete CSV export of CMS's mapped catalogue, in both Cin7 and Shopify shapes.
Delta CSV — CSV containing only products changed since the previous export, in both shapes.

v0 does not support a live sync/diff workflow; CMS pulls exports on their own cadence and runs them through Cin7's import path.

Images: v0 passes through supplier-provided image URLs (Cin7 and Shopify both fetch them on import). The platform does not host images in v0.

Category mapping: CMS has their own category tree. Mapping from the platform's canonical taxonomy to CMS's tree is configured per-retailer via the mapping editor (admin-only at v0, per scope.md). Exports contain CMS's category strings, not the canonical ones. The Cin7 output uses Cin7's category-path convention; the Shopify output uses Shopify's collection-handle convention. Same canonical mapping, different rendering.

Variant grouping: the canonical record carries each SKU as an atomic unit, with product-family identifiers. The Cin7 output renders as product-family + variant-code rows; the Shopify output renders as one product with multiple variants. This is a transformation-time choice, not a canonical-layer decision.

v0 design implications surfaced by this profile

CMS surfaces design points about the v0 transformation/export layer that JBM doesn't expose. Most arise from Cin7 Core's inventory list import schema (~95 columns; required fields: ProductCode, Name, CostingMethod; recommended batch size 5,000 rows).

Output schema is part of the transformation config, not just field mapping. Each target platform has its own column set, column order, required fields, batch-size guidance, and format conventions (dimension units, weight units, date formats, currency formatting). The v0 mapping/transformation editor must treat output-schema definition as a per-retailer configuration concern, alongside the field-to-field mapping it already covers. A Cin7 CSV missing CostingMethod will not import regardless of how well supplier data is mapped — schema fidelity is the import gate.
Required fields can be retailer-overlay constants. Cin7 requires CostingMethod (e.g. FIFO, Weighted Average) — a retailer accounting choice, not a supplier datapoint. The transformation layer's "hardcoded values" surface (already in v0 scope) covers this, but the Cin7 example makes it load-bearing rather than nice-to-have: without per-retailer constants for required fields, no Cin7 import works.
Three-axis variant model. Cin7's product family carries ProductFamilySKU, ProductFamilyName, and Option1/2/3 (Name + Value pairs). Variant grouping in the Cin7 output is capped at three axes. Within CMS's expected variant patterns (finish + size + handedness max), three axes is sufficient. Canonical records that imply more than three axes either collapse at transformation time or split into multiple product families — both are transformation-config behaviours, not canonical-layer changes.
Pricing / accounting / tax fields are retailer-overlay constants. Cin7's PriceTier1–PriceTier10, InventoryAccount, RevenueAccount, ExpenseAccount, COGSAccount, PurchaseTaxRule, SaleTaxRule are all retailer configuration. v0 emits supplier RRP only; everything else is either left blank (where Cin7 accepts blanks) or filled by per-retailer hardcoded values in the transformation config. None of these are supplier data and none should leak into the canonical layer.
Optional fields with intermittent supplier coverage. HSCode, CountryOfOrigin, and carton-level dimensions (CartonLength / Width / Height / InnerQuantity / Quantity / Volume) are sometimes in supplier data, often not. v0 emits them when canonical carries them; leaves blank otherwise. Cin7 accepts blanks here.
Cin7 is not unique in fussiness. Shopify has its own quirks (collection handles, Vendor field, metafield namespacing, image-position rules). Lightspeed has its own. Future targets will have theirs. The v0 transformation layer should be designed to absorb arbitrary target-platform schemas as configuration, not by hand-coding each one. CMS happens to surface Cin7's fussiness because Cin7's schema is the most explicit example we have; the general lesson is platform-wide.

Out of scope for v0

Direct sync with Cin7, Shopify, or Lightspeed via API.
Automatic updates, notifications, or out-of-sync data checks.
Self-enrichment (personalising descriptions etc. specific to CMS).
Pricing management in-platform (no competitive sale-price logic, no schools-program discount logic).
Full catalogue management in-platform — any CMS-specific products (pre-owned, trade-ins, schools-program bundles, direct imports from unique suppliers) are handled in Cin7 separately.
Platform-hosted image storage (pass-through supplier URLs only).
Live sync / diff workflow (full + delta CSV exports only).
Retailer sell-price ingestion. CMS continues to set their own trade pricing in Cin7 after import; v0 exports surface RRP only. Schools-program pricing is set in Cin7 independently.
Lightspeed-shape output. Cin7's existing Lightspeed connector covers the POS side downstream.
B2B portal features (schools quoting, account billing, trade-tier pricing visibility) — CMS handles these in Cin7 and via sales contact, not via the platform.
Pre-owned / trade-in management. Every item is unique and retailer-managed.
AMEB syllabus-year change tracking. CMS staff continue to manage edition churn manually until the curation workstream covers AMEB facets post-v0.

Open questions

Variant grouping when supplier data doesn't expose hints. Confirmed: variant grouping is a retailer transformation-config choice, and suppliers can opt in to expose grouping hints (model identifier + variant axes). Open: what happens when supplier data arrives ungrouped and doesn't expose hints, but the retailer's transformation wants to group? Options: (a) canonical carries enough downstream-derivable hooks (parsed MPN patterns, brand+model heuristics) for the transformation to group at output time; (b) canonical leaves it atomic and the retailer accepts ungrouped output for those SKUs. (b) is acceptable for v0 and avoids canonical-layer heuristics; flag for revisit post-v0.
AMEB and exam-syllabus facet shape. AMEB exam materials have a different attribute pattern than the v0 Print Music facet set (which is publisher / composer / arranger / instrumentation / difficulty / format). Whether the v0 Print Music facet set covers AMEB sufficiently, or whether AMEB is a post-v0 facet-curation extension. Either is acceptable for v0 — the question is which.
Cin7-side reconciliation if SKUs already exist. CMS's Cin7 instance already contains thousands of products. A v0 import has to either treat the import as additive (new products only), or match-and-update existing Cin7 records. Match-and-update is a sync behaviour and is out of v0 scope per scope.md; the realistic v0 path is "import as new" with the retailer accepting that initial overlap with existing Cin7 records is a one-time manual reconciliation. Worth flagging explicitly in any demo so the audience doesn't assume sync.