ACF Custom Fields Are Your LLM's Garbage Disposal—Clean Before Serving

The Setup: A Real Production Failure

We were modernizing a WooCommerce setup for a regulated beverage portfolio last summer. Their product database was rich: bulk SKU data, regulatory markers (alcohol %ABV, allergen flags), compliance notes—all in ACF. The plan was clean: build a RAG pipeline, feed it Claude, use Claude to auto-answer customer questions about ingredient specs and state shipping rules.

The first week of queries, the model started generating incorrect allergen information. On regulated products, that's not a bug—it's a liability. We traced it back within hours: ACF was serializing nested repeater groups as PHP-serialized strings in post_meta. The RAG ingestion script was pulling raw post_meta, and Claude was seeing a:2:{s:9:"allergen";a:3:{i:0;s:4:"milk"...} alongside clean product names. The model had learned to ignore the garbage, then started making confident guesses to fill gaps.

Three weeks of data mapping, validation, and re-indexing. During that time, the feature was disabled. We shipped late. The cost to the client was opportunity cost—they wanted to automate support volume during peak season.

Why This Happens: The WordPress Developer Blind Spot

Most WordPress teams don't think of post_meta as a data contract. You build ACF fields in the GUI, the plugin handles serialization, posts load fine in the WordPress admin. The schema is implicit. It works for human-scale rendering.

Then you plug Claude into it. Claude doesn't care that the data is "working." It sees signal-to-noise ratio. Serialized repeater groups, inconsistent formatting across bulk edits, legacy post_meta keys from an old plugin migration—those aren't bugs anymore. They're training data for hallucination.

I've watched this same pattern across three regulated verticals: financial services (compliance disclaimers in RichText fields feeding a summarizer), healthcare (provider credentials in nested ACF relationships), and CPG (allergen / ingredient matrices). Every time, the agency or in-house team built the RAG index straight from post_meta. Every time, the model performed worse than a rule-based system, and nobody knew why until the audit.

The Fix: Treat ACF as an ETL Stage, Not a Source

Before you touch Claude or any LLM, build an explicit ACF → canonical JSON transformer. It's not glamorous. It's mandatory.

What this looks like:

• Schema definition: Document every ACF field—type, cardinality, expected values, nullable behavior. If you're using repeaters or relationships, define the nesting explicitly.
• Validation layer: Before indexing into Pinecone, Milvus, or whatever vector store you're using, validate against the schema. Reject serialized data. Reject empty required fields. Log violations.
• Type coercion: ACF returns numbers as strings. ACF relationships return post IDs; you may need to hydrate them to post titles. Do that translation once, in code, not in the prompt.
• Audit the source: I ship a small admin page that shows the RAG pipeline's view of each post—what fields were extracted, what was ignored, what failed validation. Editors can see if their ACF edits are actually feeding the model.

For the beverage client, we built a 200-line ETL script (PHP / Laravel) that ran on post_meta_update hooks and on a nightly batch job. It normalized allergen arrays, validated regulatory flags, and surfaced allergen conflicts (e.g., "Contains X" but "Allergen-free" both set). We cut RAG index errors from 23% to 2%. Claude's confidence in its answers went up measurably—support tickets with "I'm not sure, ask your package" dropped from 8% to 2% of responses.

Why Auditing Costs Nothing Now and Saves Everything Later

A lot of agencies skip this because it's not client-visible. You're not building features; you're unglamorous data cleanup. But I've learned: LLM integrations that fail in production always fail on data quality first. Hallucinations, prompt injection, rate-limit thrashing—those are symptoms. Bad source data is the root cause.

If you're running an agentic workflow (Claude using tools to look up product specs, apply discount rules, check inventory), the stakes are higher. A race condition in ACF data might cause the agent to make two conflicting API calls. We saw this in a WooCommerce automation where inventory counts were out of sync with the ACF-backed source of truth. The agent would approve an order, then check stock, then approve the same order again because the two sources disagreed by one field.

The fix was the same: canonical JSON contract, validation, audit layer. No rocket science. Just the willingness to spend two weeks on tooling before you let the model make decisions.

The Multisite Angle: Where This Gets Worse

If you're running WordPress Multisite with shared ACF fields across subsites, your ETL layer also has to enforce role-based access. We've had cases where a RAG index built on one subsite accidentally ingested private or draft posts from a sister site. The model served public context it shouldn't have. That's partly a multisite permission leak, partly a data curation failure. But it starts with assuming post_meta is clean and permissioned the way you expect it to be.

The takeaway: Never feed raw post_meta to an LLM. Build a schema-aware transformation layer first, audit it relentlessly, and make sure every field feeding the model has an explicit permission rule.

Champlin Enterprises ships WordPress modernization and applied-AI integrations for enterprises where data integrity isn't optional—including pharma, financial, and regulated CPG. The AI Showcase and AI Tax both use disciplined ETL and schema validation before any LLM sees data.