AI Transformation Fails at the Foundation, Not the Model

I run an architecture knowledge base that an AI curates and I ratify. Raw sources in, cross-linked wiki out — under a written contract. The model is the least interesting part of that sentence, and that's the point.

Every transformation conversation I walk into starts with the model. Which one, how big, how many pilots. Almost none of them start with the foundation: the data the model reads, the contract for what it may do, and the human who signs off before its output becomes a decision. That's where transformations actually die — in production, not in the pilot.

What's funded vs. what decides the outcome

• Model selection gets funded. Whether the data is trustworthy decides the outcome — CMDB and CSDM accuracy, not vibes.
• Pilot velocity gets funded. Operating contracts decide the outcome: what the AI may touch, change and promise.
• Impressive demos get funded. Ratification gates decide the outcome: a human with authority signs off before output becomes action.
• Speed to deploy gets funded. Integrity checks decide the outcome: continuous proof the output still matches reality.

Pilots are cheap. Production is where the foundation gets audited — by your customers, your auditors and your incident channel.

Models are rented. The foundation is owned.

The three questions

Here's the advice I'd give any executive before scaling AI — three questions about every system you plan to run:

1. What does it contractually agree to do? An operating contract between the AI system and the business process it serves: scope, limits and the data it may use.
2. Who ratifies its output? A named human, with authority, before the output becomes a decision, a payment or a customer-facing message.
3. How do you know it's still right? Integrity checks that run continuously, because models drift, data rots and sessions forget.

Proof, not theory: my own second brain

That isn't a framework I invented for this post. It's how my AI-maintained architecture knowledge base has run for nearly two years:

• Operating contract. Every session opens by reading a written contract that defines what the AI may and may not do.
• Ratification gate. Nothing is treated as settled until I settle it. Decisions sit in a pending-ratification queue until I ratify them.
• Integrity checks. Every session closes by running checks and scripts, and a ruled-out list keeps a fresh session from confidently re-suggesting what we abandoned last Tuesday.

Answer all three and the model becomes interchangeable — a line item you can swap. Skip them and the model becomes load-bearing in an architecture that can't hold it, and swapping it later is a decision, not a config change. (See When a Config Change Is Really an Acquisition.)

Copy this: the three-question foundation test

## Before scaling any AI system

Answer in writing, with names and dates:

1. OPERATING CONTRACT - scope, limits, data it may use, what it may
   change. Signed by the process owner.
2. RATIFICATION GATE - who signs off before output becomes action.
   Named human, with authority.
3. INTEGRITY CHECKS - how output is continuously verified against
   reality, and who owns the check.

If a question can't be answered, the system isn't ready to scale.

This is the contract my own AI-maintained architecture knowledge base runs under, nearly two years in.