CRB MVP Scope Matrix — 2026-04-28 (v2)

Governing thesis: Canary never owns the transaction of record. The retailer already has systems that create items, process transactions, generate invoices, manage payroll, and plan orders. Canary's job is to read all of that, add intelligence the retailer can't get anywhere else, alert in real time, and expose clean APIs so every other tool can plug in. The L3 processes split along three lines:

Category A — Canary Owns (~120 L3s)

The proprietary intelligence + evidentiary layer. Loss prevention analytics, real-time alerting, store ops visibility, hash-chained evidence. Nothing in the SMB market delivers this for specialty retail. This is what Canary is.

Q — Loss Prevention (all 38 L3s) ← THE CORE PRODUCT

Canary-Distinctive L3s in Other Modules (~82 L3s)

These exist specifically because Canary is the intelligence layer — not because another system would do them.

Evidentiary layer (Module T) | L3 ID | Process | Why Category A | |-------|---------|---------------| | T.2.3 | Hash-before-parse | Patent-critical ordering constraint. Canary's evidentiary integrity depends on this | | T.2.4–T.2.6 | Seal record write, fanout routing, mutation-lock | Tamper-evidence layer applied at the transaction grain | | T.4.1–T.4.9 | Canonical event publication (SALE, RETURN, VOID, PAYMENT, TAX, AUDIT, routing, customer upsert) | Canary's canonical data model — the intelligence substrate above the raw Counterpoint data | | T.5.1–T.5.5 | Merkle anchoring (tree, root hash, leaf linkage, audit proof, verification) | The L2 blockchain anchoring. One of the three platform accountability rails | | T.7.1–T.7.12 | Substrate contracts | Canary's internal API contract surface — what T owes every downstream module |

LP substrate configuration (Module N) | L3 ID | Process | Why Category A | |-------|---------|---------------| | N.4.1 | Drawer config thresholds | Feeds Q Q-DC-01 (drawer discrepancy). LP fires off this baseline | | N.4.2 | Discount cap config | Feeds Q Q-DR-01 (abnormal discount). The "what's too much" line | | N.4.3 | Void reason codes | Feeds Q Q-VO-01 allow-list | | N.4.4 | Comp reason codes | Feeds Q Q-CO-01 allow-list | | N.5.1–N.5.2 | Device health + connectivity alerts | Canary alerting layer on store infrastructure |

Customer intelligence surface (Module C) | L3 ID | Process | Why Category A | |-------|---------|---------------| | C.2.1–C.2.4 | Customer risk scoring and behavioral pattern detection | Canary intelligence — no Counterpoint equivalent | | C.6.1–C.6.4 | Investigator surface (lookup, history, risk score, cross-module context) | How the investigator acts on a Q alert. Canary's operator UX |

Analytics intelligence (Modules D, F, S, P, W) | Module | L3 IDs | Process | Why Category A | |--------|--------|---------|---------------| | D | D.4.1–D.4.5 | Transfer-loss reconciliation + adjudication | Canary detects shrink in transit. No Counterpoint equivalent | | D | D.5.1–D.5.4 | Distribution reconciliation analytics | Canary analytics surface on inventory variance | | F | F.2.1–F.2.4 | Financial metrics connected to LP outcomes | Canary's "here's what shrink cost you" surface | | S | S.5.1–S.5.3 | Item lifecycle / drift detection and alerts | Canary detects when item attributes shift unexpectedly | | S | S.7.1–S.7.3 | Category analytics and margin target surface | S.7.2 (margin targets) feeds Q-ME-01 margin exception detection | | P | P.2.1–P.2.3 | Promotional window inference from price variance | Canary infers promotions because Counterpoint has no promo API. Prevents Q false positives | | C | M.4.1–M.4.5 | B2B detection rules Q-M-01 through Q-M-05 | Routes through Q's Chirp pipeline. B2B LP intelligence | | L | L.3.3 | Employee productivity signal to Q (LP context) | Connects labor data to LP investigation. Canary intelligence | | W | E.1.1–E.5.6 | Cross-domain exception detection, aggregation, case management, remediation, MCP tools | The v3 capstone. W is Canary's immune system — generalizes Q across all domains |

Category B — Interface Layer on Counterpoint (~120 L3s)

Canary reads this data from NCR Counterpoint, canonicalizes it, and makes it available to Category A. The retailer creates and owns this data in Counterpoint. Canary never replaces these workflows — it reads their output.

Building this layer fully is the API footprint strategy: any future integration, partner connector, or analytics module plugs into clean canonical data without touching Counterpoint directly.

The API footprint argument: Build all of Category B fully, not just the slices Category A immediately needs. A Counterpoint VAR, an ERP integration, a BI tool, a future Canary module — all of them plug in at the B layer. Canary becomes the cleanest Counterpoint data surface in the market. That's a durable competitive moat that strengthens the NCR partnership.

Category C — Retailer Has Another Solution (~117 L3s)

The retailer already manages these functions in Counterpoint, QuickBooks, spreadsheets, ADP, Homebase, or a dedicated planning tool. Canary's role here is data provider and analytics surface, not workflow owner. Build APIs and read-only analytics. Don't build the workflow.

The Write-Back Question

Canary reads everything. The only identified write-back in the corpus is O.4.4 (POST /Document, DOC_TYP=PO). The correct decision framework:

Does the retailer benefit more from Canary pushing the PO into Counterpoint automatically, or from Canary exporting the PO suggestion to whatever workflow the buyer already uses?

At the SMB ICP ($10M–$50M), the answer is likely export. The buyer has a process. Canary surfaces the intelligence; the buyer executes in Counterpoint. The write-back pattern matters more as retailers grow and want automation. Build the export API first; the write-back is a v2+ decision.

Module-Level Summary

Note: totals are approximate; a small number of L3s straddle boundaries and are counted in the dominant category.

Build Roadmap Implied by This Framework

Launch (v1): All Category A + all Category B. ~285 L3s. This is Canary: LP intelligence fully operational, complete Counterpoint API footprint, real-time alerting, evidentiary anchoring, clean canonical data available for every future integration.

v1.1 — Category C analytics surfaces (not workflows): Export APIs for planning tools (J data), B2B analytics (C data), labor context (L data). The retailer's planning tool, accounting software, and labor system can pull from Canary. Canary becomes the data hub.

v2+ — Selective workflow absorption: Based on customer demand, absorb specific Category C workflows where Canary can demonstrably beat the existing solution. The candidate list: O.4 PO approval workflow (once receiving volume justifies it), S.6 range analytics (if no planning tool is connected), P.6 promotion calendar (if it directly improves Q accuracy).

Pass: GRO-670 | v2 of MVP scope matrix — A/B/C framework replacing Bucket 1/2/3 | Source: CRB-PROCESS-MAP.md + CRB-UI-SURFACE-SCAN.md