The architecture review is forty minutes old and you have not said a word. On screen is a diagram with eleven boxes and nineteen arrows, and the discussion has moved through vector stores, token throughput, egress fees, identity federation, and something called a control plane. You understand a third of it. Around the table sit four people who understand all of it and who are, visibly, waiting for the business person to nod or stop wasting their afternoon. So you nod. The recommendation carries. Twenty-two months later you are explaining to a chief financial officer why the AI platform bill went from 38,000 dollars a year to 214,000, why the one use case the board cares about cannot be moved to a better tool, and why moving it anyway would take seven months. Nobody in that room lied to you or made a technical mistake. The only questions nobody asked were the ones you were the only person there qualified to ask.

Two Bad Options, and the Third One Nobody Teaches

Every AI readiness strategist eventually sits in that room. The platform layer is the substrate all of your portfolio items run on: the model providers, the assistant tenant, the retrieval infrastructure, the workflow or agent runtime, the integration middleware, the identity and logging plumbing. It is decided in a language most strategists do not speak, and its consequences arrive years later on your profit and loss rather than the architects'. The profession offers two failure modes here, both bad in slow-surfacing ways.

Abdication is the polite one. You defer entirely to information technology (IT) and architecture on the grounds that they know and you do not. It feels like humility. What you actually did was accept, unread, a set of business commitments: a substrate you cannot exit, a cost curve nobody modelled, and a capability boundary that will quietly veto use cases for five years. Nobody calls them business commitments when they are made, because they are made inside technical sentences. They become business commitments the first time a use case dies on a capability the platform lacks, or a successful rollout produces a bill that reads to finance like a failure.

Pretense is the ambitious one. You spend a weekend on vendor documentation and arrive with opinions about inference architecture. It ends one of two ways: you are wrong in front of people who can tell, and your credibility on what you actually know (process, risk appetite, sequencing, the business case) never recovers; or you are accidentally right and own a technical decision you cannot defend when it degrades. Engineers forgive ignorance far more readily than costume.

The third path rests on a distinction that reorganises the whole room: platform decisions are made of two kinds of question, and only one kind is technical. Whether a platform can achieve sub-second retrieval over four million documents is technical. Whether the business can accept a twenty-week, 200,000 dollar exit cost in exchange for a 15 percent lower run rate is not. It arrives wrapped in technical context, but it is a risk-appetite question, and risk appetite is not an engineering discipline. Engineers cannot answer it alone, not for lack of intelligence but for lack of mandate. Asked to guess, they guess by temperament, and the organisation inherits a temperament instead of a decision. Your job is to own that second kind completely, refuse the first kind completely, and be explicit about which is which.

You are not there to say which platform. You are there to say what the business cannot accept, in writing, before anyone chooses.

The Five Questions

These five go on the agenda of every platform conversation you attend. Each is genuinely a business question, each has a shape of good answer and a tell that marks a bad one, and none requires you to know what a vector store is.

Question 1: What does this commit us to, and for how long?

This is the lock-in question, almost always asked badly. Asked philosophically ("are we worried about lock-in?") it produces a philosophical answer ("we are mindful of it") and changes nothing. Asked concretely it produces a number: what would it cost in money, weeks, and disruption to move our top three use cases off this platform in two years?

That number is the exit-cost estimate, a required artifact rather than a courtesy, computed with IT and never asserted by either side. "We could migrate if we needed to" is not an answer, it is a feeling. A real answer sounds like this: roughly 10 weeks and 90,000 dollars, mostly re-integration and re-testing rather than data movement, assuming the vendor exports our documents and correction history in the formats their contract guarantees.

That sentence contains a duration, a cost, a decomposition showing where the cost sits, and an assumption stated out loud. The last clause matters most, because the estimate's assumptions become contract requirements. If the estimate holds only when export in named formats is available on demand, that goes into the contract before signature, tested during onboarding rather than trusted. This is the Chapter 4.2 exit-clause standard with a number attached, which turns a clause the vendor concedes into one your finance function cares about. Price the duration too: a ten-week exit during which four processes run in parallel and error rates rise is an operational event needing a window, and windows are scarce.

The tell of a bad answer: anything in the conditional mood. "It would be a lift." "Nothing is impossible." Treat as bad any estimate produced in a day by one person, and as a red flag any vendor who will not describe their export mechanism concretely.

Question 2: How does the cost behave as we succeed?

AI platforms differ most sharply here from the enterprise software your procurement instincts were trained on. Classic software is priced per seat per year and the bill is roughly flat: you know in January what you owe in December. Most AI platforms are priced on consumption: tokens processed, documents ingested, agent runs executed, minutes transcribed. Consumption pricing means the bill grows with adoption, a trap unique to this technology: a successful rollout produces a budget surprise that reads as a failure. You fight for adoption for a year, you win, volume triples, and the finance business partner opens a variance review on a line item 180 percent over plan. Nobody there is celebrating that the tool got used, and the strategist who did not model this looks, at the moment of victory, like someone who cannot forecast.

The discipline is simple and almost nobody does it: model the cost at three times and ten times current volume before signing anything, not as a doomsday scenario but as the plan. Three times is the rollout working as intended; ten times is it working and two adjacent functions adopting it, which is the outcome you are aiming for. Put both in the business case beside the benefit numbers, so the cost curve and the value curve are read together rather than the second arriving eighteen months after the first.

Then negotiate against the model. Get the price-break structure in writing before signing, tiers named and rates specified, because the moment to secure a better unit rate at 3x volume is while the vendor still wants the logo. This is the procurement counterpart of Level 3's cost-per-case metering: there you instrumented what a case costs, here you make that number contractual before it exists. Then ask, plainly: what happens to price at renewal, once we are dependent? Honest vendors answer with a cap, an index, or a named uplift ceiling; vendors who deflect into relationship language have told you their renewal strategy. Gartner's projection that over 40 percent of agentic AI projects will be cancelled by the end of 2027 lists escalating costs among the leading drivers, alongside unclear business value and inadequate risk controls. Projects are rarely cancelled because the technology stopped working, they are cancelled because the economics were never modelled at the volume success produces.

The tell of a bad answer: a per-seat quote for a consumption-priced product, which usually means someone converted the vendor's pricing into a familiar shape and lost the mechanism doing it. Also: "we will monitor usage and manage it." Managing usage down is managing adoption down, which is unwinding the value case.

Question 3: What does it refuse to do?

Every platform evaluation you have seen was organised around capability: what can it do? That framing is a gift to the vendor, because the demonstration was built precisely to answer it. Reframe: do not ask what the platform can do, ask what it cannot do and what that costs us.

The list of refusals is the honest capability description, and it is where your Level 3 specification work becomes a selection criterion. There you specified grounding (making the system answer from your documents rather than its training data, commonly called retrieval-augmented generation or RAG), output schemas (a fixed, named field structure the system must emit so downstream systems consume it without a human retyping anything), and agent controls (scope limits, permitted actions, escalation triggers). Those are the boundary conditions of use cases you have already committed to, and a platform either clears them or vetoes the work. Ask in business language, yes or no required for each:

• Can it emit our schema? Not structured output in the abstract, but the specific fields, types, and identifiers our downstream systems require, and what happens on a field it cannot populate.
• Can it be permission-aware over our documents? Does it search only what the asking user is already entitled to see? A platform that indexes everything and answers everyone is a data-leak incident with a search box on it.
• Can it retain nothing? Can we prevent inputs and outputs being retained, logged beyond a defined window, or used for training, and prove it rather than be promised it?
• Can it run in our required jurisdiction, for every subprocessor including the model provider?
• Can it be turned off per function? If legal must suspend one department during an investigation, is that a switch or a project?

Write the refusals down and price them. A platform that cannot do permission-aware retrieval has not disqualified itself, it has told you one class of use case cannot live there. That is a governable fact in the record on day one and a crisis when a project team discovers it in month nine, with a plan built on the assumption and a budget built on the plan.

The tell of a bad answer: "that is on the roadmap." Roadmap is not capability. Either the item is contractually committed with a date and a remedy, or the use case is planned as if it will never arrive. Treat "yes, with configuration" as a maybe until IT says what the configuration is and how long it takes. Gartner's agent-washing finding is the cautionary tale: of thousands of vendors claiming agentic capability, only around 130 were judged genuinely to offer it. The capability question invites that gap; the refusal question exposes it, because vapour finds specific negatives much harder to fake than specific positives.

Question 4: Who else has to change?

This is the integration question asked in organisational rather than technical terms. The technical version ("can it integrate with our enterprise resource planning system?") gets a technical answer ("yes, there is an API"), which is true and nearly useless. An application programming interface (API) existing is not an integration happening. Integration happens when named teams spend weeks of capacity they already promised elsewhere.

So ask the organisational version: which systems does this touch, which teams have to build or change something, and whose roadmaps does that consume? An AI platform requiring eight weeks of the enterprise resource planning (ERP) team's capacity in the third quarter is not an AI decision. It is an enterprise sequencing decision, and it belongs on the roadmap as a dependency arrow with the same weight as any other. The Chapter 4.1 roadmap has those arrows for a reason: they are how a portfolio avoids discovering in week 30 that two funded initiatives need the same six people.

Here the strategist provides value nobody else can, the antidote to feeling like the least qualified person present. You are frequently the only person in the room who can see the collision. The architects know their domain, the vendor its product, the IT lead his bench. You have read the enterprise roadmap, sat in the ERP steering committee, and know the go-live moves hypercare into the exact weeks this integration wants. That is a portfolio insight, not a technical one, and it is worth more than the technical opinion you were tempted to fake.

Get the answer as a named list: system, owning team, estimated weeks, quarter, and the person who agreed. "IT will handle the integration" is how a five-week dependency becomes fifteen, because nobody with authority to protect the capacity ever saw the request. The tell of a bad answer: passive voice. "The connectors will be configured." By whom, in which weeks, at the expense of what? Work with no owner and no window has not been costed.

Question 5: What happens when it changes under us?

This question is earned by scar tissue. In Level 3 you met the drift incident: a vendor updated the underlying model on a Tuesday, output distributions shifted overnight, an extraction step began returning a field in a different shape, and a team spent nine days investigating a "quality problem" in their own process that was in fact a silent change under their feet.

Traditional software changes on a release calendar you can see. AI platforms change continuously and sometimes invisibly: model versions swapped, capabilities deprecated, features removed when they prove unprofitable, vendors pivoting or being acquired. Volatility is not an edge case here, it is the weather. Three sub-questions, all business questions:

1. What notice do we get? A specific number of days, in the contract, for model changes, deprecations, and product sunsets. Ninety days is a reasonable ask for deprecation, notification with a testing window for model changes.
2. What testing burden does each change impose? The one people forget, and a recurring cost rather than a one-off. Every notified change triggers your own regression discipline: the canary set and evaluation-suite rerun from Level 3. If a re-test costs four days and the vendor ships four notified changes a year, that is sixteen days of platform tax belonging in the run-rate line where finance can see it. A platform that changes twice a year and one that changes monthly have very different total costs at identical list prices.
3. What is our position if a capability we depend on is retired? Not "would they do that" but "what do we do when they do." A committed successor path, a migration allowance, an extended support term, or nothing?

How a vendor handles this separates platforms that treat enterprises as partners from those that treat them as traffic. Consumer-scale providers ship changes to everyone at once because that is their economics; enterprise providers accept that a customer with 40 integrated workflows needs notice and a stable version, and price it. Neither posture is dishonest; buying the first while assuming the second is the mistake. The tell of a bad answer: "we always improve, never break." Improvement in a probabilistic system means a changed output distribution, and that can break a downstream rule tuned on the old one.

The Division of Labour, Made Explicit

The five questions only work if the room understands why you are asking, so the division of labour has to be stated rather than assumed. Stated, it protects your credibility; assumed, it reads as encroachment, which triggers the reflex that ends collaborations.

Now the sentence that makes it work. Say it out loud, early, before you ask a single question:

"I am not going to tell you which platform. I am going to tell you what the business cannot accept, and I need your judgment on which options clear that bar."

That sentence disclaims the technical decision, removing the threat; asserts a domain unambiguously yours, which nobody in the room wants anyway; and converts architects from defendants into advisors, the role they would rather have. Turf conflicts at this layer are almost always caused by ambiguity about who decides what, and naming the split dissolves most of them while obliging the technical side to treat your business constraints as the input to their recommendation rather than a critique of it.

The Artifact: the Platform Decision Record

The output is one document, this lesson's named artifact. A Platform Decision Record (PDR) is one to two pages per platform, containing five things:

1. The five questions with their answers, in business language, with numbers where numbers exist.
2. The assumptions each answer depends on. The exit estimate assumes export formats, the cost model a volume profile, the refusal list a product version. Assumptions are where records rot, so trace each to a contract clause or a monitored fact.
3. The review trigger, a condition rather than a date: volume passing the 3x tier, a vendor pricing announcement, a refusal claimed to be resolved, or renewal minus six months, whichever comes first.
4. The decision and the options not taken, two sentences each, so the next strategist inherits the reasoning rather than only the outcome.
5. Two sign-off lines, side by side: business and technical. Same page, same date, both names.

The side-by-side sign-off is not ceremony, it is the mechanism. A single signature makes the decision one function's problem, which is exactly what abdication and pretense both produce. Two signatures on one page make it a joint commitment with a shared record, which is what you want on the desk in month twenty-two when someone asks why the bill moved.

The Platform Portfolio: Two to Four Is Usually Right

There is a reflex, common in strategists new to this layer, to treat multiple AI platforms as indiscipline and campaign for consolidation onto one. Resist it. Most enterprises correctly end up with two to four, because the layer is not homogeneous:

• A general assistant tenant: per-seat or hybrid pricing, used by everyone for drafting, summarising, and analysis. Its governance problems are data handling and verification behaviour.
• One or two embedded capabilities inside existing systems: the AI features in the customer relationship management suite, the service desk, the ERP. You did not choose the underlying model and often cannot swap it. Their problems are lock-in and pricing changes.
• Possibly a workflow or agent platform, where multi-step, tool-using automations live. Its problems are scope control, volatility, and cost at volume.

These serve different jobs, and forcing them onto one substrate usually means a bad fit for two of the three. Consolidation for its own sake is a preference, not a policy. What you defend against is not multiplicity, it is proliferation without policy. Two platforms chosen deliberately, each with a Platform Decision Record, is a portfolio. Seven bought independently by six functions, none with a record, four with overlapping capability, three with data-retention terms nobody has read, is the shadow-IT problem reappearing one layer up, and worse here because these substrates accumulate data, integrations, and dependency.

The defence is a standing rule agreed once at the steering committee: a new AI platform enters only through the sourcing policy and only with a Platform Decision Record. Not a new approval body: the existing Chapter 4.2 policy plus one document. Anything already in the estate gets a record retroactively at renewal, in priority order by spend and processes touched.

Worked Example: One Record, and One Invisible Commitment

Return to this level's enterprise storyline: eleven portfolio items sourced as seven buy, three partner, one internal glue build; vendor A already carrying four of the eleven; an IT function with real capability and a real backlog. Four items (claims triage, supplier onboarding, contract abstraction, the internal policy assistant) are candidates for a shared workflow-AI substrate, which needs a Platform Decision Record. All figures below are hypothetical and illustrative, chosen to show the shape of the arithmetic rather than to predict your prices.

Signed on one page by the transformation director and the head of architecture, same date. Review trigger: volume crossing the 3x tier, a pricing announcement, resolution of the retrieval gap, or renewal minus six months.

That one document moved a use case before anyone planned on a false assumption, bought a price break, surfaced a roadmap collision while moving was cheap, turned an unbudgeted recurring cost into a line item, and fixed the exit position while the organisation still had leverage.

The portfolio note is short: three platforms in the estate, each now with a record. A fourth tool, bought independently by one function on a departmental card fourteen months ago and now used by 40 people, comes under policy at renewal in five months rather than being ripped out today. Enforcement at renewal is cheap and uncontested; mid-term it is a political fight that spends credibility you will need next.

The Failure Story: the Commitment That Felt Like It Cost Nothing

A 1,400-person professional services company never held an architecture review at all, because there was nothing to review. Their incumbent enterprise suite, already contracted, deployed, and integrated with everything, switched on an AI capability at no additional charge. No procurement event, no evaluation, no comparison, no record. The path of least resistance was also the path of zero visible cost, and the organisation took it the way organisations take free things: without a decision.

Over eighteen months four use cases grew on it: proposal drafting, engagement summarisation, timesheet narratives, and a client-facing knowledge surface. All useful, all quietly load-bearing, each writing its outputs into the suite's proprietary objects because that was the frictionless way to build them.

Then the vendor restructured its AI pricing. What had been bundled became per-user-per-month across all licensed seats, not just those using it, and the effective cost of AI at the company tripled. The finance director asked the obvious question: can we move these four workloads somewhere cheaper? The answer took three weeks and was worse than anyone expected. The outputs lived inside proprietary objects with no documented export path. Configuration, prompt libraries, and eighteen months of accumulated corrections were not extractable in any structured form. Two workflows were wired into suite-native automations with no equivalent elsewhere. IT's estimate for exit was seven months, optimistically, contingent on rebuilding rather than migrating three of the four. The company paid the new price and will keep paying it, because seven months of disruption to billable work against an increase they can absorb is not a trade any sensible executive takes.

The autopsy is short. What does this commit us to? Never asked, because there was no procurement event to attach the question to. How does cost behave as we succeed? Never asked, because the cost was zero, and zero has no curve until it does. What does it refuse to do? Never asked, so nobody noticed that "export our outputs" belonged on the refusal list. Who else has to change? Nobody, which was the appeal, and why no one with a roadmap view ever looked. What happens when it changes under us? Never asked, because there was no clause, because there was no negotiation.

The decision that felt like it cost nothing was the most expensive platform decision the company made in five years, and the mechanism is a rule: "already in the contract" is the phrase that bypasses all five questions, and free adoption is the most under-governed path into lock-in that exists. Deliberate purchases trigger procurement and some scrutiny; bundled capabilities trigger nothing and accumulate dependency at the same rate. A standing rule that fires only on a purchase order will miss the platform decisions most likely to hurt you.

Set this against the wider record. MIT's GenAI Divide research found 95 percent of enterprise generative AI pilots delivered no measurable profit-and-loss return, and that externally partnered solutions succeeded roughly twice as often as internal builds: partnering works, which is why the substrate it all runs on deserves governance proportional to its leverage. Gartner's 40 percent agentic cancellation projection names escalating costs among the drivers, which is question 2 in a sentence. Abdication and pretense both end in those statistics, and the five questions are the way out of both without pretending to be an engineer. Because every platform arrives attached to a vendor, the standing risk programme governing those vendors after signature is the next lesson.

What to Do Monday Morning

Every step below is doable with no technical authority.

1. Put the five questions on the agenda of your next platform conversation, as five lines circulated beforehand, and open with the collaboration sentence. Circulating them in advance turns them from an ambush into a working session.
2. Commission one exit-cost estimate, computed with IT rather than asserted, for the platform carrying the most portfolio items. Ask for money, weeks, and the assumptions it depends on, then take those assumptions to whoever owns the contract and ask which are written down.
3. Model your leading option at 3x and 10x current volume before signing anything: two extra spreadsheet rows, placed in the business case beside the benefit numbers, with the 3x number taken into the negotiation while the vendor still wants the deal.
4. Write the refusal list for your leading option: five yes-or-no answers on schema, permission awareness, retention, jurisdiction, and the per-function off switch, with the use case each "no" kills named beside it. Usually the fastest hour of value in the process.
5. Open a Platform Decision Record with both sign-off lines already on the page, drafted empty with the two names typed in. An empty record with two signature blocks is a surprisingly effective way to get five questions answered, because it makes visible what is missing and who owes it.
6. Inventory the platforms you did not buy: every AI capability switched on inside an existing suite. Those are platform decisions made without a decision, and each needs a record at renewal.

Key Takeaways

• Reject both failure modes: abdication inherits a substrate you cannot exit, forecast, or claim to have chosen, while pretense costs you credibility with the people whose judgment you need.
• Separate the two kinds of question: feasibility belongs to IT, business consequence (exit cost, cost curve, refused capabilities, dependencies, volatility) belongs to you, because it encodes risk appetite engineers have no mandate to set.
• Demand an exit-cost estimate in money, weeks, and stated assumptions, computed with IT rather than asserted, then convert those assumptions into contract clauses: "we could migrate" is a feeling, "10 weeks and 90,000 dollars assuming guaranteed export formats" is an answer.
• Model consumption cost at 3x and 10x current volume before signing, negotiate the price break at the 3x tier while the vendor still wants the logo, and ask plainly what happens to price at renewal once you are dependent.
• Ask what the platform refuses to do rather than what it can do, since the demo answers the second question, and price every refusal against the use case it kills.
• Translate integration into organisational terms (which systems, which teams, whose quarters), because a platform needing eight weeks of ERP capacity is a sequencing decision and you may be the only person who sees the collision.
• Contract for volatility with notice periods and change notification, then budget your re-test burden as a recurring platform tax rather than meeting it as unplanned effort four times a year.
• Keep two to four platforms deliberately rather than forcing consolidation, but let none enter except through the sourcing policy and a signed Platform Decision Record, with the rule written to fire on adoption rather than spend, because "already in the contract" is the cheapest-looking path into the costliest lock-in.