The Product List View is the primary operational workspace for managing enriched products at scale. It is designed to be fast, low-cognitive, and safe — allowing merchants to control delivery without needing to inspect every underlying tag.

This view appears when selecting Products from the left navigation.

Purpose of the Product List View

The Product List View allows merchants to:

• See the current enrichment and delivery status of all products
  
• Enable or disable delivery per product
  
• Navigate quickly to detailed product records (Gallery View)
  
• Identify products awaiting review
  
• Control visibility without editing content
  
• Manage large catalogs efficiently
  

This view is not intended for deep editing. It is a control and navigation layer.

View Modes (Top Controls)

At the top of the list, merchants can switch between three modes:

• Not Yet Enriched (orange)
  Shows products that exist in the catalog but have not yet been enriched.
  
  
• View All Approved (green)
  Shows products that have been enriched and approved for delivery.
  
  
• Show All (neutral/gray)
  Shows all products regardless of enrichment state.
  
  

The selected mode highlights both the active button and the outline of the list, reinforcing context at a glance.

Review Indicator Badge

In the upper-right corner, a badge indicates whether products require review:

• Blue badge with a number (e.g. “6 Awaiting Review”)
  
  Clicking this sends the merchant directly to the Review page.
  
  
• Green badge showing zero
  
  Indicates no products require review.
  
  

This ensures merchants are always guided back to review before continuing.

Search, Filters, and Columns

Search

The search bar filters products by title in real time.

Filters

Filters allow merchants to:

• Filter by product status
  
• Hide inactive products
  
• Reset all filters easily
  

Columns

The Columns menu allows merchants to show or hide table columns, including:

• Image
  
• Enabled
  
• Title
  
• Language
  
• Status
  
• Approved date (replacing “Synced at”)
  

Column preferences affect display only and do not change product behavior.

Product Rows Explained

Each row represents a single product record.

Image

A thumbnail preview of the product image.

Enabled Toggle

Controls whether CatalogPilot delivers enriched content for that product.

• Green (On): Enriched content is delivered to the storefront.
  
• Orange (Off): Delivery is disabled; the storefront uses the platform’s original data.
  

This toggle allows merchants to disable delivery without deleting content.

Title

The product title for identification and navigation.

Clicking anywhere on the row opens the Product Gallery View (detailed record).

Language

Shows the language variant of the product record.

Status

A green checkmark indicates the product has been enriched and approved.

(Other states appear only before enrichment.)

Approved Date

Shows the most recent approval timestamp.

This replaces the earlier “Synced at” label and reflects merchant-approved state.

Sorting by this column surfaces recently approved products.

Storefront Link

A link icon on the far right opens the live product page on the merchant’s storefront.

Delete (Trash) Icon

A small trash icon appears to the left of each row.

• This removes the product from CatalogPilot’s active records.
  
• If the product remains active in the merchant’s platform, it will be re-imported and queued for enrichment again.
  
  

Deletion here does not remove the product from the storefront platform.

Pagination and List Size

At the bottom of the list:

• Merchants can choose how many products to display per page (e.g. 25, 50, 100).
  
• Pagination controls allow navigation across large result sets.
  

These controls affect display only and do not impact enrichment or delivery.

Design Philosophy

The Product List View is intentionally simple:

• No editing is required here
  
• No irreversible actions occur by default
  
• The focus is on status, control, and navigation
  

Deep inspection and editing happen in the Product Gallery View, which is covered in the next section.

Purpose of the Product Gallery

The Product Gallery is the primary confidence-building view in CatalogPilot.

This is where merchants can clearly see, at a glance, what CatalogPilot has changed, why it changed, and how that data will be interpreted by search engines and AI systems—without being required to edit or approve every individual field.

The Gallery is not a review queue and not a workflow gate.

It is a visual comparison and inspection space designed to reduce cognitive load while increasing trust.

How the Gallery Is Structured

Each product opens into a three-column comparison layout, with a clear distinction between human-facing content and machine-readable content.

Column Meaning

• Left Column — Human Context
  
  
• Represents what a human merchant traditionally recognizes:
  
• Product title
  
• Alternate title
  
• Short (mobile) description
  
• Long description
  
• Primary product imagery
  
• This column reflects the intent of the merchant and the way products were historically managed.

• Center & Right Columns — Machine Interpretation
  
  
• Represent how search engines, crawlers, and AI systems interpret the product.
  
• These columns contain:
  
  
• Structured SEO metadata
  
• ADA image descriptions
  
• Schema-aligned attributes
  
• Category, variant, and image mappings
  
• Subtle iconography (human vs. crawler indicators) visually reinforces this distinction.
  

This separation helps merchants immediately understand:

“What I write for people” vs. “What machines need to understand.”

Original vs. Approved Toggle (A/B Comparison)

At the top of the Gallery, merchants can toggle between:

• Original
  
  
• A composite of:
  
• Platform API data
  
• Existing storefront content
  
• Legacy SEO or app-generated metadata
  
• This represents the starting point before CatalogPilot enrichment.
  
• Approved
  
  
• CatalogPilot’s enriched, validated, and structured output.
  
• This is the version delivered to search engines and AI systems.
  
  

The toggle allows merchants to visually compare before and after states without editing or approving anything.

This comparison is designed to be:

• Fast
  
• Visual
  
• Intuitive
  —not something that requires reading every field.
  

Image & ADA Review

Within the Gallery, image metadata is displayed adjacent to the image itself, including:

• Image Title
  
• Image Alt Text
  
• Image Caption
  

An audio icon allows merchants to hear exactly what a screen reader will read, reinforcing accessibility confidence without requiring ADA expertise.

In most cases, no editing is required.

The system uses high-accuracy visual analysis to describe images consistently and safely.

Navigation & Utilities

The Product Gallery includes several lightweight navigation and utility controls:

• Left / Right Arrows
  
  
• Navigate sequentially through products in the current list or filter.
  
  
• Collapse / Expand Control
  
  
• Collapse the Gallery to return to the tabbed product view.
  
  
• Copy to Clipboard
  
  
• Copy the product title for use elsewhere in CatalogPilot.
  
  
• Direct Storefront Link
  
  
• Open the live product page on the merchant’s storefront in a new tab.
  
  

These tools are intentionally subtle and optional.

Editing Philosophy (Important)

CatalogPilot does not lock content after approval.

Even after a product is approved:

• All fields remain editable
  
• Changes can be made at any time
  
• Updates are version-safe and non-destructive
  

However, merchants are not expected to edit content during the Gallery review.

The recommended flow is:

1. Visually compare Original ↔ Approved
   
2. Confirm overall improvement
   
3. Approve
   
4. Edit later only if desired, from the same Gallery view
   

This ensures momentum without sacrificing control.

What Merchants Should (and Should Not) Do Here

Recommended

• Scan visually
  
• Toggle Original ↔ Approved
  
• Confirm that enrichment is clearly better
  
• Move forward confidently
  

Not Required

• Reading every metadata field
  
• Editing copy line-by-line
  
• Reviewing variants, images, or categories in detail
  

Most extended data (variants, images, categories) inherits safely from approved product logic and does not require manual verification.

The Product tab provides structured, field-level access to core product content.

It is not the primary review interface — that role belongs to the Product Gallery described in Section 4.

Merchants typically arrive at the Product tab only after visually reviewing content in the gallery and deciding whether any targeted adjustments are needed.

5.1 Purpose of the Product Tab

The Product tab exists to:

• Allow precise edits to individual product fields
  
• Support manual overrides when needed
  
• Provide full transparency into enriched vs original values
  
• Preserve merchant control without forcing manual work
  

Most merchants will not need to use this tab frequently.

5.2 Fields Included in the Product Tab

The Product tab contains the following core fields:

• Product Title
  
• Alternate Title
  
• Short (Mobile) Description
  
• Long Description
  
• Platform Identifier (read-only)
  
• Product URL (read-only)
  

These fields represent the foundational product record and are the same fields merchants are most familiar with from their native eCommerce platform.

5.3 Field Status Indicators & Legend

CatalogPilot uses consistent visual indicators across all tabs.

These indicators are explained once and apply universally.

• Green outline
  
  Field is enriched, approved, and actively delivered.
  
  
• Orange eye icon
  
  Merchant has chosen to override enrichment and retain their original platform value for that specific field.
  
  
• Gray eye icon
  
  No override is applied; enriched content is active.
  
  
• Purple UI elements
  
  CatalogPilot system actions and navigation (primary system color).
  

These indicators allow merchants to understand field state at a glance, without reading or comparing text.

5.4 Editing a Field

When a merchant clicks the Edit icon on a field:

• The field becomes editable within a purple outline
  
• The merchant may:
  
• Manually edit the content
  
• Use AI-assisted regeneration (where available)
  
  
• A thumbs-up icon confirms and saves the change
  
• A thumbs-down icon rejects the change
  
• The X icon exits editing and restores the previous value
  

Edits are field-specific and never affect other data.

5.5 Viewing Original Values

Clicking the original-value icon on a field reveals the merchant’s previous platform content.

This allows merchants to:

• Compare enriched vs original text
  
• Restore original values instantly
  
• Lock a specific field to original content while leaving all others enriched
  

Overrides apply only to the selected field.

5.6 AI Regeneration & Diminishing Returns

CatalogPilot allows AI-assisted regeneration for select fields, but merchants should use this feature deliberately.

Important guidance:

• Initial enrichment quality typically falls in the 85–95% range
  
• Re-running AI may:
  
  
• Improve nuance in some cases
  
• Degrade clarity or consistency in others
  
• Repeated regeneration increases the risk of diminishing returns
  
  

Once a worse result is saved, recovery requires manual editing.

Best practice:

Trust the initial enrichment unless there is a clear issue to correct.

5.7 Approval & Post-Approval Editing

Approval does not lock content.

Even after approval:

• All Product tab fields remain editable
  
• Overrides can be applied or removed at any time
  
• Merchants retain permanent access to original values
  

This ensures merchants can move forward quickly without fear of losing control.

5.8 Relationship to the Gallery

The Product tab is not intended for full review.

Recommended workflow:

1. Review content in the Product Gallery
   
2. Approve if the overall result is correct
   
3. Use the Product tab only if a specific field needs adjustment
   

This keeps cognitive load low and workflow efficient.

5.9 Key Takeaway

The Product tab is a precision tool, not a workbench.

• Gallery = trust & confirmation
  
• Product tab = targeted correction
  
• Approval = reversible and safe
  

CatalogPilot is designed so merchants can approve confidently first, and refine later only if necessary.

The Images / ADA tab displays accessibility-optimized metadata generated for each product image. This information is machine-read first and is primarily consumed by screen readers, search engines, and accessibility tools—not by shoppers directly.

What This Tab Represents

For each image, CatalogPilot generates three core accessibility fields:

• Image Title – a concise identifier for the image
  
• Alt Text – a descriptive sentence used by screen readers and accessibility software
  
• Caption – optional contextual description that may be used by assistive technologies and structured data
  

These fields are produced using image-to-content mapping, where CatalogPilot analyzes the image in the context of:

• The parent product
  
• Approved product metadata
  
• Variants and attributes
  
• Category relationships
  

This ensures descriptions are accurate, consistent, and non-generic, even across large catalogs.

Why This Matters

Most platforms either:

• Leave image alt text empty, or
  
• Reuse product titles automatically
  
  

CatalogPilot instead treats each image as its own accessibility record, allowing:

• WCAG-compliant screen reader output
  
• Improved image discovery in search
  
• Cleaner, more reliable structured data for AI and assistive systems
  

This is a major contributor to accessibility compliance and long-term discoverability.

Editing Guidance (Important)

While editing is available, manual changes to Image Alt Text or Captions are generally discouraged unless something is clearly incorrect.

You’ll see a warning indicator when editing these fields because:

• Small wording changes can reduce accessibility quality
  
• Over-specific or stylistic edits may confuse screen readers
  
• Inconsistent edits across images can introduce compliance drift
  

In most cases, the generated content here is already at a high-accuracy baseline and does not benefit from manual rewriting.

When Editing Is Appropriate

You may consider editing only if:

• An image contains a critical visual element that is missing from the description
  
• The generated description is factually incorrect
  
• A compliance review explicitly requires a change
  

If you do edit:

• Changes apply immediately
  
• You can always revert to the previous value using the restore icon
  

Key Takeaway

The Images / ADA tab exists to ensure your catalog is:

• Accessible by default
  
• Consistent across thousands of images
  
• Optimized for machines, not just humans
  

Most merchants will review this tab briefly and move on—confidence here is a feature, not an omission.

The Variants tab appears only when a product includes one or more variants (such as size, color, or fit). Its role is to provide visibility into how CatalogPilot represents variants for discovery, not to encourage routine editing.

Why Variants Are Represented Separately

CatalogPilot intentionally generates independent variant records derived from the parent product.

This is not duplication for duplication’s sake. It is a deliberate structural decision that enables:

• Variant-specific structured data
  
• Attribute-level indexing (size, color, fit, SKU)
  
• Improved discovery for long-tail and filtered searches
  
• Accurate interpretation by AI systems and shopping engines
  

In practice:

• One parent product remains the canonical entity
  
• Each variant becomes a distinct structured Product entity
  
• All variant entities reference the same canonical URL and parent product
  
• No duplicate pages are created
  
• No canonical conflicts are introduced
  

This allows a product with multiple variants to be discovered and indexed through multiple variant-specific entry points, while remaining a single product from a storefront and customer perspective.

Inheritance Model (How Content Is Shared)

CatalogPilot uses a strict inheritance model:

• The parent product is the authoritative source
  
• Variant records inherit all applicable content
  
• Only variant-defining attributes (such as size or color) are appended or overridden
  

This ensures:

• Consistency across variants
  
• No content drift
  
• Predictable schema generation
  
• Clean relationships between parent and variants
  

Because of this model, most variant fields are intentionally read-only or visually muted.

Editing Guidance (Important)

Editing variant content is strongly discouraged.

In most cases:

• Editing variants provides no SEO or discovery benefit
  
• Changes should be made at the parent product level
  
• Variant records automatically update through inheritance
  

Manual variant edits should be considered only if something is clearly incorrect, and even then should be used sparingly.

Pricing & Identifiers

The Pricing and Identifiers sections (GTIN, MPN, SKU, Platform Identifier, URL):

• Are sourced directly from your eCommerce platform
  
• Update dynamically via platform schema
  
• Are shown for reference only
  

Pricing, inventory, and identifiers should always be managed in your storefront platform, not inside CatalogPilot.

CatalogPilot mirrors this data automatically during synchronization.

Why This Matters for Discovery

By representing variants as structured entities:

• Search engines can index size- or color-specific offers
  
• Shopping feeds can match user intent more precisely
  
• AI systems can reason about product availability and attributes accurately
  

This significantly amplifies discoverability without increasing risk, complexity, or merchant workload.

Key Takeaway

The Variants tab exists so you can:

• Confirm variants are recognized and structured correctly
  
• Understand how CatalogPilot expands discovery at the machine level
  
• Trust the system to handle variants safely and consistently
  

Most merchants will review this tab briefly and move on — exactly as intended.

The SEO tab displays and manages all search-engine–focused metadata generated by CatalogPilot for a product. This information is machine-read first, designed primarily for search engines, shopping engines, and AI crawlers rather than human visitors.

Most merchants will review this tab briefly and rarely need to edit it.

What the SEO Tab Controls

The SEO tab includes the following fields:

• Meta Title
  
• Meta Description
  
• Meta Keywords
  
• H1
  
• H2
  
• H3
  
• Source URL
  
• Canonical URL
  
• JSON-LD (Structured Data)
  

Together, these fields define how the product is interpreted, indexed, and ranked by search engines and AI systems.

Visual Indicators & Field States

Each field uses consistent visual indicators across CatalogPilot:

• Green outline
  
  Indicates the approved CatalogPilot version is active and being delivered.
  
  
• Orange eye icon
  
  Indicates the field is currently showing the original platform content instead of the enriched version.
  
  
• Grey eye icon
  
  Indicates the enriched content is in use.
  
  

Merchants can toggle individual fields between Original and Approved without affecting other fields.

Editing & Overrides

All SEO fields support editing, with the same controls used throughout CatalogPilot:

• Edit icon — manually edit the field
  
• Original view icon — view previously imported content
  
• AI regenerate icon — generate an alternate suggestion
  

Important:

CatalogPilot strongly recommends limiting manual edits in the SEO tab.

The system’s initial output is already optimized for correctness, structure, and long-term stability.

Repeated regeneration or aggressive manual editing may reduce quality due to diminishing returns.

Headings (H1, H2, H3)

CatalogPilot generates a hierarchically consistent heading structure:

• H1 — canonical product identifier
  
• H2 / H3 — semantic refinements that support long-tail discovery
  
  

These headings are not purely visual. They are used by crawlers and AI systems to understand product context and relevance.

Canonical & Source URLs

• Source URL reflects the original product page on the merchant’s storefront.
  
• Canonical URL is preserved and never altered by CatalogPilot.
  
  

This ensures:

• No duplicate content risk
  
• No canonical conflicts
  
• Platform ownership remains intact
  

JSON-LD (Structured Data)

The JSON-LD section shows the structured data generated for this product.

This includes:

• Product entity
  
• Variant relationships (when applicable)
  
• Offers, attributes, and availability
  
• Inherited and generated metadata
  

This data is injected at render time and reflects the approved state of the product.

Most merchants will never need to edit JSON-LD directly; it is provided for transparency and technical review.

Key Takeaway

The SEO tab exists to:

• Provide visibility into how search engines and AI systems see the product
  
• Allow safe overrides when necessary
  
• Maintain a stable, non-destructive optimization layer
  

For most merchants, the correct workflow is:

Review → Trust → Approve → Move on

The Attributes tab contains structured, machine-readable product attributes used primarily by search engines, shopping platforms, and automated discovery systems (such as Google Shopping, structured search, and AI-based crawlers).

Unlike the Product tab (which is human-facing) and the Gallery (which provides a comparative overview), the Attributes tab exists to ensure semantic accuracy, classification correctness, and eligibility for external indexing systems.

This tab is not designed for heavy manual editing and should be treated as a verification and exception-handling interface, not a content-creation workspace.

How Attributes Are Generated

Most attribute values are:

• Derived from your existing catalog data
  
• Normalized against known taxonomies (e.g., Google Product taxonomy)
  
• Inferred using deterministic rules based on product type, category, and metadata
  
• Validated to ensure compliance with external indexing requirements
  

CatalogPilot fills as much attribute data as possible automatically to minimize merchant workload and reduce the risk of inconsistent or speculative data.

Understanding Field States and Colors

Attributes use visual cues to communicate confidence and editability:

• Green outline
  
  Indicates a value that has been confidently determined and validated.
  These fields typically do not require merchant intervention.
  
• Yellow outline
  
  Indicates an optional or indeterminate field.
  These values are not required and should only be filled if the merchant has verified, factual information.
  

Merchants are never expected to invent or guess attribute values.

Availability & Condition (Standardized Fields)

Availability and Condition are the only attributes that explicitly follow standardized Google-required formats.

These fields use dropdown selections rather than free text.

Tooltip guidance:

These fields use standardized Google values. Availability and Condition follow Google’s required formats to ensure correct indexing and eligibility in search and shopping results.

If your platform already manages these values correctly, you may leave them unchanged.

Editing Attributes (When to Edit — and When Not To)

Editing is available throughout the Attributes tab, but editing should be the exception, not the norm.

Appropriate reasons to edit include:

• Correcting a clearly incorrect inferred value
  
• Adding verified information that was not available in the source catalog
  
• Aligning with known manufacturer or compliance data
  

Editing is not recommended for:

• Guessing missing values
  
• Over-optimizing for keywords
  
• Adding speculative or marketing language
  
• Forcing completeness where certainty does not exist
  

CatalogPilot prioritizes accuracy over completeness.

Original vs Approved Content

As with other tabs:

• The original-content icon allows you to quickly reference the source value from your platform.
  
• The edit icon enables manual override when needed.
  
• If a field is left untouched, the approved CatalogPilot value remains active.
  

All edits remain reversible and do not permanently overwrite platform data.

Google Product Category & Google Product Type

These fields reflect structured classification paths used by external systems.

They are critical for:

• Shopping feed eligibility
  
• Correct product grouping
  
• AI and crawler understanding
  

CatalogPilot automatically assigns these based on established taxonomies.

Manual changes should only be made if you are certain the default classification is incorrect.

Key Principle

The Attributes tab exists to support machines — not to create extra work for humans.

If a value is green and looks reasonable, leave it.

If a value is yellow and you know the answer with certainty, you may add it.

If you are unsure, it is better to leave the field empty than to guess.

Purpose of the ESG Tab

The ESG tab contains optional, structured fields used to describe environmental impact, ethical considerations, and cultural or social context related to a product.

These fields are machine-readable signals, not marketing claims. They exist to support:

• Search and shopping systems that evaluate sustainability metadata
  
• AI-based discovery engines that factor ethical and environmental signals
  
• Future-facing compliance and classification frameworks
  

Completion of ESG fields is not required for CatalogPilot to function correctly.

How ESG Data Is Used

When populated, ESG data may be used by:

• Search engines and shopping feeds that surface sustainability attributes
  
• AI systems that assess product alignment with ethical or environmental values
  
• External platforms that filter or group products based on ESG criteria
  

If ESG fields are left empty, CatalogPilot continues to operate normally and does not degrade indexing or delivery quality.

Understanding Field States

As with other tabs, ESG fields use visual cues:

• Green outline
  
  Indicates a value that has been confidently inferred or validated.
  
  
• Yellow outline
  
  Indicates optional fields that CatalogPilot has not auto-filled.
  
  

Yellow fields do not represent errors or incomplete setup. They simply indicate that the information is either:

• Not reliably inferable from the source catalog, or
  
• Best provided directly by the merchant if known
  

When to Edit ESG Fields

You should edit ESG fields only if the information is factual and verifiable.

Appropriate examples include:

• Known sustainability certifications
  
• Confirmed ethical sourcing practices
  
• Verified packaging disclosures
  
• Age-group or fit classifications that are explicit
  

You should not edit ESG fields to:

• Guess or assume sustainability claims
  
• Add aspirational or marketing language
  
• Fill fields “for completeness” without certainty
  

CatalogPilot intentionally avoids inventing ESG data.

Key ESG Fields Explained

Common ESG fields include:

• Age Group / Minimum Age
  
  Used for classification and compliance contexts.
  
  
• Fit Classification
  
  Helps AI and search systems understand sizing and wear context.
  
  
• Ethical Sourcing
  
  Intended only for confirmed sourcing practices.
  
  
• Packaging Disclosure
  
  Used to describe known packaging materials or environmental impact.
  
  
• Cultural Fit Tag
  
  A high-level contextual signal (e.g., European-inspired), used for discovery—not ranking manipulation.
  
  

Editing & Original Content Reference

All standard CatalogPilot editing controls apply:

• Edit icons allow manual updates
  
• Original-content icons allow quick reference to source data
  
• Changes remain reversible
  
• Platform data is never overwritten
  
  

As with all tabs, edits affect CatalogPilot’s enriched layer, not the merchant’s underlying platform records.

Important Principle

ESG data is additive, not foundational.

CatalogPilot’s core value comes from structured accuracy, accessibility, and semantic clarity. ESG metadata enhances discovery but is never required for successful enrichment or delivery.

If you are unsure about a value, it is better to leave the field empty.

Purpose of the Social Tab

The Social tab contains structured metadata used when products are shared on external social platforms such as:

• Facebook
  
• LinkedIn
  
• TikTok
  
• X (Twitter)
  

These fields control how a product is presented when a link is shared, not how it ranks in search results.

Social metadata is machine-consumed by social platforms and preview engines. It is not intended for day-to-day human editing.

What Data Is Managed Here

The Social tab includes two primary metadata groups:

OpenGraph (OG)

Used by most modern social platforms:

• OpenGraph Title
  
• OpenGraph Description
  

These values determine the headline and summary shown in link previews.

Twitter (X)

Used specifically by Twitter/X preview cards:

• Twitter Title
  
• Twitter Description
  

These are optimized for shorter character limits and feed-style consumption.

Image URLs and preview images are managed automatically by CatalogPilot and are not exposed here by default to reduce complexity.

Editing Guidance

CatalogPilot generates social metadata using the same validated enrichment pipeline as SEO and product content.

Merchants should:

• Review at a glance
  
• Make edits only if branding tone requires adjustment
  
• Avoid frequent re-generation or experimentation
  

As with other tabs:

• Green outline indicates approved content
  
• Edit and original-reference icons function consistently
  
• All changes remain reversible
  

Why Image Fields Are Not Shown

Although social platforms support image previews, CatalogPilot intentionally manages image selection automatically to ensure:

• Correct image-to-product mapping
  
• Platform-specific sizing and format compliance
  
• Consistent preview behavior across platforms
  

When to Edit Social Fields

Editing may be appropriate when:

• A merchant wants tighter brand voice for social sharing
  
• Product naming conventions differ from SEO naming
  
• Promotional tone needs slight adjustment
  

Editing is not required for CatalogPilot to function correctly.

Key Principle

Social metadata is for presentation, not discovery.

CatalogPilot optimizes social previews to be accurate, clean, and platform-compatible without requiring ongoing merchant involvement.

Most merchants will never need to interact with this tab.

Purpose of the Legal / PCI Tab

The Legal / PCI tab attaches verified legal, compliance, and provenance information to each product record.

This information is machine-consumed first, but also provides a transparent compliance layer for regulators, marketplaces, and automated trust systems.

Unlike SEO or Social metadata, this tab establishes accountability and provenance, not marketing or discoverability.

What This Tab Provides

The Legal / PCI tab combines two distinct categories of information:

1. Product-Specific Compliance Fields

These fields may vary by product and are generated or populated when applicable:

• Compliance Notes
  
  (e.g., care instructions, material handling, safety notes)
  
  
• Warnings
  
  (e.g., choking hazards, material sensitivities, regulatory disclosures)
  
  
• Country Restrictions
  
  (e.g., shipping limitations, export controls)
  
  
• Adult Considerations
  
  (e.g., age-restricted products, suitability indicators)
  
  

These fields are deterministic and should only be edited if the merchant has factual, product-specific information to add.

Yellow-outlined fields indicate optional inputs — they are not required for CatalogPilot to function correctly.

2. Merchant & Policy Provenance (Applied to Every Product)

The following fields attach merchant identity and policy references to each product record:

• About Us (link)
  
• Terms & Conditions (link)
  
• Return Policy (link)
  
• Privacy Policy (link)
  
• Merchant Name
  
• Merchant Address
  
• Merchant Logo
  

These values are inherited from the merchant’s configuration and remain consistent across all products.

They are included intentionally to ensure:

• Clear merchant attribution
  
• Policy traceability
  
• Marketplace and crawler trust validation
  
• Regulatory alignment
  

Editing Guidance

Merchants may edit product-specific compliance fields only when information is known and verifiable.

CatalogPilot does not encourage speculative or inferred content in this tab.

Key guidance:

• Do not invent warnings or restrictions
  
• Do not duplicate policy text into product fields
  
• Do not override merchant-level policy links unless they are incorrect
  

The goal is accuracy and traceability, not completeness.

Why This Matters

Modern platforms, marketplaces, and AI systems increasingly evaluate:

• Who sells the product
  
• Under what legal terms
  
• With what compliance disclosures
  
• From which jurisdiction
  

By attaching this information at the product level, CatalogPilot ensures each product can stand independently when evaluated by automated systems.

Key Principle

Legal / PCI metadata is about trust, not optimization.

Most merchants will rarely interact with this tab.

When they do, edits should be deliberate, factual, and minimal.

Purpose of the AI Tab

The AI tab provides structured, machine-oriented signals designed to support future AI discovery, interpretation, and retrieval systems.

This tab is not intended to drive immediate SEO or human-facing content.

Its role is to anchor product meaning, context, and differentiation for advanced AI agents and large-language-model–driven systems.

Think of this tab as forward-looking semantic infrastructure.

What the AI Tab Contains

The AI tab includes the following fields:

LLM Summary

A concise, factual narrative describing the product as a complete entity.

• Generated to be stable, neutral, and non-promotional
  
• Designed for AI systems that require full-context understanding
  
• Locked by default to prevent drift
  

Merchants are not expected to edit this field.

Differentiator

A short statement identifying what meaningfully distinguishes the product.

• Focuses on structural or material differences, not marketing claims
  
• Used by AI systems to separate near-identical products
  
• Locked by default to preserve consistency
  

Target Audience

Describes who the product is intended for, in neutral, demographic terms.

• Editable if the merchant has accurate knowledge
  
• Should remain factual (avoid aspirational language)
  

Shopping Style

A high-level classification (e.g., Essentials, Luxury, Gifting).

• Used for AI categorization and clustering
  
• Editable, but should remain conservative
  

Product Personality

A distilled tonal descriptor (e.g., Essential, Sophisticated, Playful).

• Helps AI systems understand positioning
  
• Not customer-facing
  
• Editable, but should not be over-tuned
  

LLM Ignore

An instruction field used to explicitly exclude volatile or transactional data from AI indexing.

Examples include:

• Price
  
• Availability
  
• Promotions
  
• Inventory states
  

This field helps prevent AI systems from anchoring to data that changes frequently or is context-dependent.

Editing Guidance

Most AI fields are locked intentionally.

This is by design.

CatalogPilot generates these values using a controlled, multi-pass enrichment process to minimize:

• Hallucination
  
• Semantic drift
  
• Over-optimization
  

Merchants may edit Target Audience, Shopping Style, and Product Personality if they have clear, factual intent.

Repeated AI regeneration is discouraged due to diminishing returns — later generations are more likely to degrade clarity rather than improve it.

Why This Tab Matters

Search and discovery are shifting away from keyword matching toward:

• Entity understanding
  
• Semantic context
  
• Cross-catalog inference
  

The AI tab prepares products for:

• AI shopping assistants
  
• Conversational commerce
  
• Knowledge graph ingestion
  
• Multi-modal discovery systems
  

While these systems are still emerging, the data generated here ensures products are future-ready without requiring future rework.

Key Principle

The AI tab is not for optimization — it is for grounding.

Merchants should treat this tab as infrastructure, not a tuning surface.

Most will never need to interact with it — and that’s the correct behavior.

Below both Product and Category views, CatalogPilot provides two operational tabs:

• Activity
  
• Errors
  

These tabs exist to provide traceability, transparency, and confidence without increasing cognitive load during normal use.

They are designed to be informational, not something merchants need to actively manage day-to-day.

Activity Tab

The Activity tab records a chronological log of meaningful actions performed on a product or category within CatalogPilot.

This includes:

• Enrichment events
  
• Approval actions
  
• Manual edits
  
• AI-assisted generations
  
• System-initiated updates tied to enrichment workflows
  

Each entry includes:

• Activity Type (e.g. Enriched, Approved)
  
• Description of the action
  
• Created By (user or system)
  
• Timestamp
  
• Amount, when the action resulted in a billable enrichment
  

Not every action inside CatalogPilot is billable.

Only enrichment-related operations will appear with a value in the Amount column.

This allows merchants to:

• Understand what happened
  
• See when it happened
  
• Confirm why a charge occurred, if applicable
  

The Activity log is append-only and cannot be edited or altered.

Errors Tab

The Errors tab displays any issues encountered during enrichment, delivery, or synchronization.

Important characteristics of the Errors tab:

• CatalogPilot automatically retries transient errors
  
• Many errors resolve without merchant involvement
  
• Errors are shown only when they persist or require attention
  

If an error appears:

• CatalogPilot support may already be investigating it
  
• Merchants are encouraged to contact support if the error remains visible or unclear
  

Errors are presented for visibility, not blame.

The system is designed to fail safely and recover automatically wherever possible.

Design Philosophy

The Activity and Errors tabs are intentionally quiet:

• No alerts unless necessary
  
• No manual remediation required in most cases
  
• No interruption to approval or enrichment workflows
  

They exist to reinforce trust, accountability, and auditability — especially for enterprise and compliance-minded merchants.

Key Takeaway

Most merchants will rarely need to interact with these tabs.

They are there when needed, invisible when not.

CatalogPilot handles retries, recovery, and escalation automatically — while keeping a clear record of everything that matters.