Data validation rules
Data validation rules are the machine-checkable conditions a product record must satisfy before it counts as complete and publishable. They cover required fields, allowed values, numeric ranges, formats, and conditional logic that changes by category or sales channel. A PIM stores and enforces them, and they act as the acceptance criteria that decide whether a SKU passes review or gets sent back for rework.
What counts as a validation rule
A validation rule is a condition a record must satisfy, written so a machine can check it without a person reading the record.
"The description should be good" is not a rule. "long_description is required, 200-2000 characters, and must not contain the string 'TBD'" is a rule. The test is whether two reviewers would return the same pass/fail answer.
Most rules in a product catalog fall into a handful of shapes:
| Rule type | What it checks | Example on a 3/8-16 x 2" Grade 8 hex bolt |
|---|---|---|
| Required | Field is populated | thread_size cannot be empty |
| Allowed value | Value comes from a fixed list | material_grade is one of: Grade 2, Grade 5, Grade 8, 18-8 SS |
| Range | Number falls between bounds | length_in between 0.25 and 12 |
| Format | Value matches a pattern | gtin is 8, 12, 13, or 14 digits and passes the check digit |
| Uniqueness | No duplicate within a scope | one mpn per supplier |
| Cross-field | Two or more fields agree | drive_size must be consistent with head_style: a 3/8-16 hex head bolt takes a 9/16 wrench, not a Torx bit |
| Referential | Value resolves elsewhere | category_id exists in the taxonomy |
| Unit of measure | Number carries a valid UOM | torque_spec requires ft-lb or N-m, never blank |
The bottom four are where catalogs actually break. Single-field checks are easy to write and easy to pass. A record can have every field populated, every format legal, and still be wrong because the drive size contradicts the head style.
Where the rules come from
Nobody invents a rule set from scratch. It accumulates from four sources, and those sources disagree with each other more often than teams expect.
- Internal governance. What merchandising and product decided a complete record looks like. This is the layer you control and the one most likely to be undocumented.
- Channel and marketplace specs. Amazon flat file category requirements, Google Shopping feed specs, a big-box customer's intake template. Each has its own required fields, its own allowed values, and its own idea of a valid image.
- Classification standards. ETIM class features arrive with defined value lists and units. UNSPSC and GPC constrain what category a SKU can claim. GS1 constrains identifiers.
- Regulatory and compliance. A UL listed 600V wire connector needs its listing number and voltage rating populated. Hazmat items need a UN number. Cross-border items need an HS code.
When the same attribute is governed by two sources, write the strictest rule and map down. A voltage rating stored as "600V" satisfies your internal rule and fails a channel that wants the number and the unit in separate fields.
What happens when a rule fails
A rule with no consequence is a comment. Every rule needs a severity the workflow actually honors.
| Severity | Meaning | Typical consequence |
|---|---|---|
| Error | Record is not publishable | Blocked from channel export; routed to a work queue |
| Warning | Publishable but degraded | Flagged on a report; batched for later cleanup |
| Info | Nice to have | Counted in fill rate, never blocks |
The common failure is making everything an error. A catalog where every rule blocks produces a queue nobody works, and the team starts publishing around the PIM instead of through it.
The other common failure is conditional logic that never got written down. voltage_rating is required only when the category is electrical. thread_pitch is required only when thread_type is not "unthreaded". Skip the condition and you either block valid records or wave through empty ones.
Rules as acceptance criteria for enrichment
A validation rule set is a specification for what enrichment has to produce.
If you can express "done" as a set of rules, you can hand off the work of getting there and check the result mechanically. If you cannot, every batch of enriched data turns into an argument about whether it is good enough.
The PIM stores your product data and enforces the rules against it. It does not go find the torque spec, read the manufacturer's spec sheet, or decide which of three conflicting supplier values is right. That work happens upstream of the check.
Anglera reads the attribute schema and its constraints out of the PIM, completes the SKUs so they satisfy those constraints, and routes anything that fails to human review before write-back. Records land in the PIM already passing validation.
Frequently asked questions
What is the difference between data validation rules and business rules?
In practice they overlap heavily. Validation rules check whether a value is legal: format, range, allowed list. Business rules encode policy — a SKU cannot go live without a primary image, hazmat items cannot list on certain channels, a MAP price must be set before syndication. Many PIMs express both through the same configuration surface, so the distinction matters more in conversation than in setup.
Should validation rules live in the PIM or the ERP?
Product content rules belong in the PIM, because that is where the attributes, taxonomy, and channel mappings already live. The ERP owns rules about costing, inventory, and order eligibility. Duplicating a rule in both systems guarantees they drift apart. If a rule genuinely must exist in two places, pick one as the source of truth and generate the other from it.
How many validation rules does a catalog need?
Fewer than most teams write, and more conditional than they expect. Rules are per category, not per catalog. Fasteners need thread size, pitch, and grade. Wire connectors need voltage rating and wire gauge range. A flat global rule set either blocks everything or checks nothing. Start with the required attributes for your top-revenue categories, then expand outward as those hold up.
Do validation rules fix bad data?
No. They detect it. A rule tells you that `salt_spray_hours` is empty on several thousand SKUs; it does not tell you what the rating is. That is the gap most catalogs sit in: the rules are configured, the failure report runs every week, and nobody has the hours to research every one of those spec sheets. Detection and completion are separate jobs and need separate capacity.
Can validation rules be applied to AI-generated product content?
They should be, and it is the main control you have. Generated values get checked against the same allowed lists, ranges, formats, and cross-field conditions as any other source. Anything that fails is never written back. Anything that passes but sits below a confidence threshold goes to a human reviewer. Rules are what make automated enrichment auditable.