A system was passing its own compliance checks and still letting factual problems reach human review. The fix was noticing that two different questions had been collapsed into one.
Field note
What failed was not a node. It was a missing responsibility.
Client details and implementation mechanics are limited to protect business confidentiality.
A financial-services group needed social content produced at a steady cadence across multiple brands. In a regulated space, that is not just a volume problem; it is a trust problem. Every post carries factual and compliance risk, and a single wrong number can create exposure for the business.
I 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, and drafts were landing in the review queue. Yet factual problems were still occasionally surfacing at human review—the last place you want to rely on a person to catch them.
The gate checked 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 compliant, on-brand, correctly formatted, and still rest on a statistic the model had produced without a source. “Faithful to the brief” and “true” are two different questions. The failures were verification failures wearing a compliance mask.
I split the pipeline into distinct responsibilities—research, verification, strategy, content creation, compliance, and human approval—so each answers exactly one question and cannot paper over another's gap.
The key addition was a verification step before strategy: claims get checked against their actual source material, not against the model's memory. Unsupported facts are caught and excluded before they become the foundation of a post. Parts of this architecture are built; parts are still being wired and validated.
Final approval stays with a human. The system handles repeatable work and routes judgment calls, brand nuance, factual edge cases, and ambiguity 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. These are real catches from the pilot.
The workflow that revised rejected content was once configured to publish that revised content automatically instead of returning it for approval. I identified the risk and redesigned the path to preserve mandatory human approval. The live configuration returns revised content as a draft; a final supervised end-to-end run is pending.
The gate repeatedly held fabricated specifics: an invented time-saving statistic and dollar figures the brief never supplied. Cataloguing these as distinct failure classes drove the verification redesign instead of one-off patches.
A post promoting a nonexistent resource reached human review and was rejected. I traced it to one configuration value that had silently changed behaviour for a whole category of posts, then corrected the full blast radius.
I'd rather show 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.