A system was passing its own compliance checks — and still letting factual problems reach human review. The fix wasn't a better check. It was noticing that two different questions had been collapsed into one.
A financial-services group needed social content produced at a steady cadence across multiple brands. In a regulated space, that's not a volume problem — it's a trust problem. Every post carries factual and compliance risk, and a single wrong number can create exposure for the business.
I designed and built a content operations system that takes a monthly strategy, drafts platform-specific posts, checks them against brand and compliance rules, and routes everything to a human for approval before anything is scheduled. It runs on an automated daily production cadence with a human approval gate — not unattended publishing.
The system worked. Posts were generating, compliance was catching violations, drafts were landing in the review queue. And yet factual problems were still occasionally surfacing at human review — the last place you want to be relying on a person to catch them.
When I traced why, the insight wasn't about a broken node. It was structural. The compliance gate was checking whether a post faithfully followed its brief — the right tone, the approved offer, no banned topics. It was doing that well.
But nothing was checking whether the brief itself was true.
A post could be perfectly compliant — on-brand, correctly formatted, obeying every rule — and still rest on a statistic the model had produced without a source. "Faithful to the brief" and "true" are two different questions, and the architecture had quietly merged them into one. Once that was clear, the whole class of failures made sense: they weren't compliance failures at all. They were verification failures wearing a compliance mask.
The architectural response was to stop treating this as one job. I split the pipeline into distinct responsibilities — research, verification, strategy, content creation, compliance, and human approval — so that each answers exactly one question and can't paper over another's gap.
The key addition was a verification step that sits before strategy: claims get checked against their actual source material, not against the model's own memory, so an unsupported fact is caught and excluded before it ever becomes the foundation of a post. This is the architecture I designed to close the truth-checking gap; parts of it are built and parts are still being wired and validated.
Just as important was what I chose not to automate. Final approval stays with a human. The system does the repeatable work and routes every genuine judgment call — brand nuance, factual edge cases, anything ambiguous — to a person. Automating that away would have been easy and wrong.
A live system is only as trustworthy as the risks it exposes and contains before publication. These are real catches from the pilot — shown as what was caught and why it mattered, not how it was wired.
The workflow that revises rejected content and sends it back was, in an earlier version, configured to publish that revised content automatically instead of returning it for approval — at the single most sensitive point in the system, on material that had already failed review once.
Across the pilot the compliance gate repeatedly held content that had fabricated specifics the brief never supplied — an invented time-saving statistic and dollar figures that appeared from nowhere. Different fabrications, each caught automatically and held rather than shipped.
A post promoting a resource that didn't exist reached human review and was rejected there — the backstop working as intended. Rather than just fix the post, I traced it to a single configuration value that had silently switched the engine's behaviour for a whole category of posts, then mapped exactly which posts were affected and corrected all of them.
I'd rather show you a pilot with its edges named than a "finished product" that hides them. What's proven is proven; what's in progress is labelled in progress. In regulated work, that distinction is the job.
Client details and implementation mechanics have been limited to protect business confidentiality.
That's the work I do — designing systems that run reliably and know where to stop and ask a human.
Discuss an automation pilot