The Control Pattern

Governance — whether applied to data, AI, or financial controls — reduces to a single operational pattern. Recognising this pattern is the difference between building bespoke solutions for every new compliance requirement and building infrastructure that adapts.

The Pattern

Every governance implementation I’ve built follows five stages:

Define quality. Before you can measure anything, you need a specification. In data governance, this means defining what “good” looks like for each data attribute — not just “is it null?” but “is this value consistent with what the counterparty reported, within the expected range, and received on schedule?” In AI governance, this means defining acceptable output characteristics — accuracy thresholds, hallucination rates, bias boundaries.

Build checkpoints. Quality definitions are useless without enforcement points. The architecture question is where in the pipeline to place these gates. Too early and you reject data that could have been remediated. Too late and bad data has already propagated to downstream systems. The answer is almost never a single checkpoint — it’s a staged workflow with different tolerance levels at each gate.

Certify outputs. Certification is what makes governance operational rather than advisory. A certified data point isn’t just “checked” — it has a recorded quality assessment, a timestamp, an attribution to the certification rule that passed it, and a provenance trail. This is where most governance programmes fall short. They build dashboards that show aggregate quality scores but can’t tell you whether a specific data point in a specific report is trustworthy.

Track provenance. Every transformation, every quality decision, every override needs a trail. Not for compliance theatre — for operational debugging. When something goes wrong downstream, provenance tells you where the break occurred and why.

Escalate failures. The most neglected stage. Many organisations build quality checks that flag problems but have no operational workflow to resolve them. The flag goes into a log that nobody reads. Effective governance requires escalation paths — automated remediation where possible, routed human review where not, and clear ownership at every stage.

Why This Matters for AI Governance

The AI governance conversation is often framed as a novel problem requiring novel solutions. In my experience, it’s the same pattern with a different data flow direction.

Traditional data governance gates information flowing in from external sources. AI governance gates information flowing out from internal models. The architectural questions are identical: where do you place the checkpoints? What does “certified” mean for an AI output? How do you track provenance through a model’s decision chain? What happens when an output fails quality criteria?

Organisations that have already built robust data governance infrastructure have 80% of what they need for AI governance. The remaining 20% is model-specific — but the operational backbone is transferable.

The Vendor Trap

A common failure mode: organisations buy an enterprise governance platform (Collibra, Informatica, Precisely) and assume the tooling is the governance. It isn’t. The tooling is a substrate. The governance is the pattern described above — the design decisions about where gates sit, what certification means, how failures escalate. If you can’t articulate those decisions independent of any tool, you haven’t built governance. You’ve bought software.

The frameworks I design are deliberately vendor-neutral. The logic runs on Great Expectations today, could run on Pandera tomorrow, and can be lifted into any enterprise platform. The methodology is the asset. The tooling is replaceable.