The Canary Retail Spine — 13 Modules

Canary Retail's module catalog is organized along a 13-prefix spine. Each prefix is a letter that names both the module and its slug namespace in the codebase. The spine is deliberately exhaustive — it covers the full operating surface of an SMB specialty retailer from customer-facing commerce through back-office governance.

The spine, at a glance

v1 — Differentiated-Five (T + R + N + A + Q)

These five ship at v1 because together they answer the question: "What do SMB specialty retailers have that isn't productized at this tier?"

• T and Q are the classical LP workload — transaction ingestion and rule-based detection. Everyone ships these, most ship them poorly.
• R, N, and A are where Canary differentiates. Unified customer across channels (R), every device as a first-class asset (N), and threat detection over the asset registry (A) — these are standard in enterprise retail tech but missing from SMB-tier tools.

v1's pitch: "You get the LP module everyone charges for, plus the customer / device / asset tier nobody charges for, because they're the same platform."

v2 — CRDM expansion (C + D + F + J)

Once a retailer runs on v1, the next ask is almost always: "Can you also handle our buying, inventory movement, and financial flow?" These four modules answer that question without pulling the retailer toward an ERP replacement.

Each v2 prefix closes a specific operational gap the SMB collapse analysis surfaces in worked-example-solex:

• C — Commercial. The Solex reference is single-channel and single-catalog; its Assortment / Allocation coverage is partial (no multi-store, no zone-differentiated assortment). C closes the commercial catalog, department, and supplier dimensions for multi-store retailers.
• D — Distribution. Solex is single-warehouse. The canonical retail model assumes warehouse + store + transit inventory tiers with transfers between them. D closes the multi-location inventory gap.
• F — Finance. Solex collapses vendor-side finance into "payment-processor fees + bank receipts." F closes the vendor surface: purchase orders, supplier invoices, reconciliation, vendor compliance, rebate and chargeback flows.
• J — Orders. Solex has no PO / replenishment surface; on-order inventory is missing from the coverage. J closes the forecast and ordering loop, restoring the open-order dimension and enabling automated replenishment.

v3 — Full spine (S + P + L + W)

Space/range/display, pricing/promotion, labor/workforce, and generalized work-execution across all domains. This is the full retail operating platform, delivered module-by-module rather than as a single cutover.

Each v3 prefix closes a remaining operational gap:

• S — Space. Solex is online-only; physical merchandising and space management are absent. S closes the planogram, fixture, and floor-plan gap for the retailers that operate physical stores.
• P — Pricing & Promotion. Solex has a promo-code dimension but the promotion engine itself is stubbed. P extends this into a full promotion engine: bundle rules, threshold promotions, conditional offers, markdown cadence, pricing-elasticity analysis.
• L — Labor. Solex has no employee surface. Staffing, Store Location Analysis, and Staffing coverage are all zero. L closes the labor model: scheduling, time tracking, payroll integration, workforce analytics.
• W — Execution. Solex produces clean Loss Prevention signal through Chirp/Fox. W generalizes that detection + case pattern beyond LP to every other domain in the spine — exception handling for merchandising discrepancies, labor anomalies, vendor-performance breaches, and asset-condition drift.

Dependencies

Modules depend on:

• CRDM — the canonical retail data model. Every module reads and writes the shared People × Places × Things × Events × Workflows entities.
• ARTS adoption — POSLog, Customer, Device, Site standards frame the entity definitions for T/R/N modules.
• Evidence chain — hash-chained intake and append-only timelines underlie all modules; Q and W depend on it most directly.
• Agent mesh — every module has an agent population backing its tooling. The agent mesh architecture lives in the CATz vault (cbm-v2/agent-strategy.md) — open the sibling vault to read it.

Per-module detail

See modules/<prefix>-<name>.md for the per-module deep-dive. Each module article covers:

• Purpose
• CRDM entities touched
• ARTS mappings (where applicable)
• Integrations (upstream sources, downstream consumers)
• Agent surface (what agent tools the module exposes)
• Security posture (auth, tenant scoping, PII handling)
• Roadmap status

Related

• overview
• crdm
• arts-adoption
• differentiated-five-add-on