Most “AI Platforms” Only Sell You Part of the Stack. Here’s the RFP That Exposes the Rest.

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 row of connectors. It looks complete. It sounds complete.

It isn’t.

When you peel back the marketing, most AI platforms deliver one or two layers of the stack and quietly assume someone else will solve the rest. The buyer is left guessing where the boundaries are, what they’re actually paying for, what the vendor is depending on, and what risk they just signed up for. That guessing is how enterprises walk into multi-million-dollar lock-in without realizing it — not at the proof-of-concept, but two years later when the bill comes due and the exit isn’t there.

So I’m publishing the thing those rooms kept needing: the 4+1 AI Platform RFP Framework, Open Edition. A practitioner-aligned, vendor-neutral standard for evaluating AI platforms against the layers they actually have to deliver. The download link is at the bottom.

Why I built it

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 — and not because of compute differences. The hyperscaler had been silently providing something I didn’t have: a reasoning layer. A plane of the system that constantly decides where workloads run, how to trade cost against latency, when to scale, how to respect residency, how to route traffic safely.

In AWS, Azure, or GCP that layer is invisible. You don’t see it, you don’t configure it, you just rely on it. Leave the hyperscaler and the magic disappears — and most enterprises don’t know they’re missing it until they’re standing in the gap. That realization became the 4+1 Layer AI Infrastructure Model, and the RFP sits on top of it.

What the RFP forces into the open

Vendors are incentivized to blur architectural boundaries. Buyers are trying to de-risk a three-to-seven-year commitment. Procurement wants clarity before signing. Legal needs to understand liability. Architects need to know which pieces they still have to build themselves. A layered RFP cuts through all of that by forcing every vendor to state, in writing, which layers they cover, which they integrate, which they depend on someone else for, and where the blind spots sit.

The framework is architect-owned and vendor-facing. An architect sends it to any vendor claiming “AI platform” status, has them map themselves to the layers, and then looks hard at what’s missing. Procurement and legal route the findings — lock-in, liability gaps, data-use rights, compliance exposure — back to architecture for scoring and interpretation.

The 4+1 layers, in plain English

Layer 0 — Compute and Network. What hardware does this run on, and what are the constraints?

Layer 1 — Data Plane. Where the data lives and how it moves: 1A storage and governance, 1B retrieval (embeddings and vectors), 1C data movement and pipelines.

Layer 2 — Operational Tri-Plane. How work runs, scales, gets placed, and stays compliant: 2A the control plane (orchestration), 2B the execution plane (runtime and serving), and 2C the reasoning plane — the agentic decision engine that was missing on my bare metal.

Layer 3 — the AI Application Layer. The “+1.” This is the Value Plane, where the business actually lives: agents, copilots, workflows. It’s named apart from the four foundational layers because it consumes them to produce business outcomes rather than providing infrastructure itself.

The dimensions every buyer also cares about — observability, security, FinOps, compliance, and the question of who holds decision authority — aren’t a separate layer. They cut across all of them, and the RFP evaluates them that way.

The four strategic risks every buyer misses

This is the part procurement, legal, and finance should read first. These four routinely trap enterprises in contracts they can’t exit.

Vector lock-in. You index 50 TB of corporate PDFs and the vendor generates the 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, and operationally disruptive. The RFP asks plainly: are embeddings exportable, are the formats open or proprietary, and do you own the index or does the vendor? That one question can be worth the entire exercise.

Autonomous compliance liability. If a reasoning engine moves a regulated workload to a non-compliant region because it optimized for cost over residency — who is liable? Most vendors default to “you misconfigured the policy.” That isn’t acceptable. The RFP asks whether the vendor assumes any liability, and whether there’s an immutable, cryptographically verifiable audit trail of each decision. That trail is what protects you when a regulator asks why the data moved.

Policy portability. If your governance logic is written in a vendor’s proprietary policy language, you’re locked in for years. The RFP asks whether the policy language is an open standard — OPA/Rego, CUE, YAML, Python — and whether policies can live in GitOps rather than only inside the vendor’s control-plane database. Portable governance, not imprisoned governance.

Model contamination and data rights. Some vendors quietly use customer data to improve their own models. The RFP forces the question: do you claim any right to train on our telemetry or prompts, and can we fully opt out without degrading functionality? For regulated industries this one is existential.

Why it’s open — and where the line now sits

I could have kept this inside paid Buyer Room engagements. I’m not, because the industry needs a shared language, enterprises need to protect themselves, and platform hype needs a counterweight rooted in practitioner experience.

But I want to be precise about the boundary, because it has moved since the first edition. This release puts the full scoring method in the open — not just the questions, but how to grade the answers: the two-axis instrument that scores a vendor on how complete it is at each layer and how much authority adopting it cedes, the discipline that keeps a grade meaning the same thing across vendors, and worked examples that apply the method to real architectures. One of those examples scores the largest on-prem AI infrastructure OEM in the market and finds it strong at the bottom of the stack and a gap exactly where the reasoning plane should be. Another composes a complete eight-layer stack from two vendors whose strengths are mirror images, and shows where authority lands at every layer.

So the line is simple to state:

The method is open. The calibration is paid. The standing board is private.

Anyone can now run the method. What the paid tier holds is the calibration — the maintained vendor heat map, the named-vendor grades kept current across the assessed set, and the live evidence from Buyer Room sessions that grounds them. The standard is open. The standings are not.

What’s inside

The full document is in two parts. Part I is the RFP itself — the layer model, the vendor response template, more than a hundred buyer questions across compute, data plane, pipelines, orchestration, serving, reasoning, and applications, the strategic risk assessment, a one-page red-flags checklist for procurement, and a full glossary. It’s built to be lifted straight into a real procurement cycle. Part II is the evaluation method — the scoring instrument, the worked examples, and the release policy that governs how the standard evolves.

How to use it

If you’re a CIO or CTO, use the executive summary and the strategic risks as your first filter. A vendor that fails the risk assessment doesn’t need the rest of your time.

If you’re a procurement or legal lead, work the risk assessment and red flags to surface lock-in, liability gaps, data-use rights, and compliance exposure, then route the findings to architecture for scoring.

If you’re an enterprise architect, send the RFP to any vendor claiming platform status, make them map to Layers 0 through 3, and study what’s absent. The gaps are the finding.

If you’re a vendor, read it as a preview of what buyers are about to start asking for. This is where the market is heading.

Part of a larger loop

The framework doesn’t sit still. Buyer Room sessions surface what practitioners actually run into; those insights sharpen the model and the questions; the Stack Builder turns the model into interactive evaluation; and the loop closes back into the next release of the standard. The Open Edition gives the industry shared language. The Buyer Room provides the real-world patterns and the maintained board.

Final word

The AI platform market is noisy, the risk is real, and buyers deserve clarity — not just on features, but on governance, autonomy, exit options, and who holds authority when the system makes a decision on its own. This RFP is my attempt at a shared, practitioner-grounded standard for evaluating those things honestly.

Use it. Share it. Challenge vendors with it. If it pushes the market toward more transparency, it’s done its job.

Download the full framework (Open Edition, v2.1): PDF: Download