# Swire Coca-Cola — Growth Accelerator Future-State Prototype
## Codex Build Brief / Source of Truth
**Prepared for:** Fluence  
**Prototype purpose:** Swire Coca-Cola executive / stakeholder demonstration  
**Priority:** Rapid, high-fidelity, interactive prototype  
**Status:** Build-ready

---

# 1. Objective

Build a modern, browser-based prototype that evolves the legacy PepsiCo **GrowthAccelerator** concept into a future-state **Swire Coca-Cola Field Execution Platform for Category Management**.

This is **not** a pixel-for-pixel port of the FileMaker application.

The legacy FileMaker solution should be treated as:

- a workflow reference,
- a source of proven interaction patterns,
- a source of realistic product / planogram structure,
- and a functional ancestor of the Swire experience.

The new prototype should demonstrate how Swire could connect:

**category strategy → store condition → opportunity identification → recommended planogram → field action → verification → measurable value**

The application should feel like a credible enterprise product, not a concept deck.

---

# 2. Core Product Idea

The future-state system should support this loop:

1. **Observe**  
   Capture or ingest the current shelf / cooler condition.

2. **Understand**  
   Compare actual execution against the relevant planogram, assortment, merchandising rules, and account context.

3. **Diagnose**  
   Identify gaps such as out-of-stocks, misplaced products, missing facings, unauthorized items, competitor encroachment, or assortment opportunities.

4. **Recommend**  
   Suggest corrective and growth-oriented actions.

5. **Model**  
   Show the proposed future state as an editable planogram.

6. **Quantify**  
   Associate recommendations with opportunity/value signals.

7. **Execute**  
   Convert recommendations into field tasks.

8. **Verify**  
   Confirm execution using a follow-up shelf image / comparison.

9. **Learn**  
   Aggregate outcomes so category management can understand what is working across territories, stores, equipment, and recommendations.

The prototype does not need production AI, computer vision, or live enterprise integrations. These capabilities may be represented with deterministic demo data and simulated states.

---

# 3. Product Positioning

Use this working definition internally while building:

> **A Field Execution Platform for Category Management**

The experience should make it clear that planograms are an important capability inside a broader execution system.

Avoid positioning the product as merely:

- a planogram editor,
- a shelf visualization tool,
- a photo audit tool,
- or a reporting dashboard.

The value is the connected workflow.

---

# 4. Legacy GrowthAccelerator — Concepts to Preserve

The attached FileMaker DDR, screenshots, Quick Reference Guide, and exported planogram packet establish the following legacy capabilities.

## 4.1 Geography-driven template selection

Legacy flow:

**Home → Region → Market → Planogram Template**

The FileMaker application lets the user choose a region and market, then create a planogram from a market-specific template.

### Preserve concept
Swire should retain geography/context awareness, but modernize it into persistent territory / account / store context rather than a multi-step map wizard.

---

## 4.2 Planogram library

The legacy application stores user-created planograms in a searchable and sortable library.

### Preserve concept
Swire should maintain a planogram / execution library, but organize it around:

- customer,
- store,
- channel,
- territory,
- equipment type,
- status,
- date,
- and compliance/opportunity signals.

---

## 4.3 Customer-specific planograms

The legacy "Create a New Planogram" workflow captures:

- title,
- description,
- customer first name,
- customer last name,
- customer email,
- establishment name,
- notes.

### Preserve concept
A planogram is not merely a generic diagram. It can be a customer/account-specific execution object.

In the Swire prototype, associate each planogram with a **Store / Account record**.

---

## 4.4 Interactive shelf / cooler

This is the experiential center of the legacy application.

Users can:

- inspect a shelf position,
- view product name,
- view UPC,
- view package size,
- see door / shelf / position information,
- replace a product,
- remove a product,
- reset an edited position,
- see additional product information,
- search the product catalog,
- change equipment headers,
- move between Beverage and Snack planograms.

### Preserve strongly
This interaction model is one of the highest-value parts of the legacy experience.

The new application should make the shelf / cooler visualization a first-class workspace.

---

## 4.5 Product catalog

Legacy replacement workflow supports product search with:

- product image,
- product name,
- package size,
- UPC.

### Preserve
Build a reusable product catalog / search experience.

For the prototype, a curated subset of realistic products is sufficient.

---

## 4.6 Competitor awareness

The legacy application contains a **Clear Competitor Product** action and distinguishes portfolio / competitor product in its underlying data.

### Evolve
This is highly relevant to the Swire concept.

The Swire application should support visual and numerical indicators for:

- Swire / Coca-Cola portfolio facings,
- competitor facings,
- whitespace / empty positions,
- share of visible shelf,
- unauthorized competitor product,
- competitive encroachment.

Do not imply that these metrics are production-validated unless using clearly marked demo data.

---

## 4.7 Pricing

The legacy application can toggle pricing directly on the planogram.

### Evolve
Pricing may remain available at SKU level, but the future-state prototype should emphasize higher-order business impact:

- estimated opportunity value,
- potential incremental revenue,
- facing gain/loss,
- compliance improvement,
- share-of-shelf improvement.

Use illustrative values.

---

## 4.8 Sharing / output

The legacy application can generate a customer-facing planogram packet and share it by email.

The exported planogram packet contains both:

- a visual planogram,
- and an execution-oriented SKU list showing location, UPC, product, and size.

### Preserve concept, modernize execution
The new prototype should show an **Export / Share / Create Task** path.

For the demo, no real email or backend is required.

---

## 4.9 Selling materials / enablement

Legacy GrowthAccelerator includes a Selling Materials area and Help Center.

### Preserve as secondary capability
Do not prioritize for the first build. Represent as a **Resources** nav item or lightweight panel if time allows.

---

# 5. Future-State Swire Information Architecture

Primary desktop navigation:

1. **Overview**
2. **Opportunities**
3. **Stores**
4. **Planograms**
5. **Tasks**
6. **Insights**
7. **Resources**
8. **Settings**

For the first demo build, fully implement the first five.

Insights / Resources / Settings may be lightweight but should appear credible.

---

# 6. Priority Demo Screens

Build these screens in order.

---

## SCREEN 1 — Territory Overview

### Purpose
Immediately communicate that this is a category execution platform, not a planogram utility.

### Suggested content

Header:
- Swire Coca-Cola branding
- "Growth Accelerator" working product name
- user profile
- search / notification affordance

Filters:
- This Week
- Territory
- Channel

KPI cards:
- Execution Score
- Planogram Compliance
- Opportunity Value
- Tasks Completed

Example illustrative values:
- Execution Score: 84%
- Planogram Compliance: 78%
- Opportunity Value: $1.24M
- Tasks Completed: 24 / 36

Main content:
- execution score over time
- top opportunities
- stores requiring attention
- recent activity / priority tasks

### Interaction
Clicking a top opportunity or store should navigate to Store Detail.

---

## SCREEN 2 — Stores

### Purpose
Give field and category teams a territory-level execution view.

### Layout
Split view:

**Left / main**
- map or geographic visualization with status pins

**Right / side list**
- store number
- address / account
- execution score
- status
- last visit / update

Filters:
- territory
- channel
- compliance range
- opportunity level
- issue type

### Status examples
- Green: performing / compliant
- Amber: attention needed
- Red: high priority

### Interaction
Selecting a store opens Store Detail.

---

## SCREEN 3 — Store Detail / Execution Intelligence

This should be one of the strongest screens in the demo.

### Header
Store #3821  
Account / location information  
Territory / channel  
Last visit  
Assigned representative

### KPI summary
- Execution Score
- Planogram Compliance
- Product Availability
- Share of Shelf
- Opportunity Value

### Tabs
- Overview
- Shelf / Planogram
- Issues
- Opportunities
- Tasks

### Main visual
Show a current shelf / cooler image or reconstructed shelf representation.

Overlay or adjacent issue indicators:
- Missing
- Out of Place
- Incorrect Facing Count
- Competitive Encroachment
- Empty Position

### Right rail
**Detected Issues**
and
**Recommendations**

Example recommendations:
- Increase Coca-Cola Zero Sugar by 2 facings
- Move Sprite up one shelf
- Restore missing authorized SKU
- Replace unauthorized competitor facing

### Actions
- View Recommended Planogram
- Create Task
- Mark Reviewed

---

## SCREEN 4 — Planogram Intelligence / Comparison

This is the modern evolution of the FileMaker Virtual Viewer.

### Header
Store / equipment context  
Planogram name  
Compliance score  
Version / last update

### Tabs
- Actual
- Recommended
- Compare
- Products
- Issues

### Core workspace
High-quality cooler / shelf rendering.

Product positions should be clickable.

### Comparison behavior
Allow the user to switch between:

- **Actual State**
- **Recommended State**

Optional enhancement:
- side-by-side comparison
- "difference" overlays
- changed products highlighted

### Right rail
Shelf Summary:
- Total SKUs
- Compliant
- Out of Place
- Missing
- Competitor
- Empty

Recommendations:
- action
- reason
- expected impact

### Actions
- Accept Recommendation
- Edit Planogram
- Create Task
- Export

---

## SCREEN 5 — Interactive Planogram Editor

This is where the legacy GrowthAccelerator interaction model should be reused most directly.

### Required interactions

Click a product:
- image
- product name
- UPC
- package size
- shelf / facing location
- portfolio / competitor indicator
- current price (optional)
- status

Actions:
- Replace
- Remove / Clear
- More Info

### Replace workflow
Searchable modal / drawer showing:
- product image
- product name
- size
- UPC
- portfolio/category

Selecting a replacement should update the visual shelf immediately.

### Additional controls
- Undo
- Reset
- Show Pricing
- Show Compliance
- Show Opportunity
- equipment/header selection if practical

### Important
Do not build drag-and-drop unless it can be implemented cleanly and reliably within the available time.

Click → replace is sufficient for the executive demo.

---

## SCREEN 6 — Opportunity Detail

### Purpose
Connect shelf recommendations to business value.

Example opportunity:

**Increase Coca-Cola Zero Sugar facings**

Show:
- store / territory scope
- issue
- current facings
- recommended facings
- affected stores
- estimated incremental value
- confidence / priority
- recommendation rationale

Example:
- Current facings: 1
- Recommended: 3
- Affected stores: 550
- Est. opportunity: $286K
- Priority: High

### Actions
- View Stores
- View Planogram
- Create Tasks
- Approve Recommendation

Use clearly illustrative / demo values.

---

## SCREEN 7 — Tasks

### Purpose
Demonstrate that insights become field execution.

Tabs:
- My Tasks
- Team Tasks
- Completed

Task examples:
- Verify Planogram Compliance
- Address Out of Stocks
- Install Endcap Display
- Capture Shelf Photos
- Correct Facing Count

Fields:
- priority
- store
- owner
- due date
- status
- source recommendation

### Interaction
Selecting a task opens a compact detail drawer.

---

# 7. Optional Mobile Companion

If time permits after desktop functionality is stable, create a responsive mobile view for Store Detail / Tasks.

Suggested bottom navigation:

- Overview
- Stores
- Scan
- Tasks
- More

Center action:
**Scan**

The Scan interaction may be simulated.

Flow:
1. Tap Scan
2. show camera / uploaded shelf placeholder
3. display "Analyzing"
4. transition to identified issues
5. open Store Detail / Planogram result

Do not implement actual computer vision.

---

# 8. Primary Demo Story

The app should support one polished, deterministic walkthrough.

## Recommended walkthrough

### Step A
Open **Overview**.

Narrative:
Swire can see execution performance and growth opportunities across a territory.

### Step B
Select a high-priority store.

Narrative:
The platform identifies where execution is breaking down and where value can be created.

### Step C
Open Store #3821.

Narrative:
A recent shelf image / store condition has been analyzed and compared with the expected plan.

### Step D
Review issues and recommendations.

Example:
- 2 missing products
- 4 out-of-place products
- competitive encroachment
- opportunity to increase Coca-Cola Zero Sugar facings

### Step E
Open **Recommended Planogram**.

Narrative:
Instead of stopping at an audit result, Swire gets an actionable proposed future state.

### Step F
Toggle Actual ↔ Recommended.

Narrative:
Category strategy becomes visually understandable at shelf level.

### Step G
Click Coca-Cola Zero Sugar and edit a facing / replace a product.

Narrative:
Users retain human control and can adjust recommendations.

### Step H
Show quantified opportunity.

Narrative:
The system connects execution changes to value.

### Step I
Create a task.

Narrative:
The approved recommendation becomes field work.

### Step J
Return to Overview / Tasks.

Narrative:
Swire has closed the loop from category strategy to execution.

---

# 9. Demo Data Model

Use local JSON / TypeScript fixtures.

No production backend is required.

Suggested entities:

```ts
Territory
Region
Market
Store
Account
Equipment
Planogram
Shelf
Position
Product
Issue
Recommendation
Opportunity
Task
User
```

Suggested relationships:

```text
Territory
  └── Stores
       ├── Equipment
       │    └── Planograms
       │         └── Shelves
       │              └── Positions
       │                   └── Product
       ├── Issues
       ├── Recommendations
       ├── Opportunities
       └── Tasks
```

---

# 10. Suggested Product Fields

```ts
Product {
  id
  upc
  name
  brand
  packageSize
  category
  subcategory
  image
  portfolioOwner
  isSwirePortfolio
  illustrativePrice
}
```

---

# 11. Suggested Planogram Position Fields

```ts
PlanogramPosition {
  id
  equipmentId
  door
  shelf
  position
  productId
  facingCount
  expectedProductId
  status
  issueIds[]
  recommendationIds[]
}
```

Suggested `status` values:

```text
compliant
missing
out_of_place
wrong_facing_count
competitor
empty
recommended_change
```

---

# 12. Prototype Data

Seed the app with enough data to feel real, not exhaustive.

Recommended:

- 3 territories
- 12–20 stores
- 1 hero store with full detail
- 2–3 equipment / planogram types
- 35–60 beverage products
- 10–15 issues
- 6–10 opportunities
- 10–15 tasks

The hero store should have the richest data.

Use the legacy exported beverage planogram as structural reference for realistic shelf positions and UPC/product relationships.

---

# 13. Product Imagery

Prefer assets extracted from the existing GrowthAccelerator solution or supplied project files.

Do not scrape or download additional branded product imagery unless explicitly instructed.

If an exact asset is unavailable:
- use a neutral placeholder,
- preserve the correct package proportions,
- keep the data model ready for later asset replacement.

The prototype should not depend on external image URLs.

---

# 14. Visual Direction

The UI should feel:

- enterprise-grade,
- premium,
- contemporary,
- clean,
- highly legible,
- data-rich without being dense,
- operational rather than marketing-oriented.

Avoid:
- oversized gradients,
- excessive glassmorphism,
- giant corner radii,
- consumer-app styling,
- decorative dashboard clutter,
- overuse of Coca-Cola red.

Use red primarily for:
- brand accent,
- active navigation,
- high-priority action,
- key status / alert moments.

Use neutral surfaces and restrained status colors.

The shelf / planogram imagery should remain the strongest visual object on planogram screens.

---

# 15. Suggested Technology

For the rapid prototype:

- React
- TypeScript
- Vite
- CSS modules, Tailwind, or a lightweight component styling approach
- local JSON / TS fixtures
- Lucide icons or another free/open icon set
- Recharts or lightweight SVG charts if needed

No database required.

No authentication required.

No server required for initial demo.

The application should run locally with:

```bash
npm install
npm run dev
```

and build with:

```bash
npm run build
```

---

# 16. Architectural Guidance

Separate:

```text
/data
/components
/features
/pages
/assets
/types
```

Recommended reusable components:

- AppShell
- Sidebar
- KPIStat
- StoreCard
- OpportunityCard
- StatusBadge
- ShelfViewer
- ProductPosition
- ProductPopover
- ProductSearchDrawer
- IssuePanel
- RecommendationPanel
- TaskList
- PlanogramComparison
- FilterBar

Keep domain data separate from presentation components.

---

# 17. Important Fidelity Rule

The prototype should preserve **legacy functional DNA**, not legacy visual design.

Do not reproduce:

- FileMaker chrome
- old modal styling
- old navigation bars
- old typography
- old map styling
- old card styling

Do reproduce / evolve:

- planogram editing logic
- product replacement
- shelf-position semantics
- equipment context
- product metadata
- customer/store context
- pricing capability
- competitor distinction
- planogram output/share concept
- account-specific plan creation
- searchable planogram library

---

# 18. Simulated AI / Computer Vision

Any photo-to-planogram or image-recognition behavior in the prototype must be **explicitly simulated**.

The UX may show:

```text
Shelf image captured
↓
Analyzing shelf
↓
Products detected
↓
Planogram matched
↓
Issues identified
↓
Recommendations generated
```

But the underlying implementation may simply load deterministic fixture data.

Do not spend build time implementing ML.

---

# 19. Claim Discipline

This prototype is a future-state demonstration.

Avoid UI copy that implies unsupported production capability such as:

- "AI guarantees"
- "live computer vision"
- "real-time ERP integration"
- "proven revenue lift"
- "automated ordering"
- "production deployment"

Use phrasing such as:

- Estimated opportunity
- Illustrative value
- Recommended action
- Detected in demo
- Proposed future state

Do not place disclaimer text everywhere; simply keep claims disciplined.

---

# 20. Build Phases

## Phase 1 — Foundation
Build:
- app shell
- navigation
- routes
- fixture data
- design tokens
- reusable cards/statuses

## Phase 2 — Executive Story
Build:
- Overview
- Stores
- Store Detail
- Opportunities
- Tasks

## Phase 3 — Planogram Core
Build:
- ShelfViewer
- actual/recommended states
- clickable positions
- SKU information
- replacement workflow
- product search

## Phase 4 — Demo Polish
Add:
- transitions
- empty/loading states
- chart refinement
- visual hierarchy
- realistic copy
- responsive behavior
- demo-state reliability

## Phase 5 — Optional
Only after the above is stable:
- mobile companion
- simulated Scan flow
- Resources
- deeper Insights
- export mockup

---

# 21. Acceptance Criteria

The first usable prototype is successful when:

- It loads without external services.
- The design feels like a credible modern Swire enterprise platform.
- Overview → Store → Recommended Planogram → Edit → Create Task works as one uninterrupted demo path.
- Shelf products are visually represented.
- Shelf positions can be clicked.
- A product can be replaced from a searchable list.
- Actual and recommended planograms can be compared.
- Issues and recommendations are linked to shelf state.
- Opportunity value is visible.
- A recommendation can produce a task.
- No broken controls appear in the primary demo path.
- All demo values are deterministic.
- The app builds successfully with no console-breaking errors.

---

# 22. Source Hierarchy

When source materials conflict or appear incomplete, use this order:

1. **This build brief** — future-state product source of truth
2. **Legacy screenshots supplied by Fluence** — interaction / visual evidence
3. **GrowthAccelerator Quick Reference Guide** — legacy workflow reference
4. **FileMaker DDR XML** — legacy structural / script / field reference
5. **Exported planogram PDF** — planogram structure and execution output reference

Do not blindly port unused FileMaker functionality simply because it exists in the DDR.

---

# 23. Project Inputs to Place Beside This File

Recommended Codex project folder:

```text
/swire-growth-accelerator/
  SWIRE_ACCELERATOR_CODEX_BUILD_BRIEF.md

  /source/
    /ddr/
      Accelerator v1-1 - UNLOCKED_fmp12.xml

    /docs/
      GrowthAccelerator-Docs-v1.pdf
      PepsiCo Planogram.pdf

    /screenshots/
      [all supplied GrowthAccelerator screenshots]

    /assets/
      [any extracted product / equipment assets]
```

If branded Swire assets are available, add:

```text
/source/brand/
```

Do not block the first build waiting for perfect brand assets.

---

# 24. First Codex Instruction

Use the following as the initial instruction after attaching this file and the source materials:

> Read `SWIRE_ACCELERATOR_CODEX_BUILD_BRIEF.md` first and treat it as the future-state product source of truth. Review the legacy screenshots, Quick Reference Guide, exported planogram PDF, and FileMaker DDR only to understand the existing GrowthAccelerator workflows, data semantics, and interaction patterns.
>
> Do not recreate the FileMaker UI.
>
> Begin by inventorying the supplied source materials, then implement **Phase 1 and Phase 2** of the build brief as a working React + TypeScript prototype with deterministic local fixture data. Establish the design system and reusable architecture so that Phase 3 can add the interactive planogram workspace without rework.
>
> Before coding, briefly document:
>
> 1. your interpreted information architecture,
> 2. the primary demo path,
> 3. the fixture data model,
> 4. any missing assets or assumptions,
> 5. the proposed implementation sequence.
>
> Then proceed with the build.
>
> Keep the primary demo path stable and functional at all times. Do not spend time implementing real authentication, backend services, computer vision, machine learning, or production integrations.

---

# 25. Strategic North Star

The legacy GrowthAccelerator answered:

> **What should this cooler / shelf look like, and how can I customize it for this customer?**

The Swire future-state prototype should answer:

> **What is happening in this store, what should we change, why does it matter, what should the shelf become, and how do we get that change executed and verified?**

That distinction should guide every design and implementation decision.