What a PIM Does Not Do

In almost every technical evaluation, someone asks a version of the same question. We already own a product information management platform. Why would we need anything else. It is the right question, and most answers to it are wrong, because they claim a PIM cannot do things it can. Modern platforms generate missing values, enforce rules per category, handle units and controlled vocabularies, and talk to marketplaces in both directions. The capability is there.

What follows is four places where having the capability is not the same as having the outcome. Not four things a PIM cannot do. Four things a PIM requires you to do.

What a PIM is built to do, and does well

It is worth being specific about this, because the argument that follows depends on taking it seriously.

A PIM is a system of record for product information. Its core job is to hold one authoritative version of a product, model the relationships around it, and control who may change what. The data model is the heart of the thing: product families, variants, hierarchies, localized values, relationships between items, and the association of assets with records. Building that model correctly is genuinely difficult, and mature platforms have spent many years getting it right.

Around the model sits governance. Role-based permissions decide who can edit which attribute. Workflow routes a record through refinement, review, and approval. Versioning records who changed a value and when, and allows a change to be reversed. For an organization with merchandisers, translators, and channel managers touching the same records, this is not administrative overhead. It is the only thing preventing the catalog from becoming a shared document that everyone overwrites.

Then there is syndication. A PIM takes the values it holds, formats them according to the template configured for each destination, and moves them to marketplaces, retailer portals, storefronts, and downstream systems on a schedule. It tracks what went where and reports what came back rejected.

Model, govern, version, syndicate. A platform that does those four things reliably across a large catalog is valuable, and nothing here argues otherwise.

The first: a PIM will generate values. It will not know which values are right.

This one has changed, and anyone still arguing it has not looked at a modern PIM. Generative field completion ships in the major platforms now, wired into the workflow so a generated value routes through review and approval like any other edit. The volume problem that used to define this work is largely solved. A merchandiser looking at a 38 percent completeness gap is no longer looking at months of typing.

What the plugin supplies is fluency. A model asked to fill a wood finish field returns something that reads like a wood finish, every time, for every record, and it never returns a blank. Whether the value is correct is not decided by the model. It is decided by the rule that governs that attribute in that category, and by whether anything checks the output against it.

So the generation question is not whether the platform can. It is what the generated value is checked against, and who wrote that check.

The second: the rules exist. Somebody has to write them.

PIM platforms support per-category validation properly. Enumerated value lists, unit-of-measure handling, required-field and completeness rules scoped to a category rather than to the whole catalog. A wood finish field restricted to walnut, oak, mahogany, and teak will reject “brown.” A conduit length configured in feet will catch a value entered in millimeters. The mechanism is there and it works.

The mechanism is not the constraint. Authoring is the constraint.

Every one of those rules is written by a person. Somebody decides which attributes a category requires, what the allowable values are, which unit convention governs, and how variants may differ. That work is precise, it is slow, and it is specific to the category. Doing it for twenty categories is a project with an end date. Doing it for four hundred is a permanent staffing commitment, because the rulebook for office furniture shares almost nothing with the rulebook for writing instruments, which shares almost nothing with the rulebook for air handlers.

So the rules get written for the categories that hurt most, and the rest of the catalog runs on a generic schema that checks types and required fields and little else. The validation is not absent. It is uneven, and it is uneven in proportion to how much configuration effort each category ever received. Ask a team running a large catalog which categories have real rules behind them and the answer is a short list rather than a complete one.

The rules also decay. They encode what somebody understood about a category on the day they wrote them, and they do not notice when a marketplace changes its requirements or a new variant dimension becomes standard. Nobody owns four hundred rulebooks. People own the twelve they built, and measuring data quality honestly means knowing which twelve.

The third: a PIM executes mappings. It does not build them.

Here the argument leaves the territory people expect it to occupy, because this one happens at the far end of the pipeline rather than the near end.

A PIM syndicates, and syndication runs on templates. Each destination gets a template that says which internal attribute answers which required field, how values are transformed on the way, which units are converted, and how a controlled vocabulary on our side translates into the controlled vocabulary on theirs.

Somebody had to build that template. They read the destination’s specification, made a long series of judgments about which of our attributes answers which of their fields, defined the transformations, handled the unit conversions, reconciled the two vocabularies, tested it against a sample, and then owned it. That work is the mapping. The platform executes mappings. It does not produce them.

For a business selling into four or five destinations this is a manageable project, tedious rather than hard. For a brand selling across hundreds of retailer templates, each with its own required fields, its own vocabularies, its own units, and its own idea of what a color is, the configuration burden stops being a project and becomes the permanent job. Our European team hears this constantly from brands who are explicit about it: the problem is not storing product data, it is that there are hundreds of templates and no way to map to them by hand.

The reason this is intelligence work rather than transport is that a mapping decision is a judgment made against two schemas and the rules of a category simultaneously. Deciding that our “sleeve length” answers their “sleeve” field, in centimeters rather than inches, with our value “three quarter” rendered as their value “3/4 sleeve,” requires knowing what the attribute means in this category, not merely what it is called. That is the same kind of judgment as the validation work, applied at the other end of the pipe.

The fourth: noticing is not the same as acting.

Destinations change their requirements. A retailer adds a required attribute, renames a field, tightens a controlled vocabulary, changes a unit convention, or splits one attribute into two. Each does this on its own schedule, and none of them sends a note.

This one is platform dependent, and the better platforms do more than they get credit for. Where a PIM holds an API connection to a retailer or marketplace, that connection usually runs both ways. Schema can be pulled back as well as data pushed out, which means the platform can know that a destination’s requirements have changed and can surface it.

Detection is the easier half. What does not follow is the remediation. Knowing that a retailer added a required attribute, split one field into two, or tightened a controlled vocabulary does not populate the new attribute across forty thousand affected records, decide how the old value maps onto the new one, or backfill the history. That is a re-mapping problem and a generation problem arriving together, at volume, against a deadline somebody else set.

So the failure is narrower than it first appears and it lands in a more frustrating place. The alert fires. The work the alert implies is manual, and it is the same per-category judgment as everything above. atronous closes the second half: when a destination’s schema moves, the affected attributes are re-mapped and regenerated against the new requirement rather than queued for somebody to work through.

Four requirements, one architecture

The interesting question is not what a PIM lacks, because on this evidence it lacks very little. It is why all four of these land on a person, because that is not a coincidence and it is not an oversight.

A PIM is SaaS workflow software. That is a description of a design philosophy rather than a criticism, and it is the right philosophy for a system of record. Workflow software presents the right task to the right person at the right moment, records what they decided, enforces that steps happen in order, and keeps an account of it afterward. In that architecture the intelligence at every step is the human occupying it. The software is the choreography around the judgment, not the judgment.

Read the four again with that in mind and none of them is a gap. Every one is the architecture behaving exactly as designed. It generates a value and routes it to a person, because deciding whether the value is right is the human’s step. It enforces the category rules a person authored, because authoring them is the human’s step. It executes a mapping a person built. It raises an alert that a person then acts on. Nothing is missing. The architecture assumes throughout that a person supplies the judgment, and it is excellent at everything that surrounds that assumption.

Which gives the cleanest statement of the difference: their model is done by you, ours is done for you.

That is not a feature comparison and it does not resolve into one. It is a question of where the judgment lives. A done-by-you system scales with headcount, because every additional category, every additional template, and every additional channel adds human steps, and the steps do not get cheaper as they multiply. A system built to supply the judgment itself has different arithmetic, and the difference compounds in exactly the conditions that describe a large modern catalog: many categories, many destinations, and requirements that will not hold still.

Not upstream. The layer in between

It is tempting to describe all of this as sitting upstream of the PIM, and that description is too small. Upstream implies a stage: data gets prepared, then handed over, then the system of record takes it from there. Some of the work does behave that way. Generation and category validation happen before delivery.

Mapping into a destination’s schema does not. Responding when that schema changes does not. Both happen at the far end, after the system of record has done everything it does. A framing that puts atronous at one end of a line cannot describe a capability that operates at both.

The accurate description is that atronous is the intelligence layer PIMs are missing. Not a stage before them. The judgment their architecture assumes a person will bring, supplied instead by something built to supply it, at several points in the same pipeline, including points on the far side of the system of record from where a preparation stage would sit.

Concretely, it starts before a PIM has anything to manage. It means ingesting from the formats product information actually arrives in, which is spec sheets, manuals, images, drawings, CAD files, and vendor spreadsheets rather than a clean feed. It means normalizing what comes back so that eleven vendors describing the same attribute eleven different ways resolve to one value. And it means rationalizing a single coherent catalog out of many vendor and seller files that were never built to agree with each other. That is more than adding content, because a generated value is a candidate rather than an answer.

From there it is deterministic logic validating every candidate against the rules of the category the record belongs to, after it has been classified into the right category, across a constraint layer covering more than 400 categories. Each category carries its own vocabulary, unit conventions, allowable variant dimensions, and identifier rules, each enforced independently so a rule correct for one cannot contaminate another. The difference from a configured rulebook is that nobody has to author four hundred of them.

At the far end it means generating the mappings into destination schemas rather than waiting for someone to configure them, and watching those destinations so a changed requirement is re-mapped and regenerated rather than queued for a person to work through.

None of which makes us a system of record, and we are not becoming one. The PIM continues to model, govern, version, and syndicate, which is what it is good at. What changes is that the judgment those four functions assume a person will supply is supplied by something built for the job.

The principle underneath is unchanged: a validated subset with documented exceptions beats a complete file with hidden errors. Ten thousand verified records and a flagged remainder is a good outcome. Thirteen thousand records with an unknown error rate is a problem that surfaces after go-live.

Why this matters more now

For as long as the reader of a product record was a person, an unconfigured category was survivable. A merchandiser who knows the category reads a thin or inconsistent record, recognizes what happened, and works around it. Tolerance for ambiguity was built into every part of the process, because people supplied it at every step, which is the same assumption the workflow architecture makes.

As AI agents take on more of how products are found, compared, and recommended, that tolerance disappears at the other end too. An agent reads the structured values it is given and computes on them. It cannot tell a value that satisfied a schema from a value that satisfied the rules of its category, and it has no way to route around the difference. A record that is complete and wrong is worse in that setting than one that is visibly incomplete, because incompleteness at least announces itself.

The symmetry is worth noticing. The done-by-you architecture assumed a person would supply judgment during production. The channels it delivers to assumed a person would supply interpretation during consumption. Both assumptions are being withdrawn at the same time, and for the same reason.

See the difference measured on your own records

The quickest way to see how far apart populated and correct sit in your own catalog is to have a sample measured. That is what the atronous Data Quality Assessment does. Send up to 50 SKUs out of your PIM or ERP, exactly as they live in your system, and we run them through the same pipeline our enterprise customers rely on. Within five business days you receive the sample back, generated and validated, along with the taxonomy and schema recommendations behind the work and a working session to walk through what we found.

No pitch. Your own records, measured against the rules of their categories.

Request your Data Quality Assessment.

Intelligence in every attribute.