Prepare inputs for AI review

AI review cannot rescue input that changes shape from one submission to the next. A phone number arrives with a country code, then without one. A service choice appears as a label today and an internal key tomorrow. A URL includes tracking parameters in one entry and a bare domain in another.

That inconsistency costs staff time before any model gets involved. It also makes prompts longer, comparisons weaker, and routing rules harder to test. The safe way to normalize WordPress form inputs is to work at the form boundary, preserve the original submission, and give reviewers one predictable representation.

Start with a small field contract

A field contract says what a value means, what format downstream work expects, and what must remain untouched. It does not need to be a formal schema. A one-page table is enough for most forms.

Field	Accepted input	Review form	Preserve
Phone	Local or international	One agreed display format	Original value
Email	Valid address	Trimmed; domain case normalized	Original local part
Website	Domain or URL	HTTPS URL when safely inferable	Path and query when meaningful
Service	Approved choice	Stable internal key plus friendly label	Submitted label
Free text	Visitor wording	Whitespace cleaned for display	Exact original text

Keep the contract close to the form owner. If the form changes, the person changing it should know which prompts, exports, notifications, and destinations depend on that field.

Normalize without rewriting visitor intent

Formatting and meaning are different jobs. Removing extra spaces around an email address is formatting. Replacing a visitor’s description of a problem with your preferred category changes meaning.

• Trim accidental leading and trailing whitespace.
• Convert known choice labels to stable keys while retaining the label.
• Standardize dates only when the timezone and locale are known.
• Do not silently correct names, addresses, or free-text claims.
• Store the submitted value when a normalized value is used downstream.

This boundary matters for Entry Summary and Lead Scoring. Consistent structure can make reviews easier to compare, but it must not turn an uncertain input into a confident fact.

Use form controls before cleanup code

The cheapest normalization happens before submission. Use a select field for a closed set of services, a date control for dates, and clear examples for phone or account formats. Keep a text field when the visitor needs to describe something you cannot predict.

WordPress recommends validating, sanitizing, and escaping data at the appropriate boundaries in its data validation guidance. Those security practices are related to normalization, but they are not identical. Sanitization protects storage and output; a field contract protects meaning and downstream consistency.

Protect routing keys from label changes

A common maintenance failure starts with a harmless label edit. “Website support” becomes “Website care,” but a webhook, prompt, or spreadsheet still expects the old wording.

Use a stable internal value for routing and a separate customer-facing label when the form builder supports it. Then record both in the test evidence. The field-change checklist covers the surrounding prompts and destinations that need retesting.

Keep original and normalized values separate

A normalized value is a working representation, not a replacement for evidence. When a reviewer questions a result, they need to see what the visitor actually submitted.

Layer	Purpose	Example
Original	Audit and customer context	The exact submitted phone value
Normalized	Comparison and routing	A consistent international display value
Derived	Review aid	Country inferred with a documented rule
Model output	Recommendation	Suggested queue or summary

Label derived values and model output as such. Do not let either overwrite the source record.

Test the contract with edge cases

1. Submit one normal example for every mapped field.
2. Try spaces, punctuation, capitalization, and international formats.
3. Change one customer-facing choice label without changing its stable key.
4. Leave optional fields empty and confirm that “missing” is not converted into a fact.
5. Compare the source entry, normalized context, action result, and downstream record.

Use fictional data and record the form ID, entry ID, time, expected transformation, and observed result. Pair the test with the post-update form smoke test when plugins or themes changed.

Measure review rework

Count entries that need manual cleanup, routing corrections caused by label drift, failed downstream matches, and review decisions reversed after checking the original value. The useful outcome is less avoidable rework without hiding source data or inventing certainty.