Governed enrichment
Why enrichment suggestions should never auto-approve
A review-first operating model that preserves source truth, uses confidence as attention guidance, and keeps provider capability separate from approval.
Written for ecommerce, catalog, and ai-governance practitioners. This is educational methodology, not a customer case study or performance claim.
Keep three layers of catalog truth
A source value, an enrichment suggestion, and an approved product attribute are not interchangeable. The source records what arrived, the suggestion records a proposed interpretation, and the canonical attribute records a reviewed decision.
Collapsing those layers makes correction harder. A reviewer cannot tell whether a phrase came from the source, a rule, a model, or a previous edit. Keeping the layers distinct preserves both accountability and the option to improve the enrichment method later.
Practice
- Never overwrite source content during suggestion generation.
- Store the prompt or profile version with the suggestion run.
- Promote values to canonical truth only through review.
Use confidence to direct attention
Confidence is most useful as a triage signal. A low-confidence material or fit suggestion deserves closer inspection; a stronger color suggestion may need less time. Neither score authorizes a state change on its own.
Thresholds can order a queue or mark work as needing review, but they should not hide the evidence. Reviewers need the proposed value, source context, reason, and any brand rule that shaped the output.
Practice
- Sort uncertain or high-impact suggestions toward the top.
- Expose the evidence needed to make the decision.
- Avoid a global score that obscures field-level uncertainty.
Make review a durable decision
Accept, edit, and reject are different decisions. Accept preserves the proposed value, edit creates reviewer-authored truth, and reject records that the suggestion should not be used. Each action should be tenant-scoped and auditable.
Bulk review needs the same discipline. A filtered operation should report what matched, what changed, and what had already been reviewed. It should not describe a queued or partially applied operation as complete.
Practice
- Record actor, action, scope, and time for each decision.
- Keep reviewed suggestions immutable as evidence.
- Report bulk results without fabricating success.
Separate provider capability from product governance
Changing the enrichment engine should not change the approval contract. Deterministic fixtures, a future local model, and later model versions should all return the same strict suggestion shape and enter the same review path.
Provider availability is also not output quality. A local workflow can prove state transitions and controls without claiming production model fidelity. Quality evaluation belongs in its own evidence and should not be inferred from a green review interface.
Practice
- Validate provider output against a strict schema.
- Keep provider failures from creating fake suggestions.
- Evaluate model quality separately from workflow correctness.
Truth boundary
What the current product can support.
Review-first enrichment workflow
The local product stores strict-schema suggestions and supports accept, edit, reject, QA, and bulk-review decisions.
Deterministic local workflow evidence
MockProvider supports repeatable local verification of the enrichment state machine, not production model-quality claims.
Local/open-weight enrichment provider
A non-mock local provider is the sanctioned future path but is not implemented in the current repository.
Continue reading