Grocery Retail Reference Architecture¶

RA-002 | Unified Commerce end-to-end model for grocery and food retail
Classification: reference-architecture · Vertical: Grocery Retail

Industry Profile¶

Grocery retail is architecturally distinct from other verticals in ways that force specific capability and application choices:

Capability Map¶

Maturity levels: 0 Absent · 1 Aware · 2 Fragmented · 3 Integrated · 4 Optimised

Mission-Critical Capabilities (MVP ≥ 4)¶

Critical Capabilities (MVP 3)¶

Standard and Lower Capabilities¶

Critical Processes¶

graph TD
    subgraph "In-Store"
        CHK[Checkout]
        SCO[Self-Checkout]
        SNG[Scan and Go]
    end
    subgraph "Omnichannel"
        BOI[BOPIS / Click & Collect]
    end
    subgraph "Loyalty & Engagement"
        LOY[Loyalty Enrollment]
        VOU[Voucher Redemption]
    end

    CHK -->|multi-buy applied| VOU
    SCO -->|age gate| CHK
    SNG -->|exit verification| CHK
    BOI -->|picker app| CHK
    LOY -->|personalised offers| VOU

    style CHK fill:#1e88e5,color:#fff
    style SCO fill:#1e88e5,color:#fff
    style SNG fill:#1e88e5,color:#fff
    style BOI fill:#1e88e5,color:#fff
    style LOY fill:#43a047,color:#fff

Grocery-Specific Architectural Considerations¶

Weighted Item Flow¶

sequenceDiagram
    participant C as Customer
    participant POS_S as POS / SCO
    participant Scale as Electronic Scale
    participant Basket as Basket Mgmt
    participant Promo as Promotion Engine

    C->>POS_S: Place item on scale / scan PLU
    POS_S->>Scale: Capture weight (kg)
    Scale-->>POS_S: Weight confirmed (e.g. 0.432 kg)
    POS_S->>Basket: AddBasketItem (PLU, qty=0.432, UOM=kg, unit_price=£4.50/kg)
    Basket-->>POS_S: Line total: £1.94
    POS_S->>Promo: Evaluate (fresh produce promotions)
    Promo-->>POS_S: No promotion applies
    POS_S-->>C: Running basket total updated

Architectural implication: basket-management must support unit-of-measure as a line attribute with weight-based pricing. This is a schema extension not required in fashion or specialty retail.

Fresh Markdown Cascade¶

sequenceDiagram
    participant SIM_S as Store Inventory (SIM)
    participant PromEng as Promotion Engine
    participant POS_S as POS / Price Labels

    Note over SIM_S: Daily batch: scan best-before dates
    SIM_S->>PromEng: BatchNearExpiry (SKU, best_before=T+2, qty=24)
    PromEng->>POS_S: Activate markdown rule (-25%)
    Note over POS_S: Price label updated
    SIM_S->>PromEng: BatchNearExpiry (SKU, best_before=T+0, qty=8)
    PromEng->>POS_S: Activate end-of-day rule (-50%)
    Note over POS_S: Automated markdown applied
    Note over SIM_S: Unsold units → waste recording

Architectural implication: store-inventory at level 3+ must emit BatchNearExpiry events. promotions must support inventory-triggered markdown rules (not just time-based or manually activated).

Age Verification Interrupt¶

Every checkout touchpoint (staffed, SCO, scan-and-go, online) must handle age-restricted items.

Architectural implication: checkout capability must expose an age-verification hook that blocks PaymentAuthorized until associate approval event is received.

Multi-Buy Promotion Evaluation¶

Unlike fashion (where promotions are applied at checkout), grocery promotions must evaluate incrementally as items are added to the basket:

Basket state after 1× Coca-Cola: £1.99 (no promotion)
Basket state after 2× Coca-Cola: £3.98 (no promotion)
Basket state after 3× Coca-Cola: £2.99 (3-for-2 promotion applied → saves £0.99)

Architectural implication: promotions capability at level 4 requires a stateful basket-aware rules engine, not a simple coupon validator.

Typical Application Stack¶

Maturity Targets¶

Capabilities that MUST reach level 4 for Minimum Viable:

checkout · promotions · payment-processing · basket-management

Operational Experience View¶

Modelled using SPEC-016 Experience Model and ADR-016.
Tasks are vendor-neutral canonical units. Screens are application-specific projections.

Key Actors in Grocery Retail¶

Priority Journeys by Maturity Level¶

Grocery-Specific Experience Patterns¶

Weighted Item Capture Task
The capture-weighted-item task has no equivalent in fashion. It requires a log-weight Interaction (scale integration) or key-in-weight manual fallback. This Interaction exercises checkout + basket-management and produces a BasketItemAdded event with a variable price field. Any checkout Journey in grocery must include this task as optional (present when the basket contains weighted items).

Age Verification Interrupt Task
The verify-customer-age task is an interrupt — it is triggered mid-Journey by a AgeVerificationRequired event when a restricted item is scanned. It requires an authorisation Interaction type and may escalate to a store-manager-override Role. This is a cross-cutting task that appears in Checkout, SCO, and Scan-and-Go Journeys.

Multi-Buy Evaluation Task
Before payment capture, a evaluate-promotions task fires the multi-buy rule engine (BOGOF, 3-for-2, meal-deal). The task exercises promotions + basket-management and may trigger a PromotionApplied event with basket recalculation. A notification Interaction displays the applied saving to the customer.

Pilot: BOPIS Operational Experience¶

The BOPIS process is fully modelled end-to-end using the Experience Model (shared with Fashion RA):

• BOPIS — Customer Journey — 5 tasks, 12 interactions
• BOPIS — Store Associate Journey — 6 tasks, 17 interactions
• Store Manager Exception Journey — 2 tasks (unfulfillable reservation)

Catalog Reference¶

• Machine-readable model: catalogs/reference-architectures/grocery-retail.yaml
• Fashion Retail RA: RA-001 Fashion Retail
• Vertical Comparison: RA Vertical Comparison
• Capability maturity reference: Assessment Framework

RA-002 — Grocery Retail Reference Architecture — UC-BoK v0.8-alpha