SNAC Ecosystem

Response to Scope Document Review and Change Requests

Confidential

This document responds to each item raised in the Scope Document Review and Change Requests. For every item, we provide: (a) the proposed resolution or scope update, and (b) any points that require further discussion before the change can be finalised into the scope.

Where an item can be resolved directly, the proposed scope language is included below and will be incorporated into the next revision of the Full Scope Document. Where an item requires a decision or further input, we have outlined the options and our recommendation, and flagged it for discussion.

Part 1. Gaps Between the Full Scope Document and the Original Ecosystem Brief

1. Progressive Autonomy Roadmap for Autonomous Commerce

Request summary: The scope mentions progressive autonomy but does not commit to it as a phased product roadmap. Subscription Auto-Ordering needs to be a distinct module in the scope. The data model and consent framework must support the full four-stage progression from day one.

Resolution: Accepted. A new module, Subscription Auto-Ordering, will be added to the SNAC Consumer App section (Section 2) with the following scope:

• User opts into weekly or daily meal subscriptions per vertical (restaurant delivery, grocery, meal kits, home chef bookings)
• AI selects meals, rotates variety, respects dietary constraints, stays within user-set budget
• Orders placed automatically on schedule; user receives notification of upcoming order before it locks
• User can veto, swap, or skip any item within a defined window before the order is confirmed
• Consent framework scoped from day one: explicit opt-in per vertical, pause and resume controls, spending limits, veto window configuration, full audit trail of automated orders placed on behalf of the user
• Data model designed from day one to support the full four-stage progression:
  • Stage 1 (Suggestions): preferences schema storing taste graph, recommendation history, acceptance and rejection signals
  • Stage 2 (Pre-Built Baskets): basket template storage, channel-optimised selections, one-tap confirmation flow
  • Stage 3 (Subscription Auto-Ordering): subscription rules, schedules, budget constraints, veto window logic, automated order execution log
  • Stage 4 (Full Autonomous Commerce): autonomous decision authority model, smart device integration hooks, wearable data-driven adjustment triggers
• Subscription management UI: active subscriptions, upcoming orders, edit schedule, spending history, pause and cancel

This approach ensures the data model and consent framework are built for the full progression from day one, avoiding the retrofit cost highlighted in the review.

2. Interconnection Map and Event Contracts

Request summary: The original brief defines 20 or more specific data and value flows between components. The scope lists Kafka or Redis Streams as infrastructure but does not formalise these flows as event contracts. An event catalogue with schemas, producers, consumers, and delivery guarantees per flow is requested.

Resolution: Accepted. An Event Catalogue will be produced as a dedicated technical deliverable, covering all inter-component data and value flows defined in the original ecosystem brief.

The catalogue will include, for each flow:

• Event name and description
• Producer service
• Consumer service(s)
• Payload schema (field names, types, required and optional fields)
• Delivery guarantee (at-least-once, exactly-once, or best-effort)
• Ordering and idempotency requirements
• Error handling and dead-letter queue behaviour

The flows to be documented include, at minimum, the specific examples referenced in the review:

Point for discussion: We propose producing this event catalogue as the first output of the foundation phase rather than as a prerequisite before build begins. The rationale is that event schemas are most accurate when produced by the teams who will implement the services, and the foundation phase is specifically designed for contract definition. However, if the preference is to have the catalogue completed before development commences, we can accommodate that with an additional lead-time period. We would welcome guidance on the preferred sequencing.

3. Flywheel Instrumentation

Request summary: The four compounding flywheels need dedicated KPIs and dashboards that prove they are actually compounding. Generic analytics will not surface this.

Resolution: Accepted. A new module, Flywheel Instrumentation Dashboard, will be added to the Data Intelligence Layer (Section 11) with the following scope:

Data Flywheel KPIs:

• Data points captured per user per week (growth rate over time)
• AI recommendation acceptance rate (trending over time)
• Search-to-order conversion rate
• Recommendation accuracy improvement curve (month-over-month)
• New data sources onboarded (scraper coverage, EPOS connections, card-linked merchants)

Loyalty Flywheel KPIs:

• Earn-to-spend velocity: average time from cashback credit to cashback redemption
• Wallet balance growth rate across the consumer base
• Tier progression speed: average time from Bronze to Silver, Silver to Gold
• Cross-vertical spend rate: percentage of users transacting in 2 or more verticals
• Churn rate by tier (proving higher tiers churn less)
• Mission completion rate and repeat mission engagement

Supply Flywheel KPIs:

• SNAC Fresh price vs external market benchmark per product category
• Average cost savings per restaurant per month through SNAC Fresh
• Procurement cycle efficiency: time from bid deadline to purchase order generation
• AI buying recommendation acceptance rate by 3PL partner
• Price trend analysis: daily price movement vs market index

Procurement Network Flywheel KPIs:

• Number of active suppliers per product category (competition density)
• Bids per picking list item (supplier competition on each order)
• Price compression over time (are prices falling as more suppliers compete)
• New food business acquisition rate via SNAC Fresh referral
• Supplier retention rate and new supplier onboarding rate

Each flywheel will have a dedicated dashboard view accessible to the SNAC internal team. Automated alerts will be configured to trigger when any flywheel metric stalls or reverses, enabling proactive intervention.

4. Virtual Brand Creation as a First-Class Module

Request summary: Virtual brand creation currently sits as a single bullet under Business AI Agent (section 3.3.3). It should be broken out as its own module with six specified components.

Resolution: Accepted. Virtual Brand Creation will be elevated to a standalone module within SNAC Workspace + KitchenOS (Section 3) with the following scope:

4a. Concept Recommendation Flow

• AI analyses postcode-level demand data: which cuisine types are underserved, what price points convert, what menu items generate the highest margin in the area
• Competitive landscape analysis: existing restaurant density by cuisine type within delivery radius
• Presents recommended brand concept to merchant with supporting data (projected demand, target audience, suggested cuisine positioning)

4b. Merchant Approval Gates

• Merchant reviews AI recommendation including projected demand, suggested cuisine, target audience, estimated revenue potential
• Merchant can approve the concept as presented, modify parameters (cuisine, pricing, positioning), or reject with feedback
• Nothing launches without explicit merchant approval at every stage

4c. Brand Identity Setup

• Name, logo, description, and visual theme for the virtual brand
• AI-generated branding options available; merchant can also provide custom branding
• Separate storefront identity from the parent kitchen
• Brand categorisation and tagging for consumer search and discovery

4d. Menu and Pricing Workflow

• AI generates recommended menu composition and pricing based on local demand data and the kitchen's existing ingredient inventory (linked to SNAC Fresh procurement data where available)
• Merchant reviews each menu item, adjusts portions, pricing, descriptions, and images
• Menu published as a separate entity from the parent brand

4e. Launch and Go-Live Process

• Virtual brand published across SNAC consumer app, SNAC Direct, and connected aggregators via KitchenOS
• Orders for the virtual brand route to the parent kitchen automatically
• Launch marketing: AI can trigger a cashback boost and targeted notifications to consumers in the delivery radius

4f. Per-Brand Performance Tracking

• Separate analytics dashboard per virtual brand: orders, revenue, margin, customer demographics, repeat rate
• Comparison view against the parent brand and other virtual brands from the same kitchen
• AI recommendations for menu adjustments and brand repositioning based on performance data

5. UGC Creation Tooling

Request summary: The scope covers the Creator Marketplace attribution and payout side but does not specify the in-app content creation tools. Capabilities needed include photo and video capture flows, dish tagging, venue tagging, review composition, and a simplified posting experience.

Resolution: Accepted. A new module, UGC Creation Tooling, will be added to SNAC TV and Creator Economy (Section 5) with the following scope:

• In-app camera for photo and video capture with food-optimised filters and editing
• Dish tagging: user selects specific menu items from the venue's menu during or after capture. Auto-suggestion based on GPS location and recent orders.
• Venue tagging: auto-detected from GPS or manually selected from search. Linked to the venue's SNAC profile.
• Review composition: structured rating (food, service, value, ambience) combined with free-text review and photo or video attachment
• Simplified posting flow: capture, tag, add comment, post. Designed for completion within three taps from capture to published content.
• Content distribution: published content appears on the user's profile feed, the tagged venue's SNAC page, the SNAC TV feed (if video format), and the social graph activity stream
• Loyalty integration: posting earns XP; high-engagement reviews earn cashback; referrals driven by content unlock bonuses
• Content moderation: AI-based filtering for inappropriate content before publishing, with manual escalation for edge cases

6. Brand and Menu Creation with AI — End-to-End Merchant Workflow

Request summary: Related to point 4 but distinct. The actual merchant-facing user journey needs to be specified as a concrete workflow, not a capability statement.

Resolution: Accepted. The following end-to-end workflow specification will be added to the Virtual Brand Creation module (see point 4 above) to define the merchant-facing journey at each stage:

Step 1 — AI Surfaces Recommendation The Business AI Agent analyses postcode-level consumer demand, identifies underserved cuisine types, and evaluates the merchant's existing kitchen capacity and ingredient access. A recommendation card is presented in the Merchant Hub Dashboard containing: suggested cuisine type, target consumer segment, projected weekly order volume, recommended price range, and competitive gap analysis.

Step 2 — Merchant Reviews and Configures The merchant opens the recommendation, reviews the supporting data, and enters a guided setup flow. The merchant can accept the suggested concept or modify any parameter. The AI adjusts its projections in response to merchant changes in real time (e.g., if the merchant changes the cuisine type, the projected demand recalculates).

Step 3 — Menu Composition The AI generates a draft menu based on the chosen concept, drawing on local demand patterns, trending dishes, and the kitchen's existing ingredient inventory. Each item includes a suggested name, description, price, and estimated margin. The merchant reviews item by item, edits as needed, and uploads or approves images.

Step 4 — Brand Identity and Storefront The merchant configures or approves the brand name, logo, description, and visual theme. A preview of the virtual brand's storefront is generated showing how it will appear in the SNAC consumer app and on SNAC Direct.

Step 5 — Go-Live The merchant confirms the launch. KitchenOS is configured to route orders for the new brand to the parent kitchen. The brand is published across the SNAC consumer app, SNAC Direct, and any connected aggregator platforms. An optional launch cashback boost and targeted notification campaign can be activated.

Step 6 — Ongoing Performance The per-brand analytics dashboard goes live. The AI monitors performance and surfaces recommendations for menu adjustments, pricing changes, and promotional opportunities. The merchant can pause, modify, or retire the virtual brand at any time.

Point for discussion: The workflow above defines the system behaviour and merchant journey at each stage. If wireframe-level or screen-level UX specification is required for scope sign-off, we would propose producing that as a separate product design deliverable during the design phase, as UX detail typically follows scope agreement rather than preceding it. We would welcome guidance on whether the workflow specification above is sufficient for scope purposes.

Part 2. Additional Recommendations to Fold Into the Scope

1. AI Explainability and Override UI

Request summary: Merchants need a user-facing explanation for every AI Agent decision and granular override controls beyond the current binary automatic or manual-approval modes.

Resolution: Accepted. The following will be added to the SNAC Workspace + KitchenOS section (Section 3), as updates to the Business AI Agent Integration module and as a new sub-module:

AI Explainability Layer:

• Every AI Agent action visible to the merchant includes a human-readable explanation of why the action was taken
• Explanation format: what was observed (e.g., "Tuesday 2pm footfall projected 40% below average"), what was decided (e.g., "Cashback increased from 2% to 15% for the next 3 hours"), and what evidence supports the decision (e.g., "Similar boosts have recovered 60% of the gap historically")
• Explanation displayed inline on the Merchant Hub Dashboard alongside each AI action in the activity log
• Merchants can tap any explanation to see the underlying data points

Granular Override Rule Engine:

• Replaces the current binary Automatic / Manual Approval modes with a configurable rule-based system
• Merchants define override rules per action domain:
  • Pricing: "Auto-approve changes under X%, escalate anything above"
  • Cashback: "Auto-approve during off-peak hours only, require approval during peak"
  • Marketing: "Auto-approve content posts, but require approval for spend over a threshold"
  • Procurement: "Auto-approve reorder within existing supplier list, escalate new supplier selection"
• Default rule sets provided for common merchant profiles (independent restaurant, chain operator, dark kitchen)
• Rules configurable via a simple UI with plain-language rule descriptions, not technical syntax
• Override audit trail: every rule trigger, every override, every approval or rejection logged

Point for discussion: We recommend the Explainability Layer be included from the initial Business AI Agent release, as it directly affects merchant trust and adoption. The Granular Override Rule Engine could follow in a subsequent release if needed, with the binary Automatic / Manual Approval modes serving as the interim control. We would welcome guidance on whether both components are required for the initial release or whether the phased approach is acceptable.

2. Customer Support and Dispute Resolution Infrastructure

Request summary: No dedicated support module exists in the scope. The platform needs ticketing, SLA management, escalation workflows, a refund and credit engine integrated with the wallet and loyalty layers, a B2B procurement dispute flow, and consumer-side dispute resolution.

Resolution: Accepted. A new section, Customer Support and Dispute Resolution, will be added to the scope as a cross-platform module with the following components:

Ticketing and SLA Management:

• Support ticket creation from consumer app, merchant dashboard, driver app, and SNAC Fresh
• Ticket categorisation by type: order issue, delivery issue, cashback dispute, procurement dispute, account issue, payment issue
• SLA rules per ticket category and priority level
• Escalation workflows: automatic escalation on SLA breach, manual escalation by support agent
• Support agent dashboard with queue management, ticket history, and resolution tools

Refund and Credit Engine:

• Integrated with SNAC Wallet and Loyalty OS
• Refund to original payment method, wallet credit, or cashback credit depending on dispute type and resolution
• Partial refund support for individual items within a multi-brand order
• Automatic loyalty point adjustment when a disputed transaction is reversed
• Audit trail for every refund and credit action

B2B Procurement Dispute Flow:

• Dispute initiation from SNAC Fresh procurement dashboard by food business or 3PL partner
• Dispute types: supplier shortage (ordered quantity not delivered), invoice mismatch (invoice price differs from confirmed order price), quality issue (product does not meet expected quality)
• Resolution workflow: dispute raised, evidence attached (photos, invoice comparison), supplier notified, resolution proposed (credit, replacement, or adjustment), both parties confirm
• Linked to Invoice OCR and Reconciliation module for automatic discrepancy detection

Consumer-Side Dispute Resolution:

• Dispute initiation from order history within the consumer app
• Dispute types: failed order, missing items, wrong items, delivery issue (late, damaged, never arrived), cashback not credited
• Resolution options: reorder, refund, wallet credit, cashback adjustment
• AI-assisted first-pass resolution for common dispute types (e.g., automatic refund for confirmed non-delivery)
• Escalation to human agent for complex disputes

Point for discussion: For the ticketing and SLA management layer, we recommend integrating a third-party platform (such as Zendesk or Intercom) rather than building a custom ticketing system. The SNAC-specific components — the refund and credit engine, the B2B procurement dispute flow, and the consumer-side dispute resolution — would be built custom as they require deep integration with the SNAC Wallet, Loyalty OS, and SNAC Fresh procurement layer. We would welcome confirmation of this approach, and guidance on whether support infrastructure is required before consumer launch or whether a lightweight initial version is acceptable with full capability following in a subsequent phase.

3. Fault Tolerance and Graceful Degradation

Request summary: The scope does not specify system behaviour during partner outages. Circuit breakers, documented fallback paths, and degradation modes are needed per critical dependency.

Resolution: Accepted. A new section, Resilience and Fault Tolerance, will be added to the Unified Backend Architecture section (Section 12) specifying the fallback behaviour for each critical external dependency:

Architecture-level resilience patterns applied across all services:

• Circuit breaker pattern on every external dependency call
• Retry with exponential backoff and jitter for transient failures
• Dead-letter queues for events that cannot be processed after maximum retries
• Health check endpoints per service for Kubernetes liveness and readiness probes
• Graceful degradation principle: no single external dependency failure should make the core platform unusable

Point for discussion: The fallback strategies above define the intended behaviour per scenario. If a more detailed resilience design document with sequence diagrams per failure path is required, we propose producing that during the foundation phase alongside the event catalogue (see Part 1, Item 2). We would welcome guidance on whether the specification above is sufficient for scope purposes or whether the detailed design document is expected before build.

4. Drop Offline and Low-Bandwidth Support

Request summary: Drivers routinely hit patchy signal. Drop needs offline-first architecture with local caching, offline order acceptance, and sync-on-reconnect with conflict resolution.

Resolution: Accepted. The following will be added to the Drop section (Section 6) as an update to the Core Platform module:

Offline and Low-Bandwidth Architecture:

• Local on-device storage (SQLite or Realm) caching active order details, route data, pickup and dropoff addresses, and map tiles for the current route
• Offline order acceptance: where the aggregator protocol supports asynchronous acceptance, Drop queues the accept or decline action locally and syncs when connectivity returns
• Route continuation: cached map data and last-known GPS route allow navigation to continue without live connectivity
• Sync-on-reconnect: when connectivity is restored, local state is reconciled with server state. Conflict resolution rules:
  • Order assignments: server state takes priority (another driver may have been assigned during the offline period; the driver is notified if their queued acceptance was superseded)
  • Driver position and activity logs: local state takes priority (the device has the most accurate position and timing data)
  • Earnings and completed deliveries: reconciled and confirmed on both sides before finalisation
• Low-bandwidth mode: compressed data payloads, text-only order information (images deferred), reduced GPS update frequency to conserve bandwidth
• Connectivity status indicator visible to the driver at all times, showing current signal strength and sync state
• Automatic retry queue for any actions that failed during the offline period

5. Reservation Platform Integration — Strategic Decision Needed

Request summary: The scope does not clarify whether SNAC is aggregating live availability from OpenTable, Resy, Quandoo, and TheFork, or building its own reservation engine. These are fundamentally different projects. A decision is needed before build starts.

Resolution: This item requires a strategic decision. We present three options below with our assessment of each:

Option A — Aggregate Live Availability via Partner APIs Integrate with OpenTable, Resy, Quandoo, and TheFork APIs to access real-time table availability and process bookings through their platforms.

• Advantage: Full live booking capability from day one for restaurants already on these platforms
• Risk: Requires API partnership agreements with each platform. Availability of these APIs is not guaranteed — some platforms restrict third-party booking access. Ongoing dependency on partner platform uptime and API stability.
• Scope: Medium — API integration per platform, availability aggregation, booking flow coordination

Option B — Build a Proprietary Reservation Engine SNAC manages its own table inventory, availability calendar, and booking flow for restaurants that opt in.

• Advantage: Full ownership of the booking experience, no external dependency, deep integration with SNAC Loyalty and AI Agents
• Risk: Significantly larger scope. Restaurants would need to adopt SNAC as their reservation system or maintain dual systems.
• Scope: Large — essentially a new product within the ecosystem

Option C — Hybrid Approach (Recommended) Use the Web Scraping Engine for restaurant discovery data (as currently scoped). For booking transactions, deep-link consumers to the restaurant's existing reservation platform (OpenTable, Resy, etc.) or to the restaurant's own booking system. SNAC owns the booking flow only for restaurants using SNAC Direct or KitchenOS with table management enabled.

• Advantage: Smallest scope, no external partnership dependency for launch, booking ownership grows organically as SNAC Direct adoption grows
• Risk: SNAC does not own the full booking flow for externally-managed restaurants in the initial phase
• Scope: Small — deep-linking plus internal booking for SNAC Direct restaurants

Our recommendation is Option C. It allows Table Bookings to function as a discovery and routing vertical from day one without blocking on external partnership agreements, while progressively building proprietary booking capability through SNAC Direct adoption.

This item requires a decision before the Table Bookings module scope can be finalised. We would welcome guidance on the preferred approach.

6. Agent Conflict Resolution Protocol

Request summary: The Agent-to-Agent Commerce Protocol is listed as a module but the conflict rules are not specified. Three specific conflict scenarios are raised: Business Agent vs FMCG campaign, simultaneous last-table booking, and negotiation below margin floor.

Resolution: Accepted in principle. The conflict resolution architecture will be added to the Agent-to-Agent Commerce Protocol module (Section 8) with the following framework:

Conflict Resolution Architecture:

• Priority hierarchy engine: every agent action is tagged with a priority class and source authority
• Tiebreaker mechanism: deterministic resolution for simultaneous competing actions
• Margin floor enforcement: hard constraint that no agent negotiation can override
• Deadlock detection: timeout-based detection with automatic fallback to deterministic behaviour
• Conflict audit trail: every conflict detected, the resolution applied, and the outcome logged

Proposed resolution rules for the three scenarios raised:

Scenario 1: Business Agent cashback vs active FMCG campaign on the same menu item Proposed rule: FMCG-funded campaigns operate as a contractual commitment. If the merchant has opted into an active FMCG campaign, the campaign terms take priority on the specific items covered by that campaign. The Business Agent may adjust cashback on all other menu items freely. If the Business Agent's proposed rate is higher than the FMCG campaign rate, the higher rate applies (as this benefits both the consumer and the brand).

Scenario 2: Two Customer Agents simultaneously booking the last table at 8pm Proposed rule: First-come-first-served with optimistic locking at the database level. The first agent to confirm the booking locks the slot. The second agent receives an immediate rejection and is automatically offered the next-best alternative (e.g., "8pm is no longer available. 7:30pm is available with 10% bonus cashback.").

Scenario 3: Customer Agent negotiation pushes a Business Agent below the merchant's margin floor Proposed rule: The margin floor is a hard constraint that cannot be overridden by any agent. If a Customer Agent's negotiation request would push the effective margin below the floor, the Business Agent returns its best available offer at the margin floor rather than rejecting the negotiation outright. The Customer Agent presents this as the best available deal to the consumer.

Point for discussion: The three proposed resolution rules above represent our recommended approach. However, the business priority decisions embedded in these rules — particularly the FMCG campaign priority and the margin floor enforcement model — are business policy decisions that should be confirmed rather than assumed. We would welcome review and confirmation of each proposed rule, or alternative priority logic if preferred.

Summary

Open Items Requiring Input

The following items require a decision or confirmation before they can be finalised into the scope:

1. Event Catalogue sequencing (Part 1.2): Produced during foundation phase (recommended) or completed before build commences?
2. Brand and Menu Creation UX detail (Part 1.6): Workflow specification sufficient for scope sign-off, or wireframe-level UX detail also required?
3. AI Explainability phasing (Part 2.1): Both Explainability Layer and Granular Override Rule Engine required for initial Business AI Agent release, or phased?
4. Customer Support approach (Part 2.2): Third-party integration for ticketing confirmed, or full custom build preferred? Required before consumer launch or acceptable in a subsequent phase?
5. Resilience design depth (Part 2.3): Specification in scope document sufficient, or separate resilience design document with sequence diagrams expected?
6. Reservation Platform strategy (Part 2.5): Option A (aggregate via partner APIs), Option B (build proprietary engine), or Option C (hybrid with deep-linking, recommended)?
7. Agent conflict business rules (Part 2.6): Proposed resolution rules for the three scenarios confirmed, or alternative priority logic preferred?

We are happy to discuss any of these items in further detail. As noted in the review, the wording is open to revision and we welcome any reframing before changes are formalised into the scope.