A head of learning has three proposals on the desk and a board meeting on Thursday. Option one: use the AI built into the authoring tool the team already owns. Option two: adopt the AI baked into a new LXP platform that promises to run the whole learning experience. Option three: have a small internal team compose a custom assistant on top of a general model, grounded on the company's own knowledge base. Every proposal leads with a feature list, and every feature list is irrelevant. The decision that matters is not which tool does the most. It is which choice she can still verify, still audit, and still walk away from in three years. Lock-in and verifiability, not features, are the real axes, and learning to weigh on them is the whole subject of this lesson.

The Feature List Is a Distraction

Every AI vendor sells on features, because features demo well and compare cleanly on a spreadsheet. Does it generate video? Does it have an avatar? Does it auto-translate? The trouble is that features converge. Within a year, every serious tool in a category has roughly the same checklist, so a decision made on the feature list is a decision that will look arbitrary in eighteen months. The two things that do not converge, and that you will live with for years, are how locked in you are and how verifiable the output is. Those are the axes a strategist actually decides on.

Two terms anchor this lesson. Lock-in is the cost of leaving: how hard it is to get your content, your data, and your workflows out of a tool and into something else, including whether your grounding sources and your accessibility work transfer or have to be rebuilt. Why you care: lock-in is the price you do not see at purchase and pay at renewal, when the vendor knows you cannot easily leave. Verifiability, carried forward from earlier in this chapter, is whether you can trace any claim the tool produces back to an approved source and prove conformance, fast enough to defend at audit. Why you care: a tool you cannot verify is a tool you cannot defend, no matter how many features it has.

The reframe is to stop asking "which tool does the most" and start asking two harder questions. If this tool is wrong, can I catch it, and if this relationship sours, can I leave. A tool that scores high on features but low on both of those is not a capability, it is a trap with a good demo. The three paths, buy, compose, and build, sit at different points on those two axes, and the strategist's job is to place each one honestly rather than be sold the feature list of whichever is in the room.

Features converge within a year. Lock-in and verifiability you live with for years. Decide on the things that last, not the things that demo.

The Three Paths as a Category Map

The choices form a category map, taught vendor-neutrally, with named examples only to orient you and never as endorsements. The obligation to verify and to stay accessible does not transfer to any platform on this map.

Buy: The AI Baked Into a Platform

The buy path is adopting AI that comes built into a tool you purchase: the AI assistant inside an authoring tool (the category includes tools like Articulate Rise 360's assistant, Adobe Captivate, iSpring) or the AI native to an LXP or LMS (the category includes platforms like Docebo, Sana, Cornerstone, 360Learning). The appeal is speed and integration: it works inside the workflow your team already knows, with nothing to build. The cost is on both axes. Lock-in is high, because your content, your grounding, and your generated assets live inside the platform and often cannot leave cleanly. Verifiability depends entirely on what the vendor chose to expose: if the platform cites sources and produces a conformance report, you can defend it, and if it generates content as a black box, you cannot, and you have no way to add the transparency it lacks.

Compose: A Custom Assistant on a General Model

The compose path is assembling your own assistant by grounding a general-purpose model on your knowledge base, your policies, SOPs, and SME content, using configuration rather than deep custom engineering. The category includes grounded copilots and retrieval-augmented assistants built on a foundation model the vendor maintains. The appeal is verifiability and control: because you choose the grounding sources and the retrieval, you can make the tool cite your documents and refuse outside them, which is exactly the source transparency an auditor wants. Lock-in is moderate: the model underneath is the vendor's, but your grounding sources, your prompts, and your configuration are portable assets you can carry to a different model. The cost is that you own more of the verification and accessibility work yourself, because no vendor is doing it for you end to end.

Build: A Bespoke System

The build path is engineering a custom learning-AI system largely from the ground up. The appeal is total control: you decide everything, including verifiability and accessibility by design. The cost is that you now own everything, the maintenance, the model updates, the accessibility conformance, the security, the moment the underlying model changes and your carefully tuned system drifts. For most learning functions this is the wrong path, not because control is bad but because the L&D function rarely has the engineering capacity to sustain it, and a bespoke system you cannot maintain is more dangerous than a bought one you can leave. Build is justified only when your need is genuinely unique and your engineering capacity is genuinely real.

Weighing the Paths on the Axes That Matter

Place the three paths on the two axes and the decision stops being a feature comparison and becomes a strategic trade-off you can defend to a board.

It is worth being precise about what "verifiability you control" means in each row, because it is the column that most often decides the outcome and the one shoppers most often misread. In the buy path you control nothing about verifiability; you inherit whatever the vendor decided to expose, and if that is a black box, no effort on your side can add a source citation the platform does not produce. In the compose path you control verifiability directly, because you choose the grounding sources, you set the instruction to cite or refuse, and you can inspect the retrieval, so the tool's defensibility is a property you engineer rather than a property you hope for. In the build path you control everything, including verifiability, but only for as long as you can sustain the system, so your control is real but conditional on a capacity most learning functions do not have. The single most expensive misjudgment in this whole decision is to assume you can fix a bought black box later; you cannot, and that assumption is how regulated functions end up locked into tools they can never defend.

Read the table as a strategist, not a shopper. The buy path trades verifiability and exit for speed, which is acceptable only if the platform is genuinely audit-grade on the gates from earlier in this chapter, because if it is a black box, high lock-in means you are stuck with a tool you cannot defend. The compose path is the sweet spot for most regulated learning functions, because it gives you the source transparency an auditor needs and keeps your grounding portable, at the cost of owning more of the verification work, which you should be owning anyway. The build path is a commitment to permanent ownership that most L&D functions cannot honor, and the honest strategist names that out loud rather than being seduced by total control.

A Worked Example: The Three Proposals

Return to the head of learning with three proposals and a board on Thursday, evaluating for a regulated compliance and safety curriculum.

The feature-list trap. Read on features, the LXP buy proposal wins easily: it has the longest checklist, the most polished demo, and the promise to run the whole experience. So she almost picks it. Then she applies the axes. The LXP generates content as a black box with no source citation, so on the verifiability gate it fails, she cannot trace a regulated claim to a source, and the lock-in is total, so a failed tool is a tool she is stuck with. The feature list was leading her toward the least defensible option, because the feature list never measures the things that matter at audit.

The axes-based decision. She re-scores all three on lock-in and verifiability. The authoring-tool buy is low-effort but its AI is opaque, failing verifiability for regulated claims. The bespoke build offers total control but her function has two instructional designers and no engineers, so the maintenance burden is unsustainable, and an unmaintainable system is a future incident. The compose path lets her ground a maintained foundation model on the company's approved SOPs and policies, so the assistant cites the source and refuses outside it, passing the verifiability gate, while the grounding sources stay portable, keeping lock-in moderate. She chooses compose, and on Thursday she does not show the board a feature list. She shows them that she picked the option she can verify at audit and walk away from in three years, and that the obligation to verify never left her function for the platform.

The lesson is not that one path is always right. It is that the right path is the one that survives the two questions the feature list cannot answer: if it is wrong, can I catch it, and if it sours, can I leave. The LXP had the best features and the worst answers to both. The compose path had a shorter feature list and the best answers, and at a board meeting about a regulated curriculum, the answers are the only thing that matters.

It is worth dwelling on why the LXP's lock-in is not a minor inconvenience but the thing that converts a bad tool into a permanent one. Lock-in compounds. Once the LXP holds your content, your learner data, your generated assets, your competency taxonomy, and your reporting, every additional course you build inside it deepens the dependency, and the cost of leaving grows with every month. By the third renewal the vendor knows exactly how trapped you are, and the negotiation is no longer between equals. A tool you cannot verify is bad on day one; a tool you cannot verify and cannot leave is bad forever, and forever is the timescale a strategist is accountable for, not the timescale of the demo.

The Hybrid Reality and the Renewal Clock

Real decisions are rarely a clean choice of one path. The mature strategist often composes a portfolio: buy the platform for low-stakes delivery and operations where lock-in is tolerable and the content is not regulated, and compose a grounded, citing assistant for the regulated and safety content where verifiability is non-negotiable. This hybrid is frequently the most defensible real-world answer, because it confines the black-box trade-off to the content that can survive it and keeps the high-stakes claims on tooling you control. The discipline is to decide path by content criticality, not to pick one tool and force all content through it because procurement prefers a single contract.

The second discipline is to treat the decision as a position you maintain, not a bet you place once. Vendors mature: a platform that ships as a black box this year may add source citation and a conformance report next year, moving from the un-defendable quadrant toward audit-grade. Conversely, a vendor you trusted may be acquired, change its data terms, or deprecate the model your build depended on. The renewal is the moment to re-test both axes honestly: has the verifiability gap closed, has the lock-in deepened past what you can accept, do your grounding sources still transfer. A path chosen well in 2026 can become a trap by 2029 if nobody re-asks the two questions, so the strategist puts a recurring review on the calendar rather than signing and forgetting.

This is also where the earlier chapter lessons converge into one adoption discipline. Procurement gates whether a tool can verify, conform, and protect data in principle. The privacy lesson decides whether the data terms keep your learners out of someone else's model. The pilot proves quality on a small scope before scale. And the build-versus-buy-versus-compose decision selects the path whose lock-in and verifiability let all of that hold over the years the relationship will actually last. Treated separately they are four checklists; treated together they are a single, defensible answer to the only question that survives a board meeting about a regulated curriculum: can we trust what this produces, and can we walk away if we stop trusting it.

A tool you cannot verify is bad on day one. A tool you cannot verify and cannot leave is bad forever, and forever is the timescale a strategist answers for.

The Decision Questions to Carry

• If this tool is wrong, can I catch it? Verifiability: does it cite sources and refuse outside them, or is it a black box?
• If this relationship sours, can I leave? Lock-in: do my content, data, and grounding sources transfer, or are they trapped?
• Who owns the verification and accessibility work? Buy shares it but cannot add what the platform lacks; compose and build put it on you, by design.
• Do I have the capacity this path demands? Build requires durable engineering; compose requires configuration capacity; buy requires only that the platform be audit-grade.
• Do my grounding and accessibility assets transfer? Portable grounding is the asset that survives a vendor change; trapped grounding is lock-in by another name.

Key Takeaways

• Features converge within a year and demo well, so a decision made on the feature list looks arbitrary in eighteen months; lock-in and verifiability are the axes you live with for years.
• Lock-in is the cost of leaving, the price you do not see at purchase and pay at renewal; verifiability is whether you can trace any claim to a source and prove conformance fast enough to defend at audit.
• The three paths form a vendor-neutral category map: buy the AI in a platform, compose a grounded assistant on a general model, or build a bespoke system, and the obligation to verify never transfers to any of them.
• Buy trades verifiability and exit for speed and integration, acceptable only if the platform is genuinely audit-grade, because high lock-in plus a black box means you are stuck with a tool you cannot defend.
• Compose is the sweet spot for most regulated learning functions: you choose the grounding, so the assistant cites and refuses, and your grounding stays portable, at the cost of owning more of the verification work you should own anyway.
• Build offers total control but commits you to permanent ownership of maintenance, accessibility, and model drift, which most L&D functions cannot sustain; an unmaintainable system is more dangerous than a bought one you can leave.
• The two questions the feature list cannot answer decide the path: if the tool is wrong, can I catch it, and if the relationship sours, can I leave, and the best feature list often gives the worst answers to both.
• The iron rule holds across all three paths: AI assists, the human verifies, the human owns the decision, so the right path is the one that keeps the verification in your hands and the exit open, not the one with the longest checklist.