Where content actually lives — the Seller & Vendor Central map.

Before we open a single field, it pays to name the surfaces. Amazon listing content does not live in one place. It lives across five distinct editing surfaces, each with its own UI, its own validation rules, its own permission model, and — most importantly — its own position in the override hierarchy that decides which surface wins when two of them write conflicting values to the same field. Most "my edit didn't stick" tickets are not bugs in Amazon's system. They are a misunderstanding of which surface owns which field on that ASIN.

The five surfaces

• Seller Central. The third-party seller's UI. Owns almost all attribute fields (title, bullets, description, dimensions, materials, certifications), all FBA/MFN fulfilment configuration, all pricing and inventory, all promotion settings. Edits go live within minutes when accepted. Accessed at sellercentral.amazon.[tld] per marketplace region.
• Vendor Central. The first-party vendor's UI for selling wholesale to Amazon Retail. Owns cost prices, purchase orders, chargebacks, shortage claims, and a subset of attribute fields where the Vendor is the source of truth (cost, packaging weight, MSRP). Most content fields can be edited in Vendor Central, but they often lose the override battle to Brand Registry edits. Accessed at vendorcentral.amazon.[tld].
• Brand Registry & Manage Your Brand Content. The brand owner's UI, available once Brand Registry enrolment is complete. Owns title, bullets, images, A+ Content, Brand Story, the brand wordmark, the brand-protection tools (Project Zero, Transparency, Report a Violation). The override hierarchy is structured around this surface: a Brand Registry edit by the brand owner beats Seller Central and Vendor Central edits on the contested attribute fields. Accessed at brandservices.amazon.[tld].
• A+ Content Manager. A sub-surface of Brand Registry dedicated entirely to A+ Content and A+ Premium modules. Owns the A+ document library, the ASIN-to-document mapping, and the moderation submission queue. Lives at Seller Central → Advertising → A+ Content Manager for Sellers, and at Vendor Central → Merchandising → A+ Content for Vendors. Same underlying data store, different UI shell.
• Flat-file pipeline. The bulk CSV/Excel/TSV upload route that hits the same underlying attribute store as the UIs, but with different validation paths and significantly higher destructive potential. Includes both manual flat-file uploads (Seller Central → Catalog → Add Products via Upload) and SP-API automated feeds. Edits via this surface inherit the ownership and override rules of the surface they map to — a flat-file uploaded by a Seller account behaves as a Seller edit; a flat-file uploaded against a Brand Registry-locked field behaves as a Brand Registry edit.

The override rules nobody documents cleanly

Amazon does not publish a single source-of-truth document explaining which surface beats which under which condition. The rules below are observed behaviour across thousands of audited listings:

• Brand Registry beats Seller and Vendor on contested attribute fields. Once a brand owner edits title, bullets, or images through Brand Registry, subsequent Seller or Vendor edits to the same fields are silently reverted on the next catalogue refresh — typically within hours, sometimes within minutes.
• Vendor beats Seller in Vendor-controlled categories. When Amazon Retail is the seller of record (Vendor relationship), the Vendor Central data takes precedence over any third-party Seller edits on the same ASIN.
• Most-recent-edit wins among peer surfaces. Two Seller Central edits to the same field — last one in wins. Two flat-file uploads — last one in wins. This is also why an automated SP-API feed firing every six hours will silently overwrite the manual fix a human applied at 09:00.
• Style Guides override all of the above on character-level violations. The category Style Guide validator runs after the surface-level write and can silently strip characters, truncate fields, or rewrite capitalisation regardless of which surface produced the value. Most "Amazon changed my title" reports trace back to a Style Guide validator catching a violation, not to a competing edit.
• Catalogue contributors with higher trust scores beat lower-trust contributors. Within Brand Registry → Manage Contributors, Amazon assigns each contributor a trust score based on edit history and account age. A higher-trust contributor's edit can override a lower-trust one on the same field — which is how an outsourced agency with a fresh account can find its work overridden by a long-tenured competitor agency on the same ASIN.

The override map in one diagram

Read top-to-bottom; each row beats every row below it on the listed fields:

1. Style Guide validator — character-level rewrites on every field it touches.
2. Brand Registry (highest-trust contributor) — title, bullets, main image, A+ Content, Brand Story.
3. Vendor Central — in Vendor-controlled categories, on attribute fields not locked by Brand Registry.
4. Seller Central — all attribute fields not claimed above, all offer-level fields.
5. Flat-file / SP-API feeds — inherit the owning surface's rank; last-write-wins among peers.

Why most "missing edit" tickets are mis-diagnosed

When a brand team reports that "my edit isn't showing up", the diagnosis is almost never an Amazon bug. The actual cause is one of five recurring patterns:

• The edit was made on a surface lower in the override order than the surface that owns the field. A Seller Central edit to a bullet that Brand Registry owns will silently lose every time.
• An automated feed (SP-API integration, repricer, BIL sync) fires periodically and overwrites the manual edit on its next run.
• The Style Guide validator caught a violation and rewrote or stripped the field after the surface accepted the input.
• Another contributor with a higher trust score on the brand re-asserted a different value.
• The edit landed on a child ASIN but the user is checking the parent (or vice versa) — variation families have a separate attribute pipeline per child.

The defence is to always know which surface owns the field you're editing before you edit it, to audit the SP-API feeds your account has authorised, and to lock down contributors in Brand Registry → Manage Contributors so that random catalogue contributors cannot overwrite your work.

What this module assumes from here on

From this episode onward, every Module 4 episode names the surface it operates on. If a workflow involves two surfaces simultaneously (for example, a flat-file upload that also requires a Brand Registry image override), we name both surfaces explicitly and call out the order of operations. The mental model — surface, ownership, override — is the thread that runs through everything that follows.

What to take into the next episode

The next episode opens with the Seller Central account itself — the entry surface most catalogues actually start on. Account type, marketplace region, sub-user roles, and the day-one decisions that quietly shape every later workflow.