Readiness gate

A readiness gate is the decision point at the end of the first two weeks of an AI Delivery Readiness Review. The team answers one question: should this workflow proceed to a build, be reframed around a different problem, or be paused until a precondition is met?

The gate is passed only when four preconditions are visible in writing. There is a named business owner who will accept the outcome. There is access to the data the workflow needs, agreed with the data owner. There is a success threshold the owner can measure. And there is a list of constraints covering security, legal and operational limits.

In practice

In the first week I map the workflow from the trigger to the outcome, sample real inputs and check which of the four preconditions are true. In the second week I test the riskiest assumption, which is usually data access or the quality of the source records. I run that test as a small spike, not as a design document.

The output is a one-page recommendation with the evidence attached. A pause is a valid result. It stops the client from paying for a system that cannot be evaluated or run safely.

Example

[Composite] A logistics firm wanted an agent to draft replies to carriers about delayed shipments. In week two the team found that exception codes were free text in three separate systems. The recommendation was to reframe: standardise the codes first, then build the agent. The build started later, on a narrower scope.

Common mistakes

• Treating the gate as a formality. If the owner has not been named, the gate has not been passed.
• Judging the idea before testing the data. In my experience the blockers are usually access and records, not the model.
• Writing a success threshold that cannot be measured. Use a number or a yes or no that the owner can check.