For the past two years, I’ve been in rooms—Buyer Rooms, CIO roundtables, vendor advisory sessions—where everyone claims to have an “AI platform.” There’s always a diagram, usually a box labeled something like AI OS sitting above a cluster, a model server, and a bunch of connectors. It looks complete. It sounds complete.

But it’s not complete.

When you peel back the marketing, most “AI platforms” only deliver one or two layers of the stack. And buyers are left guessing where the boundaries are, what they’re really buying, what the vendor is assuming someone else will solve, and what risks they’re signing up for.

This is how enterprises walk into multi-million-dollar lock-in without realizing it.

So today, I’m publishing something that I believe the industry has needed for a long time:

📘 The 4+1 AI Platform RFP Framework (Open Edition)

A practitioner-aligned, vendor-neutral standard for evaluating AI platforms.
Download the full documents:

• PDF: CDN Download

Why I Built This

Earlier this year, I tried to replicate a cloud-native AI application on bare-metal DGX infrastructure. Same code. Same models. Same data.

It didn’t work.

Not because of compute differences… but because the hyperscaler was silently providing something I didn’t have:

A reasoning layer.

A plane of the system that constantly makes decisions about:

• where workloads should run

• how to balance cost vs. latency

• when to scale up or down

• how to respect residency requirements

• how to route traffic safely

It’s invisible when you’re in AWS/Azure/GCP. You don’t see it. You don’t configure it. You just rely on it.

But when you leave the hyperscaler, that “magic” disappears. And most enterprises don’t know they’re missing it.

This realization became the 4+1 Layer AI Infrastructure Model—and now, the RFP that sits on top of it.

What This RFP Solves

Vendors are incentivized to blur architectural boundaries.
Buyers are trying to de-risk long-term commitments.
Procurement wants clarity before signing a 3–7-year contract.
Legal needs to understand liability.
Architects need to know which pieces they must still build.

A layered RFP cuts through all of that.

It forces vendors to explicitly state:

• Which layers they actually cover

• Which layers they integrate

• Which layers they depend on

• Where risks and blind spots sit

And it helps buyers avoid the mistakes that derail AI programs—not at the POC stage, but two years later when the bill comes due.

The 4+1 Layers (Plain English)

Here’s the model in simple terms:

Layer 0 — Compute & Network

“What hardware does this run on, and what are the constraints?”

Layer 1 — Data Plane
1A: Storage & Governance
1B: Retrieval (embeddings, vectors)
1C: Data Movement

“Where is the data, and how does it move between systems?”

Layer 2 — Operational Tri-Plane
2A: Control Plane (orchestration)
2B: Execution Plane (runtime)
2C: Reasoning Plane (agentic decision engine)

“How does work run, scale, get placed, and stay compliant?”

Layer 3 — AI Application Layer

“Where the business actually lives—agents, copilots, workflows.”

And there are cross-cutting concerns across all layers:

• Observability

• Security

• FinOps

• Compliance

This is the structure the RFP uses.
Every vendor must map their capabilities to the model.

---

The 4 Strategic Risks Every Buyer Misses

This is the part of the RFP that procurement, legal, and finance should read first.

These four risks routinely trap enterprises in contracts they can’t exit.

1. Vector Lock-In (Layer 1B)

You index 50 TB of corporate PDFs.
The vendor generates embeddings.

Two years later you want to leave.
Can you export your vectors? Or only the raw PDFs?

Re-embedding 50 TB is:

• expensive

• slow

• operationally disruptive

The RFP asks vendors explicitly:

• Are embeddings exportable?

• Are formats open or proprietary?

• Do you own the index or does the vendor?

This one question alone is worth the entire RFP.

2. Autonomous Compliance Liability (Layer 2C)

If a reasoning engine moves regulated workloads to a non-compliant region because it prioritized cost over residency…

Who is liable?

Most vendors default to:

“You misconfigured the policy.”

Not acceptable.

The RFP asks:

• Does the vendor assume any liability?

• Is there an immutable, cryptographically verifiable decision audit trail?

This protects you when regulators ask, “Why did this data move?”

3. Policy Portability (Layer 2C)

If your reasoning logic is built using a proprietary DSL, you’re locked in for years.

The RFP asks:

• Is the policy language open (OPA/Rego, CUE, YAML, Python)?

• Can policies live in GitOps, not just the vendor’s control plane database?

This ensures your governance is portable—not imprisoned.

4. Model Contamination & Data Rights

Some vendors quietly use customer data to improve their own models.

The RFP forces vendors to answer:

• Do you claim rights to train models on our telemetry or prompts?

• Can we fully opt out without degrading functionality?

This is existential for regulated industries.

Why This Is an Open Standard

I could have kept this as part of Buyer Room paid engagements.
Instead, I’m releasing the Open Edition because:

• The industry needs a shared language.

• Enterprises need to protect themselves.

• Vendors need clarity about what buyers actually expect.

• Platform hype needs a counterbalance rooted in real practitioner experience.

The paid tier still exists (scoring, weighting, maturity modeling, competitive patterns).
But the structure—the standard—should be open.

What’s Inside the Full RFP

(Download links below.)

✔ 100+ detailed buyer questions

Covering compute, data plane, pipelines, orchestration, serving, reasoning, and applications.

✔ The 2C Differentiation Table

Shows exactly why the Reasoning Plane is not “just an operator.”

✔ The Strategic Risk Assessment (Section 2.2)

Vector lock-in
Compliance liability
Policy DSL traps
Model contamination

✔ Layer-by-layer guidance

What to ask
What to look for
Where vendors mislead
Where enterprises trip

✔ Red Flags Checklist

A one-page escalation guide for procurement teams.

✔ Full Glossary

Clear definitions for Reasoning Plane, Execution Plane, policy oscillation, kill switch, dry-run, vector lock-in, and more.

✔ Update Cadence

This becomes more valuable as vendor behavior evolves.

Download the Full Framework (Open Edition v1.1)

• PDF: https://cdn.blubrry.com/YOUR_PATH/4plus1-rfp-v1.1.pdf

How to Use This in Your Organization

If you’re a CIO/CTO:

Use the executive summary as your filter.
If a vendor fails Section 2.2 (Strategic Risks), you don’t need the rest.

If you’re a procurement or legal lead:

Use the RFP to identify:

• lock-in

• liability gaps

• data use rights

• compliance exposures

Pull architects in only when needed.

If you’re an enterprise architect:

Send this RFP to any vendor claiming “AI platform” status.
Have them map themselves to layers 0–3.
Then look at what’s missing.

If you’re a vendor:

Use the RFP as a guide to what buyers are finally going to start asking for.
This is where the market is heading.

This Framework is Part of a Larger Ecosystem

Buyer Rooms → RFP → Stack Builder → Buyer Rooms

This loop captures real practitioner insights, evolves the model, and updates the standard.

The Open Edition provides shared language.
Buyer Rooms provide real-world patterns.
Stack Builder provides interactive evaluation.

Final Word

The AI platform market is noisy.
The risk is real.
And buyers deserve clarity.

This RFP is my attempt to give the industry a shared, practitioner-grounded standard for evaluating AI platforms—not just features, but risks, governance, autonomy, and exit options.

Use it. Share it. Challenge vendors with it.
If the framework pushes the industry toward more transparency, it has done its job.