ai Case study
Product Specification Workflow
A catalog of this size cannot be described by hand, and it also cannot be handed to a language model unsupervised. This is the workflow in between: generated titles, attributes and descriptions that queue for a person to approve, with the controls that make running it against a live store defensible.
The business problem
The catalog had inconsistent titles, thin descriptions and attribute data that varied by whoever entered it. Generating better copy is the easy part. The hard part is everything around it: not spending an unbounded amount on API calls, not running the same job twice, not writing to a live product page without a human reading it first, and being able to explain afterwards what was changed and by whom.
What I delivered
- a2-seo-ai, a modular WordPress plugin with an explicit human review gate between generation and publication.
- Two dedicated roles, SEO manager and reviewer, with four separate capabilities covering settings, approval, log access and job execution, so generating and approving are never the same permission.
- A budget guard that bounds API spend, because an unbounded loop against a paid API is the failure mode that matters most here.
- A job lock and an idempotency layer, so a retried or overlapping run cannot process the same product twice.
- Encrypted storage for the API key, read from a constant when one is defined rather than kept in the database.
- A Rank Math integration utility, so generated metadata lands in the fields the site's SEO plugin actually reads.
- A test suite covering the parts where correctness is not visible by inspection: job locking, scheduling, the review workflow, idempotency and activation.
Technical approach
- Nothing writes to a product without passing the review gate. That constraint came first and the architecture was built around it rather than added afterwards.
- Separating the approval capability from the generation capability means the person who can run a batch cannot also publish it, which is the control that makes the whole thing safe to delegate.
- The budget guard and the job lock exist because the two realistic disasters are a runaway spend and a duplicated batch. Both are cheap to prevent and expensive to discover.
- Jobs and their state live in the plugin's own tables, so a run is inspectable and resumable instead of being a fire-and-forget scheduled task.
- The tests target the concurrency and idempotency logic specifically, since those are the paths that look correct in review and fail under real scheduling.
Result and evidence
The catalog can be improved at a rate a small team can actually review, with a record of what was generated, what was approved and by whom. The gate is the deliverable as much as the generation is.
Commercial value
Most AI content tooling optimizes for throughput. On a commerce catalog the constraint is trust, and a workflow that a shop owner is willing to leave switched on is worth more than one that produces more copy faster.
Readable implementation brief
implementation_brief {
project: "Product Specification Workflow"
plugin: "a2-seo-ai (modular, WooCommerce + Rank Math)"
gate: "generation never writes; a reviewer approves"
roles: "seo_ai_manager, seo_ai_reviewer"
caps: "manage_settings, approve_content, view_logs, run_jobs"
guards: "budget guard, job lock, idempotency layer"
secrets: "encrypted at rest; constant overrides the DB"
tests: "job lock, scheduler, review workflow, idempotency"
}What this project shows
I would point a reviewer at the capability split and the budget guard rather than at the prompt engineering. Those are the parts that decide whether this can run against a live store.
Writing tests for job locking and idempotency rather than for the generated text was a deliberate choice about where the real risk lives.