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. Do not spend an unbounded amount on API calls, and do not run the same job twice. Never write to a live product page before a person has read it. And be able to explain afterwards what changed and who approved it.
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 I built the architecture around it instead of bolting it on later.
- Separating the approval capability from the generation capability means whoever can run a batch cannot also publish it. That split is what 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. A workflow 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.