Connect your PIM, import a CSV slice, or paste a source list. Central discovers missing attributes, verifies values across multiple sources, attaches confidence per field, and writes back under governance rules you control — your taxonomy, your authority, your audit trail.
A governed PIM stores the value. It doesn't tell you where the value came from, whether two sources agree, or which attributes are still blank because no source has ever supported them.
Central reads the PIM, runs verification across 15+ external sources, and returns an evidence layer per field: governed by PIM, multi-verified by Central, held because no source agrees, in conflict with the PIM. Nothing overwrites the governed value unless your write-back policy says so.
AI discovers and verifies. Governance decides what flows back into the PIM. Three visible steps from connector to a write-back event your data team can audit.
Akeneo, Pimcore, Salsify, inRiver, contentserv, or a custom REST source — Central reads governed records, maps your attribute taxonomy to the canonical schema, and never writes until policy allows it.
Central scans 15+ external sources per SKU — brand spec, retailers, regulatory registries, manufacturer documents — and surfaces missing attributes with candidate values and source agreement.
Write-back is gated by policy: approval required, conflict resolution, audit trail. Sources, confidence, agreement count, and steward decision attach to every change. Nothing silent.
PIM diff, evidence per field, held-claim policy, write-back governance, audit trail, custom-field discovery, taxonomy mapping, and a provenance API — every change has a source, a score, and a steward.
// response · field with full provenance { "field": "power_w", "value": 950, "unit": "W", "confidence": 0.96, "agreement_count": 4, "verdict": "verified", "pim_value": null, "sources": [ { "name": "smeg.com", "weight": 1.00 }, { "name": "mediamarkt.de", "weight": 0.92 }, { "name": "coolblue.nl", "weight": 0.88 }, { "name": "amazon.de", "weight": 0.84 } ], "writeback": { "target": "akeneo-prod", "steward": "j.fischer", "at": "2026-05-25T11:42:18Z" } }
The same Central system that discovers and verifies the evidence also adapts the canonical record into every channel — without the PIM having to re-shape data for each surface.
Gathers across 15+ external sources per SKU, scores confidence, surfaces conflicts against the PIM, and keeps unsupported claims out of write-back. Every fact carries a source and a score.
Turns the PIM-plus-evidence record into Google Merchant fields, custom feeds, page copy, Schema.org / JSON-LD, and AI-readable outputs — without re-keying or shaping inside the PIM.
FAQ, Smart Negatives, buyer answers — one script tag and the widget renders only from verified or governed data. Held claims never appear on the page.
The same product — sparse on the left, complete on the right. The governed PIM data is preserved. Central fills the gaps with verified evidence, holds what it can't prove, and writes back only what policy allows.
Central reads through OAuth or API key, maps the taxonomy once, and writes back only under the policy your data team defined. The evidence ledger is queryable per SKU, per field, per steward.
No. Central sits around the PIM as a discovery, verification, and write-back layer. The PIM remains the governed system of record. Central adds an evidence layer per field, fills gaps under a write-back policy you set, and never overwrites governed data without approval.
Only if your write-back policy says so. The default is PIM wins · Central fills gaps — existing PIM values stay authoritative, and Central writes back only to blank attributes that meet the confidence floor. Per-attribute overrides let you mark fields as "PIM-only" or "held".
Akeneo and Pimcore are available now via REST and OAuth/API-key. Salsify and inRiver connectors are coming, and contentserv is supported on request. A generic REST and CSV connector covers custom PIMs. The taxonomy maps once per connector; subsequent syncs preserve your codes and category tree.
Every event — write, approve, hold, run, revert — is logged with the field, the source list, the confidence, the agreement count, and the previous PIM value. The log is queryable per SKU, per attribute, per steward, and per batch. It's available via the REST evidence API.
The PIM taxonomy stays canonical. Central maps once to your attribute codes, your category tree, your unit conventions, your reference data. External sources are translated before they appear in the evidence layer — no foreign labels reach the PIM.
Central respects variant inheritance from the PIM. Base-product fields inherit by default; variant-specific values can be enriched and written back per variant. The matrix view shows which cells are inherited, which are variant-specific, and which have evidence behind them.
They stay held. Held claims are visible in Central — so your team knows the gap exists — but they never reach the PIM, the feeds, or the product page. If a brand or merchant source later confirms the claim, the steward can promote it.
Yes. The REST evidence API exposes per-field source list, confidence, agreement count, and decision history at /api/v1/products/{id}/evidence. The same record powers Channel Studio outputs, JSON-LD with x-central metadata, and the product widget — every surface can show provenance.