Product Data Validation: AI Where Needed, Rules Elsewhere

Product data is an attractive enterprise AI use case because inputs are messy and the desired output appears structured. But a model that can read a document or compose a description should not decide whether a record is compliant. We separate probabilistic interpretation from deterministic control: models extract and formulate; traceable rules validate and decide.

Product data is a control system, not a writing task

A product record sits at the intersection of supplier evidence, commercial requirements, legal obligations, channel specifications and internal master data. One attribute may affect search, logistics, tax, safety review, packaging or customer expectations. An apparently minor edit can propagate into many downstream systems.

This makes “generate the product content” the wrong system boundary. Generation is only one activity. The real workflow receives evidence, identifies entities and attributes, applies policy, routes exceptions, records approvals and publishes an authorised version. Reliability depends on the whole chain.

We therefore begin with two categories of work:

Interpretation: reading variable documents, images or free text; mapping unfamiliar language to a known concept; drafting a concise description.
Control: checking required fields, data types, allowed values, units, cross-field dependencies, evidence requirements, permissions and publication status.

Interpretation is probabilistic and benefits from models. Control should be deterministic wherever the policy can be stated. Combining both inside one prompt makes the output difficult to audit, test and appeal.

Define the canonical record before adding AI

The canonical product model needs stable identifiers, typed fields and explicit ownership. For each attribute, we document its definition, unit, cardinality, allowed sources, required evidence, market or channel scope and authority to approve changes.

The raw evidence remains immutable. We store extracted candidates separately from approved values. This prevents a model-generated value from silently becoming a fact and lets reviewers compare the candidate with its source. A minimal lineage record includes:

product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_status

The production record contains only values that passed the relevant rules and approval path. This is consistent with the architecture behind a B2B catalog with certification pages: claims should remain connected to evidence instead of being treated as interchangeable marketing copy.

Where models add value

Models are useful at the variable edges of the workflow.

Extracting candidates from unstructured evidence

Supplier forms, technical sheets, labels and images often express the same attribute in different layouts or wording. A model can locate likely values, normalise the surrounding text and return a structured candidate with an evidence reference. The output contract should require null when evidence is absent; guessing is not completion.

For vision tasks, the system should preserve the image region or page that supports the extraction. For text, it should preserve a short source span or coordinate. Confidence is useful for routing, but it is not evidence and should never replace the source reference.

Mapping language to a controlled vocabulary

A source term may not exactly match the organisation's taxonomy. A model can propose the closest controlled concept and explain the mapping. The final acceptance remains a rule or an authorised reviewer decision. If the taxonomy has an exact synonym table, deterministic matching should run first; the model handles the unresolved remainder.

Formulating customer-facing text

Models can draft titles, bullets, summaries or translations from approved attributes. The prompt should draw only from the approved record and clearly label optional style instructions. Generated copy then passes rules for length, prohibited claims, required qualifiers, terminology and unsupported values.

The model is not asked whether its own text complies. That would make the same probabilistic component both author and judge.

Where rules must decide

Rules are appropriate when a failure condition can be expressed and tested. Typical categories include:

Rule type	Example control
Presence	Required attribute is populated for this product class
Type and format	Value parses as the declared type and encoding
Range	Numeric value falls within an authorised interval
Enumeration	Value belongs to the current controlled vocabulary
Unit	Unit is permitted and conversion is lossless or approved
Cross-field	A dependent field is present when a trigger value applies
Evidence	Claim has an eligible, current source document
Consistency	Pack quantity, dimensions and derived totals reconcile
Scope	Value is valid for the target language, market and channel
Authority	Actor is allowed to approve or publish this field

Each rule needs an identifier, version, owner, severity and human-readable message. The message matters: “validation failed” creates a support ticket; “net quantity requires an approved unit and source reference” creates a repair task.

This separation also makes flatfile automation across multiple destinations safer: destination-specific formatting can change without weakening the canonical validation policy.

Rules should run at several boundaries: on ingestion, after extraction, after human edits, before export and before publication. The same versioned validation service should be used by the interface, batch pipeline and API. Duplicating rule logic across systems creates contradictory outcomes.

A reference workflow

We implement the process as a series of explicit state transitions:

Ingest: register source files, checksums, origin and receipt time.
Preprocess: classify documents and associate them with candidate product identities.
Extract: use deterministic parsers first, then models for unresolved fields.
Normalise: convert formats and units without changing semantic meaning.
Validate: execute the applicable versioned rule set.
Review: route only exceptions or high-risk changes to an authorised person.
Approve: record the accepted value, evidence and approving identity.
Publish: write through a controlled adapter to each destination.
Observe: capture downstream rejections, corrections and outcome signals.

Every transition produces an event. That event log makes the system replayable: when a taxonomy or rule changes, affected records can be identified and revalidated without extracting everything again.

The same principle applies to language variants. A disciplined multilingual commerce architecture treats translation as a derived, versioned output while approved facts and evidence remain shared.

The workflow also avoids an expensive anti-pattern—sending every field to the largest available model. Exact identifiers, dates, known units and enumerated codes should take deterministic paths. Models are reserved for ambiguous fields. This reduces cost and latency while making the remaining model evaluation more meaningful.

Confidence routes work; it does not grant truth

Confidence scores are often misunderstood. A high model confidence does not prove that a source is correct, current or authorised. It only describes the model's assessment under a particular method.

We use confidence alongside risk and rule results to select a route. A low-risk candidate with direct evidence and all rules passed may enter a lightweight review queue. A regulated or commercially sensitive claim may require human approval regardless of confidence. Missing evidence causes abstention, not a lower threshold.

Thresholds should be calibrated on representative data by attribute and document type. One global threshold hides major differences: extracting a standard identifier is not equivalent to interpreting a material claim. We track precision, recall, abstention and reviewer override for each meaningful segment.

Exceptions are part of the product

Real catalogs contain bundles, replacement items, regional variants, legacy records and conflicting supplier documents. A system designed only for the happy path will create manual work in unobservable places.

An exception needs a reason code, severity, owner, due date and permitted resolution. Reviewers should see the candidate, source evidence, failed rules and downstream impact in one view. They should be able to accept, correct, reject or request new evidence without editing raw source data.

Overrides must be explicit and scoped. A reviewer may override a warning for one product and destination, but should not disable the underlying rule globally. Repeated overrides are a signal: the rule, taxonomy, source process or product model may need revision.

Service levels should reflect business risk rather than arrival order. A missing optional marketing field and a contradictory safety attribute do not belong in the same queue.

Measurement from baseline to outcome

Before automation, we measure field completeness, first-pass validation, correction cycles, review time, downstream rejection rate and severe defect rate. For confidential internal reporting, we can express each series as an index with Baseline = 100, keeping absolute volumes and commercial values inside the authorised environment.

After release, we separate extraction quality from operational performance. An extraction can be technically correct yet arrive too late for publication. A workflow can reduce review time while increasing severe defects. The scorecard therefore includes:

candidate accuracy and evidence coverage by attribute;
rule-pass and abstention rates;
human override and correction rates;
queue age and time to approved record;
destination rejections and post-publication corrections;
guardrails for high-severity errors.

Changes to models, prompts, taxonomies and rules are versioned independently. Evaluation sets include common records and known exceptions. Before deployment, we replay the proposed version and compare both newly accepted and newly rejected records. A release is blocked if a guardrail deteriorates beyond its agreed tolerance, even when average accuracy improves.

Govern changes as policy changes

Rules encode operational policy. Updating them can change which products are publishable, which claims are permitted and which teams receive work. Rule changes therefore need an owner, rationale, effective date, tests and approval proportional to impact.

Model changes need similar discipline but different tests. We evaluate extraction and formulation against labelled cases, including adversarial and low-quality inputs. We also test the structured output contract: unknown fields, invalid types and missing evidence must fail safely.

Deployment should be gradual. Shadow mode compares the new path without changing records. A limited cohort follows, then broader rollout if guardrails hold. The write adapter enforces idempotency, least privilege and rollback. No model receives direct, unrestricted access to the system of record.

The division of labour that scales

The durable architecture is not “AI versus rules.” It is a deliberate division of labour.

Models convert variable evidence into candidates and approved facts into useful language. Rules express repeatable policy. Humans resolve ambiguity, approve high-impact changes and improve the policy when exceptions reveal a gap. Event logs connect every decision to evidence and versioned logic.

This design is easier to explain to executives because risk is bounded by action and evidence. It is easier to build because components have testable contracts. And it is easier to operate because failures become specific: an extraction missed a value, a source was ineligible, a rule rejected a combination, or an authorised reviewer overrode a warning.

Enterprise product data will never be perfectly clean or uniform. It does not need to be. The system needs to know what is observed, what is inferred, what is allowed and who decided. Put AI where interpretation is genuinely required. Put rules wherever the organisation already knows how to state the decision.