The Governance Checklist Before You Ship an AI Feature

Before you ship any AI feature that touches a real customer, run it through a short governance checklist: can you log it, can it refuse, can a human oversee it, can you stop it, and can you explain it. If the answer to any of those is no, you are shipping a feature you cannot stand behind when it fails. And it will fail eventually. This checklist is not bureaucracy. It is the ten-minute gate that separates a product you can defend from one that becomes a liability the first time it misbehaves.

I run this before every governed feature goes live across the portfolio. It is deliberately short, because a checklist nobody runs is worse than none. Five questions, each with a concrete answer.

Can you log what it does?

If you cannot reconstruct what the feature did after the fact, nothing else on this list matters. Confirm you are capturing the right fields on every AI call: input, model version, prompt version, output, action, and outcome. This is the foundation the rest stands on, and it is the same audit-trail discipline that belongs in every AI system.

Fail this one and skip the rest. You are not ready to ship.

Can it refuse?

A feature that answers everything, including what it should not, is a liability. Confirm the system knows when to refuse instead of answer: when it lacks grounding, when the action is high-risk, when the request is out of scope. Test the refusal path, not just the happy path.

A confident wrong answer in front of the wrong customer costs more than any refusal. Make sure the feature can say no.

Can a human oversee the risky parts?

Identify the consequential actions: anything that moves money, sends externally, changes records, or makes a claim someone will act on. Confirm those route through human oversight, which is a feature and not a failure, or an approval gate in the workflow.

Low-stakes actions can run autonomously. High-stakes ones need a human in the path. Draw that line before you ship, not after an incident forces you to.

Can you stop it?

If the feature takes actions, confirm you can halt it fast when it goes wrong. This is the kill switch every action-taking agent needs: reachable without a deploy, scoped, and safe to resume. An answering feature can skip this. An acting feature cannot.

Ask the blunt question: if this starts doing the wrong thing at scale right now, how do I stop it in the next thirty seconds? If you do not have an answer, build one before launch.

Can you explain it?

When a customer or a reviewer asks why the feature did something, you need more than a shrug. Confirm you can trace the output to its source, the way data lineage lets you, and reconstruct the decision well enough to make it defensible after the fact.

Explainability is not a separate project. If you nailed the logging and the lineage, you can already explain. This item is the check that the earlier ones actually work.

Why the checklist is the moat, not the drag

Founders worry a gate like this slows shipping. It does not slow it much, and the fear is mostly misplaced, which is the whole argument that governance does not actually slow down shipping. Five questions before launch is cheap. Rebuilding trust after an unaccountable feature blows up is not.

This checklist is the operational form of the belief that governance is the moat once capability is a commodity. Anyone can ship a feature that works in a demo. Shipping one you can log, refuse, oversee, stop, and explain is the harder discipline, and it is the one that lets you sell to buyers who matter.

I run this gate on every governed feature I ship on Girard AI, and it takes minutes. The features that pass are the ones I can defend when a customer, a regulator, or my own monitoring finds a problem. Ship accountable, not just working. The checklist is how.