Chapter 5. Opportunity and Qualification: S0, S1, and Gate G1

The cheapest place to stop bad work, and the stage most often skipped.

5.1 S0 — Opportunity

Question: should this problem use AI at all, and if so, what kind?

S0 exists because the most expensive governance failures are systems that should never have been built. It is a short stage, often a single conversation, and it produces one decision: proceed to qualification, or stop.

The stage has a specific discipline attached. AI is never self-justifying. A proposal must name a capability or stakeholder need that the system addresses. “We should use AI for this” is not an opportunity; “claims triage takes eleven days and the capability target is four” is.

The six-way sourcing question

S0 also frames the sourcing decision that S3 will settle. Raising it this early prevents teams arriving at architecture having already committed to an approach for reasons nobody recorded.

Table 13. The six-way sourcing question

[Practice recommendation] Require the “no AI” option to be explicitly considered and its rejection recorded in one line. Teams that must write down why a rule engine was insufficient produce noticeably better use cases, and a small number abandon the initiative at this point, which is the cheapest possible outcome.

S0 checklist

• A named capability or stakeholder need is stated, with a current and target measure
• A named business sponsor exists
• The “no AI” alternative has been considered and its rejection recorded
• A provisional sourcing direction is identified, understood as non-binding
• No architecture work has begun

5.2 S1 — Use-Case Qualification

Question: is there genuine value, feasibility, and a plausible data path?

S1 converts an opportunity into a qualified candidate. Its output is the AI Use-Case Canvas, which becomes the evidence base for G1.

Four tests apply, and a failure on any one should stop or reshape the initiative.

Value. An expected outcome stated as a measure with a baseline. “Improved customer experience” fails this test. “Reduce first-response time from 6 hours to under 1 hour for tier-2 queries” passes, because it can be measured later against the same definition.

Feasibility. A plausible technical path, not a proven one. The question is whether anything in the proposal is known to be beyond current capability, not whether success is certain.

Data path. Whether the data the system needs exists, is accessible, and is governed. This is the test that most often fails late when skipped here. A retrieval system grounded on a knowledge base nobody maintains will pass every gate and then degrade quietly.

Provisional risk signal. Enough D1–D5 indication to know roughly what tier is coming. Precision is not required at S1; direction is.

Worked example

Use case. Reduce claims-processing cycle time using a generative triage assistant that summarizes submitted claims and proposes a routing category.

Capability. Claims Handling. Baseline maturity 2, target 4. Current mean cycle time 11 days against a 4-day target.

Value. 30% cycle-time reduction on the triage step, measured as mean hours from submission to routing decision, baselined over the preceding quarter.

Feasibility. Summarization and classification against an existing claims corpus. No novel capability required.

Data path. Claims documents exist in a governed repository, classified Restricted. Routing taxonomy is maintained by the claims operations team.

Provisional risk. D1 moderate (a misrouted claim delays but does not deny), D2 low (advisory only, adjuster decides), D3 low (routing is trivially reversible), D4 moderate (all claims, internal users), D5 moderate (restricted personal data).

Sponsor. Claims Operations Director.

This canvas is enough to pass G1 at the tier it implies. Note what it does not contain: no model choice, no vendor, no architecture. Those belong at S3, and including them here invites the gate to approve an architecture nobody has reviewed.

5.3 S2 in brief, and why it sits before the gate

Risk classification runs before G1, not after. The gate needs a provisional tier to know its own decision authority. A Tier 4 candidate must not be waved through by a product owner because the tier had not yet been assigned when the gate ran.

Chapters 6 and 7 cover classification in full. For G1 purposes, provisional scores are acceptable, and the record must be marked provisional so that the S3 re-score is expected, not treated as a correction.

5.4 Gate G1 — Qualification and Provisional Risk

Table 14.

What “approve with conditions” should mean

Conditional approval is the most useful and most abused outcome at G1. Used well, it lets an initiative proceed while a specific, named deficiency is closed by a specific point. Used badly, it becomes a way to approve everything.

A conditional approval is only valid if it names the condition, the owner, and the gate by which it must be satisfied. “Approve with conditions: data path to be confirmed” is not a condition; it is a deferral with no end. “Approve with conditions: Data Owner to confirm claims corpus classification and retention before G2 entry, owner J. Okafor” is a condition.

[Practice recommendation] Cap open conditions per initiative at three. Beyond that, the honest outcome is Remediate, and treating it as conditional approval accumulates governance debt that surfaces at G3 when it is expensive.

Common G1 failures

Table 15.

The “just a pilot” failure deserves emphasis. Pilots become production systems more often than they are retired, and they do so without passing any gate they skipped. [Practice recommendation] Treat pilot as a deployment state with a mandatory expiry date, not a governance exemption. At expiry the system either enters full governance or is switched off.