Two distinct responsibilities
WordPress can be the front door. It should not be the claims database.
A public content platform can collect a bounded request, deliver controlled content, and connect to backend workflows. It should not become accidental enterprise middleware or receive direct authority over sensitive operational tables. MySQL may support the public experience, but the approved system of record remains behind the governed business boundary.
- Content and campaigns
- Public resources
- Qualification forms
- Authenticated portal entry where approved
- Accessible user experience
- Claims, policy, payment, and case records
- Identity and authorization
- Validated commands
- Audit and retention
- Business workflow and decision ownership
Safe integration pattern
Connect public forms to backend workflows through a governed API.
→
→
→
Modernization work
Harden the platform and remove hidden operational coupling.
- PHP and WordPress version planning
- Theme and plugin inventory
- Dependency and supply-chain review
- Least-privilege administration
- Custom API and backend integration
- Form abuse and file-upload controls
- Secrets and environment separation
- Database and cache performance
- Backup and restore rehearsal
- Logging, monitoring, and incident paths
- Accessibility and responsive behavior
- Migration away from plugin-owned business logic
AI on the public edge
Use AI without giving the public site uncontrolled authority.
Public AI features should retrieve only authorized content, cite sources where appropriate, validate outputs, apply cost and rate limits, and use backend commands for any material write. Sensitive data, production credentials, unrestricted database access, and final business authority stay outside the model.