Overview
About This Document
This document is the product reference for Flipkart Commerce Cloud (FCC) Catalog. It covers platform architecture, core entities, the three-layer ingestion–storing–serving pipeline, AI and intelligence capabilities, strategic vision, and onboarding guidance for publishers and their technical teams.
Audience: Network publishers, catalog operations teams, integration engineers, and e-commerce product managers.
Prerequisites: Familiarity with e-commerce concepts (products, listings, categories, sellers) is helpful but not required.
Table of Contents
- Introduction
- Platform Architecture and Key Concepts
- Core Catalog Entities
- Product Lifecycle
- Ingestion Layer
- Storing Layer
- Serving Layer
- AI and Intelligence Layer
- Capability Summary
- Market Context and Strategic Vision
- Go-To-Market Motions
- Metrics and Measurement
- Onboarding Checklist
- Glossary
1. Introduction
Overview
FCC Catalog is the product lifecycle management system at the heart of the Flipkart Commerce Cloud platform. It is responsible for owning and managing the complete lifecycle of every product on a publisher's marketplace — from initial ingestion and quality validation through to structured storage and real-time serving to all downstream systems.
Originally built as the internal catalog infrastructure powering Flipkart's marketplace of 200M+ SKUs, FCC Catalog has been externalized as a multi-tenant SaaS product available to retailers, marketplaces, and commerce platforms globally.
What FCC Catalog Does
FCC Catalog is the source of truth for all product information on a publisher's platform. It powers:
- Product discovery and detail pages
- Search and browse ranking signals
- Promotions and offer eligibility
- Fulfillment and order management
- Retail media targeting and relevance
- Recommendation and personalization engines
Every piece of product content — title, images, attributes, category, brand, relationships — flows through FCC Catalog.
What FCC Catalog Is Not
- Not a storefront or CMS. FCC Catalog manages product data and serves it via API. The publisher's frontend is responsible for rendering and layout.
- Not a pricing or inventory system. Transient data such as price, stock level, and promotions are owned by dedicated systems and only joined at the serving layer when required.
- Not a manual merchandising tool. Catalog powers algorithmic enrichment and quality automation at scale — it is not a content editing interface for individual products.
Who This Platform Is For
| Persona | Description |
|---|---|
| Network Publishers | Retailers and marketplaces wanting a battle-tested, AI-ready catalog system to manage product data at scale |
| Catalog Operations Teams | Internal ops teams responsible for vertical definition, QC, enrichment, and catalog quality governance |
| Integration Engineers | Technical teams integrating FCC Catalog APIs into seller portals, storefronts, fulfillment, and analytics pipelines |
| E-Commerce Product Managers | Product teams designing catalog strategy, seller onboarding flows, and category launch processes |
2. Platform Architecture and Key Concepts
Overview
FCC Catalog operates as a three-layer pipeline: Ingestion → Storing → Serving. Each layer has a distinct responsibility and communicates through well-defined API contracts, enabling publishers to adopt any layer independently or as a complete stack.
Sellers / External Sources
│
▼
┌─────────────────────────┐
│ INGESTION LAYER │ ← Product creation, validation, QC, enrichment
│ (Ingestor + AV + QC) │
└──────────┬──────────────┘
│ Validated Product Data
▼
┌─────────────────────────┐
│ STORING LAYER │ ← MDM, Relationships, State, Brand, Size Chart
│ (Camelot / Merlin / │
│ Constantine / Zulu) │
└──────────┬──────────────┘
│ Enriched, Structured Product Records
▼
┌─────────────────────────┐
│ SERVING LAYER │ ← Configurable views served to all consumers
│ (Zulu / APIs) │
└──────────┬──────────────┘
│
▼
Storefront · Search · Ads · Fulfillment · OMS · Analytics
Key Architectural Principles
Multi-tenant, headless, and API-first. FCC Catalog is built on MACH principles — Microservices, API-First, Cloud-Native SaaS, Headless. Every integration point is a well-documented API with no dependency on publisher-specific schemas or frontend implementations.
Product is seller-agnostic. A Product exists independently of any seller. A Listing captures a specific seller's intent to sell that product. This separation ensures catalog integrity across multi-seller marketplaces.
Zero customisation policy. FCC Catalog is built as a generic, multi-client platform. Every feature is designed to serve multiple publishers. Client-specific customisations are not supported, ensuring platform reliability and long-term maintainability.
Configurable, not hard-coded. Vertical schemas, validation rules, QC workflows, and serving views are all configurable by publishers through admin tooling — without requiring engineering changes.
3. Core Catalog Entities
Entity Overview
| Entity | Ownership | Description |
|---|---|---|
| Product | Full | The primary catalog entity. Represents any unique, potentially sellable item. Identified by a unique Product ID (PID/MSN). Seller-agnostic — can exist without any listing. |
| Listing | Stored | A specific seller's intent to sell a product. Captures selling-specific data: price, availability, fulfillment type. Owned by Seller systems; stored in Catalog. |
| Vertical | Full | The lowest level of product taxonomy — a homogenous grouping of products (e.g., Mobile, T-Shirt, Television). Defines the attribute schema for all products within it. |
| Taxonomy | Full | Hierarchical classification of products across multiple dimensions: Browse, Seller, Fulfillment, Analytics. Supports up to L5 depth. |
| Brand | Partial | Brand identity associated with products. Prevents brand abuse and fraud. Powers brand-level filtering, discovery, and warranty flows. |
| Size Chart | Full | Size definitions and associations for applicable verticals (e.g., Fashion, Footwear). Supports default charts and seller-configured custom charts. |
| Rich Media | Full | Buying guides, rich product descriptions (RPDs), and media assets (text, images, videos) associated with products to improve buyer conversion. |
| Variant Group | Full | A group of products that are varieties of each other — differing on variant attributes like color or size — displayed as swatches on product pages. |
| Item | Full | A grouping of products for browse and search representation — determined by which attributes buyers consider unique during the discovery journey. |
What Is a Product?
A Product is any entity that represents a unique, potentially sellable item from a customer's perspective. It carries all information required for discoverability and for making a buying decision.
A product can exist in the catalog without any listing — it represents the item itself, not the act of selling it. Listing information (price, availability, seller) is variable per seller, while product information is fixed and consistent across all sellers offering the same item.
Products are always associated with exactly one Vertical. The Vertical defines the product's schema — the set of attributes, allowed values, validation rules, and workflows applicable to products of that type.
Variants and Items
Two types of product groupings are central to how FCC Catalog powers browse and product page experiences:
| Grouping | What It Is | Who Controls It | Where It Shows |
|---|---|---|---|
| Variant Group | Products that are varieties of each other (color, size, storage). | Seller-initiated, system-verified. | Product Detail Page swatches |
| Item | Products grouped for browse diversity based on buyer perception. | System-generated automatically. | Search and browse results |
Example: For a trouser in 4 colors × 7 sizes = 28 total products. On the product page, all 28 appear as swatches (Variant Group). In search results, the 4 colors appear as distinct results but sizes are grouped per color (Itemization).
4. Product Lifecycle
Overview
Every product on the FCC Catalog platform moves through a defined lifecycle from initial discovery to serving at scale.
Vertical Definition
│
▼
Product Creation Request (PCR)
│
▼
Auto Validation + Media Internalisation
│
▼
Quality Check & Enrichment (QC)
│
▼
Product Matcher (Deduplication)
│
▼
Storing (MDM → Relationships → State → Aggregator)
│
▼
Serving (Views served to downstream systems)
│
▼
Product Edit → QC → Re-Store → Re-Serve
Product States
| State | Description |
|---|---|
| Draft | Initial state. Product data is incomplete or pending validation. A reserve PID is created but the product is not discoverable. |
| Ready | Product data is complete and has passed all validations. Product is live and discoverable by downstream systems. |
| Unreleased | Product data is complete but the product is scheduled for discovery after a future launch date. |
| On Hold | Product has been manually or systemically flagged. Not available for discovery or purchase. Data may be complete or incomplete. |
| Deleted | Lifecycle of the product has ended. Irreversible. The product is permanently unavailable. |
Discoverability is a separate flag (true/false) that controls whether a product in Ready state is surfaced on the platform. It depends on conditions such as minimum mandatory image count and completeness of key attributes. Network Admins can override product states with appropriate reason codes, and all overrides are logged and audited.
5. Ingestion Layer
Overview
The Ingestion Layer is the entry point for all product data into FCC Catalog. It accepts product creation and edit requests from sellers, external vendors, and upstream systems, runs a series of validation and quality steps, and hands off validated products to the Storing layer.
Status: ✅ Live
5.1 Ingestor — Product Creation and Edit
The Ingestor is the main orchestrator of the ingestion pipeline. It receives Product Creation Requests (PCRs) from the Seller Portal or API, coordinates validation, media internalisation, QC, and deduplication, and manages the handshake with the Storing layer.
Ingestion entry points:
| Method | Description |
|---|---|
| Seller Portal (UI) | Sellers create or edit products through the Seller Portal, selecting a vertical and filling in attributes. |
| Bulk Feed (CSV / API) | Sellers or external systems submit product data in bulk via CSV upload or API feeds for high-volume ingestion. |
| API (Real-time) | Direct API integration for programmatic product creation or edits, used by publisher backend systems. |
Standard PCR flow:
- Seller submits product data with vertical, attributes, and image URLs.
- UI-level validations fire in real time while the seller fills the form.
- PCR reaches the Ingestor. Vertical schema is fetched.
- Auto Validations (AV) run on text attributes and internalized media.
- Product Matcher checks for duplicates.
- QC & Enrichment platform processes the request.
- Post-QC AV and Product Matcher run again on enriched data.
- Storing systems are handed the validated product data and generate a PID.
5.2 Media Internalizer
The Media Internalizer downloads product images from seller-provided URLs, stores them in FCC's internal CDN, and associates them with the product entity. It runs before QC to ensure images are available for quality verification.
Status: ✅ Live
| Capability | Description |
|---|---|
| Image download from URLs | Reads and downloads images from seller-provided URLs. Logs error rates and timeouts with appropriate error codes. |
| Domain whitelist and blacklist | Maintains a list of approved and blocked domains for image sourcing. Sellers are notified of domain restrictions during the creation process. |
| Image validations | Format (JPEG, PNG only), color space (RGB only), resolution, aspect ratio, minimum image count per vertical, duplicate image detection. |
| Static Content Association | Once internalized, images are associated with the product's reserved PID via the Static Content Framework (SCF). |
Note: GIF and WebP formats are not supported. Promotional images with overlaid pricing or offer text should not be submitted as primary product images.
5.3 Auto Validations (AV)
Auto Validations run automatically on product data at multiple points in the ingestion pipeline — before QC, after enrichment, and post-QC. They ensure data quality and compliance before any product reaches a live state.
Status: ✅ Live
Text validations include:
| Validation | Description |
|---|---|
| Mandatory attribute check | Ensures all required attributes for the vertical are present and non-null |
| Allowed values validation | Checks attribute values against the vertical's configured allowed value list |
| Data type validation | Confirms attribute values match the expected data type (text, numeric, boolean, array) |
| Attribute length validation | Validates value length against vertical-defined limits |
| Duplicate attribute check | Identifies extra attributes not defined in the vertical schema |
| GTIN validation | Validates EAN/GTIN/UPC/ISBN for brands where barcode compliance is mandatory |
| Dependency validation | Validates conditional attributes — attributes that become mandatory based on the value of another attribute |
Image validations include: format, color space, aspect ratio, minimum resolution, minimum image count per vertical, duplicate image hash detection, and domain blacklist enforcement.
Each validation rule produces a structured result: a pass/fail status, a confidence score (High / Medium / Low), and a descriptive reason code. AV passes requests through even if low-confidence conditions fail — only high-confidence failures block the request from proceeding.
5.4 Manual QC and Enrichment Platform
The QC & Enrichment Platform is a human-in-the-loop (HITL) layer that ensures product data is correct, complete, and rich before a product goes live. Human Quality Verifiers (QVs) review batched tasks organized by vertical, guided by the platform's attribute definitions and guidelines.
Status: ✅ Live
QC capabilities:
| Capability | Description |
|---|---|
| Browse path QC | Verifies that the product is correctly categorized in the taxonomy |
| Image QC | Checks image quality, compliance with image guidelines, and minimum count |
| Attribute QC | Verifies correctness and completeness of mandatory and identity attributes |
| Compliance QC | Ensures products meet safety, legal, and regulatory standards for the category |
| Enrichment | QVs can correct or enrich attribute values for eligible attributes. Enrichments require seller approval before going live. |
QC Modes:
| Mode | Description |
|---|---|
| Strict QC | Default mode. All guidelines are checked. Used for compliance-sensitive categories. |
| Relaxed QC | Reduced check set for lower-risk categories. Configured at the vertical level. |
| Eventual QC | Product goes live under Relaxed QC initially. Strict QC is triggered once a configurable threshold (e.g., minimum page views) is met. |
| Retro QC | Retrospective re-check of live products when compliance guidelines change. |
| Skip QC | Used for 1P (first-party) flows where speed is prioritised. Product created in a non-discoverable state pending subsequent QC. |
QC task management: Tasks are allocated to QV groups specialised by vertical. Team Leads (TLs) oversee allocation, verify QV work through a Check-the-Checker (CTC) sampling process, and manage overall task throughput. Metrics including pass rate, task TAT, and QV performance are tracked and available for reporting.
5.5 Product Deduplication
The Product Deduplication service checks every incoming Product Creation Request against existing catalog records to prevent duplicate product IDs from being created. It is invoked at two points: pre-QC (on the raw request) and post-QC (on the enriched data).
Status: ✅ Live
Deduplication methods:
| Method | Description |
|---|---|
| Identity attribute matching | Checks ID attributes (brand, model, EAN/GTIN) against existing products |
| Product identifier matching | Uses standardised product identifiers (EAN, GTIN, ISBN, Brand + MPN) for structured product deduplication |
| Image hash matching | Converts images to hashes and compares against existing product images |
| Brand Registry cross-check | For different-brand, different-seller scenarios — only registered, verified brands are matched |
When a duplicate is detected, the seller receives a failure notification with the existing Product ID and the option to latch their listing onto the existing product rather than create a new one. For live products identified as duplicates retrospectively, a merge process migrates orders, fulfillment, and inventory to the primary PID.
6. Storing Layer
Overview
The Storing Layer is the source of truth for all product information on the FCC Catalog platform. Once a product has been validated through ingestion, the Storing layer assigns it a permanent Product ID, maintains all its attribute values and relationships, manages its state, and keeps the Serving layer updated with enriched, aggregated product data.
Status: ✅ Live
6.1 Product MDM (Master Data Management)
The Product MDM is the core of the Storing layer. It comprises three tightly coupled components:
Product Store
The master data store for all product attribute values. It is the source of truth for every PID on the platform.
| Capability | Description |
|---|---|
| Product creation | Generates a unique PID for each validated product |
| CRUD operations | Full create, read, update, delete support for product entities |
| Attribute storage | Stores all vertical-specific and global attributes with strict data type enforcement from vertical definitions |
| Indexing and search | Indexed by vertical-level attributes to support product lookup and duplicate detection |
Product State Service
Manages the lifecycle state of every product. State transitions are governed by configurable business rules based on attribute completeness, image count, and categorization status. Network Admins can override states with reason codes; all overrides are logged and audited.
Aggregator
Maintains a denormalized, aggregated view of each product's data — combining attributes from the Product Store with data from Relationships, Size Chart, Brand, and Rich Media services. The Aggregator is updated whenever any component service changes, and its output is consumed directly by the Serving layer.
6.2 Taxonomy Platform
The Taxonomy Platform manages the hierarchical classification of products across the publisher's platform. Taxonomies can support multiple simultaneous views of the product hierarchy for different downstream purposes.
Status: ✅ Live
| Capability | Description |
|---|---|
| Multi-dimensional taxonomies | Separate taxonomy trees for Browse, Seller, Fulfillment, Analytics, and Taxation — each with different structural requirements |
| Hierarchical depth | Supports up to L5 depth from root category to vertical |
| Bulk taxonomy creation | CSV-based bulk upload for rapid taxonomy onboarding. Eliminates the need for manual, one-by-one ops portal entry. |
| Taxonomy-vertical mapping | Every product's vertical is mapped into the taxonomy. Vertical attributes are defined within the taxonomy context. |
| Taxonomy console | Admin interface for Launch teams to create, edit, and manage taxonomy nodes and vertical mappings |
6.3 Entity Definition Platform
The Entity Definition Platform is where catalog schema is defined and maintained. It powers the vertical-level attribute schemas, validation rules, QC guidelines, and workflows that govern every product on the platform.
Status: ✅ Live
Vertical definition includes:
| Component | Description |
|---|---|
| Attribute schema | Defines every attribute applicable to the vertical: name, data type, allowed values, cardinality (single vs. multi-value), requirement type (ID, Mandatory, Optional, NAFS), and default values |
| Validation rules (Processors) | Configurable rule sets that automatically validate and transform attribute values at ingestion time. Rules are modeled as a directed acyclic graph (DAG) to handle attribute dependencies. |
| QC guidelines | Image and attribute guidelines stored per vertical. Surfaced to QVs during manual QC. |
| Variant and item definitions | Specifies which attributes define variant groups and how products are itemized for browse diversity |
| Workflow configuration | Vertical-level workflow metadata — QC mode, CTC sampling rate, fulfillment strategy, expiry tracking, and return period |
Attribute requirement types:
| Type | Description |
|---|---|
| ID | Identity attributes — uniquely identify a product. Mandatory, seller-provided, non-changeable after creation. |
| Mandatory | Compulsorily filled by the seller. Can be corrected during enrichment. |
| Optional | Good-to-have attributes that aid buyer decision-making. Can be enriched by Ops. |
| NAFS | Not Applicable For Seller — filled systemically through rules, ML models, or manually by Ops teams. |
6.4 Product Relationship Service
The Relationship Service computes and stores all relationships between products and between products and supporting entities (brands, size charts). These relationships power variant swatches, itemized search results, compatibility filtering, and cross-sell surfaces.
Status: ✅ Live
Relationship types:
| Type | Description | Surface |
|---|---|---|
| Variants | Products differing on variant attributes (color, size, storage). Seller-initiated, system-verified. | Product page swatches |
| Itemization | System-generated grouping for browse diversity. Determines how products are displayed in search results. | Search and browse results |
| Compatibility | Inter-vertical relationships — products designed for use with specific other products (e.g., a phone case compatible with a specific phone model). | Discovery and recommendation surfaces |
| Service Association | Links service products (installation, warranty, repair) to applicable parent products. Supports mandatory bundling or standalone purchase. | Checkout and product page |
| Size Chart Association | Associates the correct size chart with applicable products based on vertical, brand, and pivot attributes. | Product page |
| Brand Association | Associates products with verified brands from the Brand Registry. | Product page, search filtering |
Important: Variant grouping is seller-initiated — sellers request grouping and the system verifies validity. Itemization is always system-generated and cannot be controlled by sellers or ops teams.
6.5 Size Chart Service
The Size Chart Service maintains size definitions and associations for all applicable product categories (primarily Fashion and Footwear). It resolves the complexity of varying size interpretations across brands and regions.
Status: ✅ Live
| Capability | Description |
|---|---|
| Default size charts | Provides default size charts based on vertical and applicable gender, sourced through industry research and business alignment |
| Custom size charts | Sellers and ops teams can configure custom size charts at a more granular level, pivoted on product attribute values (e.g., brand, gender) |
| Multi-qualifier support | Handles multiple size naming conventions simultaneously (e.g., UK, US, EU, Brand size) |
| Vertical applicability | Size chart applicability is configured at the vertical level — only relevant verticals prompt size chart association |
6.6 Brand Registry
The Brand Registry is the master record of all brand entities on the platform. It protects brands from abuse, prevents unauthorized use of brand names by third-party sellers, and powers brand-level filtering, discovery, and warranty flows.
Status: 🔜 Coming Soon
| Capability | Description |
|---|---|
| Brand registration | Brands are registered with full metadata: name, logo, synonyms, parent company, applicable verticals, and contact details. Requires trademark verification. |
| Seller authorization (BAL) | Sellers submit a Brand Authorization Letter (BAL) to be approved to sell under a registered brand. Authorization is validated and stored. |
| Brand abuse prevention | Registered brand names cannot be used in non-brand attributes by unauthorized sellers, preventing discovery manipulation. |
| Deduplication | Prevents creation of duplicate brands through text normalization, alternate name matching, and trademark-based deduplication. |
| Brand metadata | Stored brand attributes (logo, introductory text, subsidiary relationships, allowed verticals) power front-end brand pages, brand filter widgets, and warranty constructs. |
6.7 Rich Media Service
The Rich Media Service stores and serves rich content associated with products — buying guides, rich product descriptions (RPDs), editorial images, and video assets. This content is created by catalog ops teams to improve buyer conversion and product understanding.
Status: ✅ Live
| Capability | Description |
|---|---|
| Rich Product Description (RPD) | Text and image content created by Ops teams, served to product pages as structured containers with defined layouts |
| Rich Text Elements (RTE) | Modular content blocks (text widget, media widget, table widget) that can be composed into rich product experiences |
| Template-based publishing | RPD templates define the structure of content containers. Ops teams select a template and fill in content for each product or vertical. |
| State management | Rich media follows a draft → approved → live lifecycle, with versioning and the ability to put content on hold. |
7. Serving Layer
Overview
The Serving Layer (powered by Zulu) is the high-performance interface between FCC Catalog's stored product data and all downstream systems. It aggregates product data from the Storing layer with data from partner systems (pricing, seller information) and serves configurable Views — defined subsets of product information tailored to each consuming system's needs.
Status: ✅ Live
7.1 Configurable Views
A View is a named, configurable projection of product data. Publishers define views for each downstream consumer, specifying exactly which product attributes and relationships to include. This avoids over-fetching and enables lean, purpose-specific API contracts.
Example use cases for views:
| Consumer | Example View | Data Included |
|---|---|---|
| Storefront / Product Page | product_page_view | Title, images, attributes, variants, RPD, brand, size chart |
| Search & Browse | discovery_view | Title, item ID, vertical, categorization, key specs, discoverability flag |
| Fulfillment / OMS | fulfillment_view | Vertical, dimensions, weight, fulfillment strategy, availability |
| Taxation | tax_view | Vertical, HSN code, tax classification |
| Retail Media / Ads | ads_catalog_view | Product ID, brand, category, image link, price band |
7.2 Serving Capabilities
| Capability | Description |
|---|---|
| View definition and management | Publishers define views through a DSL or API contract. Views are stored and versioned. Changes trigger delta computation and downstream notifications. |
| Real-time serving | Views are served at high QPS with low latency from a local cache that is kept current with the Storing layer. |
| Delta computation | When a product is updated, Zulu computes the diff against the previous version. Only changed views are invalidated and recomputed. |
| Multi-consumer support | A single product can be served simultaneously through multiple views to different consuming systems with different data contracts. |
| Snapshot capability | Historical snapshots of serving entities are maintained for audit, A/B testing, and rollback. |
7.3 Integration Gateway (Storing / Integration Gateway)
The Integration Gateway transforms raw product feeds from external sources into the optimized data structures required by the MDM. It handles schema mapping, basic field-level validation, and feed-to-API translation for publishers onboarding from existing ERP or catalog systems.
Status: ✅ Live
8. AI and Intelligence Layer
Overview
FCC Catalog's AI and Intelligence Layer builds on the three core pipeline layers to deliver automated enrichment, quality assurance, and intelligence capabilities powered by large language models (LLMs), GenAI, and FK's proprietary data assets.
All AI capabilities listed in this section are currently in pipeline and will be available to clients on a rolling basis through H2 2026 and H1 2027.
8.1 AI Enrichment of Catalog (Coming Soon)
Status: 🔜 In Pipeline
AI-powered enrichment automatically improves the quality, completeness, and richness of product catalog data — reducing manual ops effort and improving product discoverability.
| Capability | Description |
|---|---|
| Image-to-Video | Generates short product videos from static product images using GenAI. Powered by the Minivet.ai partnership. |
| Auto Attribute Generation | Extracts product attributes directly from images using vision models — reducing the data entry burden on sellers. |
| Contextual Background Enrichment | Replaces or enhances product image backgrounds using GenAI to meet quality standards and improve visual consistency. |
| Image-Based Vertical Identification | Automatically suggests the most appropriate vertical for a product based on image content, reducing misclassification. |
8.2 Automated Product QC (Coming Soon)
Status: 🔜 In Pipeline
LLM and vision model-based automated quality checking replaces or supplements manual QC for high-confidence, high-volume verticals — dramatically reducing TAT for product creation.
| Capability | Description |
|---|---|
| Intelligent image QC | Vision models detect image quality issues, non-compliance, inappropriate content, and guideline violations automatically. |
| Attribute correctness scoring | LLMs assess the accuracy and completeness of text attributes against vertical definitions. |
| Compliance checks | Automated detection of regulatory and policy violations in product data, images, and descriptions. |
8.3 Auto Variant Grouping (Coming Soon)
Status: 🔜 In Pipeline
LLM-based automatic identification and grouping of orphaned SKUs that are actually variants of existing products. Reduces catalog fragmentation and improves the buyer experience on product pages.
| Capability | Description |
|---|---|
| Orphan SKU detection | Identifies products that should be grouped with existing variants but have not been linked by the seller |
| Variant suggestion | Suggests variant groupings to catalog ops for review and approval before applying |
| Attribute-driven grouping | Uses variant attribute definitions from the Entity Definition Platform to validate proposed groupings |
8.4 Conversational Product Creation via MCP Server (Coming Soon)
Status: 🔜 In Pipeline
A conversational interface for product creation using FCC's Model Context Protocol (MCP) Server. Sellers and ops teams can create or update products through natural language dialogue rather than form-based workflows.
| Capability | Description |
|---|---|
| Natural language product creation | Sellers describe a product in plain language; the MCP server extracts attributes, suggests a vertical, and generates a structured PCR |
| Agentic catalog CRUD | AI agents can perform create, read, update, and delete operations on FCC Catalog via structured API tools exposed through the MCP server |
| Catalog Truth API | Exposes confidence-scored, structured product data queryable by AI agents and voice assistants — the foundation for agentic commerce readiness |
8.5 Competitive Intelligence in PIM (Coming Soon)
Status: 🔜 In Pipeline
An integrated intelligence layer that scrapes, matches, and benchmarks competitor product data — enabling catalog owners to identify selection gaps, pricing anomalies, and assortment opportunities directly within the FCC platform.
8.6 Multi-Language Support (Coming Soon)
Status: 🔜 In Pipeline
End-to-end multilingual catalog support — enabling product creation, attribute storage, QC, and serving in multiple languages. Supports both real-time translation (via Google/Azure clients) and a persisted translation store (Rosetta) for high-frequency attribute values.
9. Capability Summary
| Capability | Layer | Status |
|---|---|---|
| Ingestor — Product Creation & Edit | Ingestion | ✅ Live |
| Media Internalizer | Ingestion | ✅ Live |
| Auto Validations (AV) | Ingestion | ✅ Live |
| Manual QC & Enrichment Platform | Ingestion | ✅ Live |
| Product Deduplication | Ingestion | ✅ Live |
| Taxonomy Platform | Storing | ✅ Live |
| Entity Definition Platform (Verticals, Attributes) | Storing | ✅ Live |
| Product MDM (Product Store + State + Aggregator) | Storing | ✅ Live |
| Product Relationship Service | Storing | ✅ Live |
| Size Chart Service | Storing | ✅ Live |
| Rich Media Service | Storing | ✅ Live |
| Integration Gateway | Storing | ✅ Live |
| Serving Layer (Zulu — Configurable Views) | Serving | ✅ Live |
| Brand Registry | Storing | 🔜 Coming Soon |
| AI Enrichment (Image-to-Video, Auto Attributes, BG Enrichment) | AI Layer | 🔜 Coming Soon |
| Automated Product QC | AI Layer | 🔜 Coming Soon |
| Auto Variant Grouping | AI Layer | 🔜 Coming Soon |
| Conversational Product Creation (MCP Server) | AI Layer | 🔜 Coming Soon |
| Competitive Intelligence in PIM | AI Layer | 🔜 Coming Soon |
| Multi-Language Support | AI Layer | 🔜 Coming Soon |
| Agentic Commerce Readiness | AI Layer | 🔜 Coming Soon |
10. Market Context and Strategic Vision
The Opportunity
E-commerce catalog management is a $2.5B market today, growing to $6B by 2030 at 15–18% CAGR. The market is transitioning from static, form-based PIM systems to AI-native catalog intelligence platforms — and the window to lead that transition is open now.
| Market Segment | TAM Today | TAM 2030 | CAGR |
|---|---|---|---|
| Conservative (standalone PIM/DAM buyers, 50K+ SKUs) | $1.2B | $2.8B | 12–15% |
| Realistic (full e-commerce PIM/DAM + enrichment SaaS) | $2.5B | $6B | 15–18% |
| FCC Addressable (SAM — SEA, ME, ANZ, US) | $300–500M | — | — |
| FCC Capturable (SOM — 3-year target) | $30–60M | — | — |
FCC's Right to Win
| Differentiator | Description |
|---|---|
| Built at scale | FCC Catalog was trained on Flipkart's live catalog of 200M+ SKUs — not synthetic data. No PIM startup can replicate this foundation. |
| FK data moat | Enrichment models are grounded in marketplace signals — impressions, clicks, purchases, returns — that no external AI can match. |
| Unified platform | PIM + media enrichment + marketplace intelligence in one platform. Competitors require Akeneo + Bynder dual-stacks; FCC replaces both. |
| Growth market native | Built for SEA, ME, ANZ, Africa market dynamics — multilingual enrichment, complex category schemas, marketplace-first architecture. |
| Faster time-to-value | Enrichment POC visible in 48 hours. No 12-month implementation cycle. Foot-in-the-door model proves ROI before full commitment. |
| MACH-aligned | API-first, headless, multi-tenant. Integrates with any existing commerce stack rather than requiring a full replacement. |
2026 Strategic Pillars
| Pillar | Description |
|---|---|
| Leverage FK Stack | Inherit FK's battle-tested catalog AI — enrichment models, CQS framework, dedup algorithms, GenAI media pipeline. Don't rebuild what FK spent years proving. |
| AI via LLM Outsourcing | Partner with Minivet.ai, FK's internal AI team, and best-in-class 3P LLMs. Speed to market over owning the AI layer. |
| Agentic Commerce Readiness | Build the Catalog Intelligence MCP Server so client catalogs are queryable by AI agents and voice assistants. |
| SaaS Readiness | MACH-compliant, multi-tenant, headless architecture. Sales demo and sandbox environment for faster conversion. |
| US Market Entry | Pipeline includes Thermo Fisher, Healthy Planet, Comoto. MACH-aligned product is the right entry vector. |
| FK Data as Moat | 200M+ FK SKUs + marketplace behavioral signals as training data and enrichment ground truth. |
| GTM: Foot-in-Door vs Full Replacement | Two motions by client type. Greenfield: lightweight enrichment POC. Enterprise: full PIM/DAM replacement with migration playbook. |
11. Go-To-Market Motions
FCC Catalog supports three distinct go-to-market motions, each targeting a different client profile and entry point.
Motion 1 — Foot in the Door (Enrichment POC)
Target: Mid-market brands, D2C brands, smaller marketplaces
ACV: $10K–$80K
Entry: Lightweight enrichment POC — no PIM commitment required. Client uploads a sample catalog, FCC returns enriched attributes, quality scores, and image improvements within 48 hours.
Path: POC → Enrichment subscription → Full PIM/DAM as catalog grows
Motion 2 — Legacy PIM/DAM Replacement
Target: Enterprise retailers and marketplaces on legacy PIM (SAP MDG, IBM PIM) or costly Akeneo + Bynder dual-stacks
ACV: $150K–$600K+
Entry: Full replacement motion with migration playbook and executive sponsor engagement. 6–12 month cycle.
Path: Full PIM/DAM replacement → add enrichment modules → expand to intelligence layer
Motion 3 — FCC Cross-Product Catalog Bundling
Target: Existing and pipeline FCC clients buying Marketplace (Seller Stack), Search, Demand, or OMS products
ACV: $50K–$300K incremental
Entry: Catalog positioned as the quality layer that makes the primary FCC product work better — not a separate pitch. CS-led expansion inside live accounts.
Path: Primary FCC product → catalog as bundled foundation → enrich → upsell full PIM/DAM suite
12. Metrics and Measurement
Catalog Quality Metrics
| Metric | Definition |
|---|---|
| Attribute completeness rate | % of mandatory and optional attributes filled across live products |
| Mandatory field fill rate | % of ID and mandatory attributes present for all live products |
| Image compliance rate | % of products meeting vertical-defined image quality standards |
| QC pass rate | % of PCRs that pass QC on first submission |
| QC TAT (Turnaround Time) | Average time from PCR submission to product reaching Ready state |
| Duplicate detection rate | % of incoming PCRs correctly identified as duplicates |
| Catalog error rate | % of live products with validation failures or data quality issues |
Business Impact Metrics
| Metric | Definition |
|---|---|
| Discoverability uplift | % improvement in search rank or CTR for enriched products vs. non-enriched baseline |
| GMV attribution | GMV uplift on enriched SKUs vs. control (A/B test: enriched vs. non-enriched catalog) |
| Seller NPS on catalog | Net Promoter Score from sellers on catalog creation experience and QC TAT |
| Time-to-live per PCR | End-to-end time from seller submission to product discoverable on the platform |
| Zero-PPV rate | % of live products with zero page views within 60 days of going live — a key catalog quality signal |
AI Enrichment Metrics (applicable when AI layer is live)
| Metric | Definition |
|---|---|
| Enrichment accuracy | % of AI-generated attributes accepted by QC or ops without modification |
| Attribute extraction rate | % of attributes successfully extracted from images vs. requiring manual input |
| AI QC alignment | % agreement between automated QC decisions and human QV decisions |
13. Onboarding Checklist
Overview
Standard FCC Catalog onboarding takes approximately 6 to 10 weeks from contract finalisation to first live products, depending on catalog size, taxonomy complexity, and integration depth.
Phase 1: Taxonomy and Schema Setup
| Task | Owner |
|---|---|
| Define taxonomy structure: browse, seller, fulfillment, and analytics trees | Publisher + FCC |
| Bootstrap initial verticals and attribute schemas from existing catalog data | FCC + Publisher Catalog Ops |
| Configure variant and itemization definitions per vertical | FCC + Publisher Launch Team |
| Define QC modes per vertical (Strict, Relaxed, Eventual) | Publisher + FCC |
| Configure image guidelines and minimum image requirements per vertical | Publisher + FCC |
| Set up brand list and initiate Brand Registry onboarding (Coming Soon) | Publisher + FCC |
| Configure domain whitelist for Media Internalizer | Publisher Engineering + FCC |
Phase 2: Technical Integration
| Task | Owner |
|---|---|
| Integrate Ingestor API for seller product creation and edit flows | Publisher Engineering |
| Set up bulk feed ingestion pipeline (CSV or Azure Blob) | Publisher Engineering |
| Configure Seller Portal with vertical selection, attribute forms, and image upload | Publisher Engineering + FCC |
| Set up Serving Layer view definitions for each downstream consumer (storefront, search, fulfillment, ads) | Publisher Engineering + FCC |
| Integrate Serving Layer API with storefront, search, and OMS systems | Publisher Engineering |
| Validate Auto Validation rules per vertical in staging environment | Publisher Engineering + FCC |
| Test end-to-end PCR flow: submission → AV → QC → Storing → Serving | Publisher Engineering + FCC |
| Configure Product State rules and discoverability conditions | Publisher + FCC |
Phase 3: QC Operations Setup
| Task | Owner |
|---|---|
| Onboard QC vendor groups and define QV roles and access controls | Publisher Catalog Ops + FCC |
| Configure QC task allocation rules (automatic or TL-managed) | Publisher Catalog Ops |
| Define CTC sampling rates per vertical | Publisher Catalog Ops |
| Train QC teams on vertical guidelines and platform UI | Publisher Catalog Ops + FCC |
| Run QC pilot with sample PCRs before full go-live | Publisher Catalog Ops + FCC |
Phase 4: Go Live and Scale
| Task | Owner |
|---|---|
| Launch first verticals with live seller PCRs | Publisher + FCC |
| Monitor QC TAT, AV pass rates, and duplicate detection for first 2 weeks | Publisher Catalog Ops + FCC |
| Review Serving Layer view performance across downstream systems | Publisher Engineering + FCC |
| Establish reporting cadence: weekly catalog health dashboard | Publisher + FCC |
| Plan AI enrichment integration (Coming Soon) | Publisher + FCC |
| Establish SLAs and schedule quarterly business review | Publisher + FCC |
Glossary
| Term | Definition |
|---|---|
| AV | Auto Validation — systematic rule-based checks run on product attribute values and images at multiple points during ingestion |
| Aggregator | Storing layer component that maintains a denormalized, aggregated view of each product's data for consumption by the Serving layer |
| Brand Registry | Master record of all brand entities on the platform. Controls brand registration, seller authorization, and prevents brand abuse. Coming Soon. |
| Camelot | FCC's internal name for the Catalog Storing Orchestrator — the core orchestrator for entity create and edit workflows |
| Catalog | The FCC platform system responsible for owning and managing the complete lifecycle of all product entities on a publisher's marketplace |
| CQS | Catalog Quality Score — a composite score measuring product data quality across image, attribute, and media dimensions |
| CTC | Check the Checker — a QC sampling process where Team Leads verify a percentage of QV-submitted tasks |
| DAM | Digital Asset Management — management of media assets (images, videos, documents) associated with products |
| Entity Definition Platform | The platform component responsible for defining vertical schemas, attribute metadata, validation rules, and QC guidelines |
| FCC | Flipkart Commerce Cloud |
| GTIN | Global Trade Item Number — a standardised product identifier used for brand verification and barcode compliance |
| HITL | Human In The Loop — a quality assurance approach where human reviewers validate or correct AI and system outputs |
| Ingestor | The main orchestrator of the FCC Catalog Ingestion Layer — receives PCRs, coordinates AV, media internalisation, QC, and deduplication, and hands off to Storing |
| Item / Itemization | A system-generated grouping of products for browse and search representation, based on which attributes buyers consider unique during discovery. Cannot be controlled by sellers or ops. |
| Kratos | FCC's multipurpose internal portal for catalog operations — supporting taxonomy management, product state overrides, and admin workflows |
| LID | Listing ID — unique identifier for a specific seller's listing of a product |
| MACH | Microservices, API-First, Cloud-Native SaaS, Headless — the architectural standard FCC Catalog is built on |
| MCP Server | Model Context Protocol Server — FCC's interface for AI agents and conversational interfaces to interact with Catalog data. Coming Soon. |
| MDM | Master Data Management — the Storing Layer component responsible for maintaining the source of truth for all product attribute data |
| Minivet | FCC's GenAI partner for image enrichment capabilities including image-to-video, background enrichment, and AI attribute generation |
| MSN / PID | Makro Serial Number / Product ID — unique identifier for a product on the FCC Catalog platform |
| NAFS | Not Applicable For Seller — attribute type filled systemically through rules, ML models, or Ops teams rather than by sellers |
| PCR | Product Creation Request — the event triggered when a seller submits product information for a new Product ID |
| PIM | Product Information Management — the category of software for managing product data across commerce workflows |
| Processor | A configurable rule unit in the Entity Definition Platform that validates or transforms attribute values. Modeled as a DAG of rule dependencies. |
| QC | Quality Check — the process of verifying that product data is correct, complete, and compliant with vertical guidelines |
| QV | Quality Verifier — a human agent who reviews and approves or rejects product creation requests in the QC platform |
| Rich Media / RPD | Rich Product Description — editorial text, images, and video content associated with a product to improve buyer understanding and conversion |
| SCF | Static Content Framework — manages storage and association of internalized product images with product IDs |
| SaaS | Software as a Service |
| Taxonomy | Hierarchical classification of products across multiple views: Browse, Seller, Fulfillment, Analytics, Taxation |
| Variant Group | A group of products that are varieties of each other (differing on attributes like color, size, storage), displayed as swatches on the product page. Seller-initiated, system-verified. |
| Vertical | The lowest node in the catalog taxonomy. Defines the attribute schema — the set of attributes, allowed values, and validation rules — for all products of that type. |
| View | A named, configurable projection of product data served by the Serving Layer (Zulu) to a specific downstream consumer |
| Zulu | FCC's internal name for the Catalog Serving Layer — the high-performance API that serves configurable product views to all downstream systems |
© 2026 Flipkart Commerce Cloud — Confidential. For Publisher and Partner Use Only.