A government order took Fable 5 offline overnight. The CAD and database eras already taught engineering software the answer: build your value above the platform, not inside it.
I ended this week reading that a frontier AI model had been switched off by government order.
On Friday evening, Anthropic received an export control directive from the US Commerce Department, citing national security authorities. The directive ordered the company to suspend access to its two newest and most capable models, Fable 5 and Mythos 5, for any foreign national, whether inside or outside the United States, including Anthropic’s own foreign-national employees. Because complying with that rule at the required granularity was impractical, Anthropic disabled both models for every customer worldwide. The models had been publicly available for three days. Anthropic disputes the order, calls it a misunderstanding, and says it is working to restore access, with no firm date.
The specific event matters less than the shape of it. Whether the model comes back next week or the dispute drags on, something happened on Friday that every engineering software builder should sit with. A capability that thousands of applications could have been built on became unavailable overnight, not because of a price change or a deprecated API, but because a third party that most builders never even consider in their architecture decided the model could not ship. The vendor wanted to serve its customers. It could not.
For me, this felt familiar in a way that took a minute to place. I have watched the same lesson arrive twice before, in two different technology cycles, and the people who learned it early were the ones still standing when the cycle turned. It leads to model independence.
Model independence is the practice of building engineering and PLM software so that the underlying AI model is a replaceable component rather than a fixed dependency, keeping the application’s value in its data, integration harness, and workflows so that a change in model availability, pricing, or regulation does not break the product.
The CAD Police Decided Who Could Build
When I was building CAD applications years ago, access to the CAD platform was the whole game. The vendor controlled the API, the file formats, and the terms, and that control decided who got to build a business on top.
Some vendors understood that an open platform multiplies its own value. Autodesk is the cleanest example. By making AutoCAD and AutoLISP genuinely accessible to developers, it seeded an ecosystem of thousands of specialized applications that made the core product more valuable than Autodesk could ever have made it alone. SolidWorks did the same, especially with the release of Document Manager API that can run without SolidWorks. Other vendors treated third-party developers as a threat. APIs were thin, access was negotiated, and compatibility was a permission you asked for rather than a foundation you stood on. We called them the CAD Police, and building on their platforms meant accepting that your roadmap was partly theirs.
The lesson we took from that era was blunt. Never build your business on the assumption that another company will always grant you access on terms you like.
The Database Wars Taught Us to Build Above the Engine
When I moved into PDM and PLM, the same lesson returned wearing different clothes. This time it was not CAD. It was the database.
If you wanted to sell into a large organization, IT had requirements, and those requirements were not negotiable. Oracle. SQL Server. DB2. Postgres. Sometimes all of them in the same account. If you sold through a partner, the partner’s installed base decided for you. An IBM channel expected DB2. Some others preferred Oracle. Microsoft accounts liked MS SQL. The relational engine underneath mattered far less than the customer’s right to choose it.
So the winning move was not to bet on the best database. The winning move was to build the application so that the database underneath was replaceable. The data model, the business logic, the workflows, all of that stayed portable, and the engine became an implementation detail the customer could swap. Applications that were built that way could be sold anywhere. Applications welded to one engine could only be sold where that engine was already blessed.
The New Twist Is That the Gatekeeper Now Has a Gatekeeper
Here is what makes the AI cycle different, and why Friday’s news is worth more than a shrug.
In the CAD era, the gatekeeper was the vendor. In the database era, the gatekeeper was IT and the channel. In both cases you were negotiating with a party that wanted your business and had commercial reasons to keep serving you. The AI era adds a layer neither of the earlier cycles had. The vendor is no longer the final gatekeeper. A government, a regulator, or an export-control authority can override the vendor entirely, and the vendor’s own commercial wishes become irrelevant. Anthropic did not decide to cut off its customers on Friday. It was instructed to, and it had no practical way to comply narrowly.
That changes the risk calculation for anyone embedding a frontier model into engineering software. Model availability is no longer just a pricing question or an uptime question. It is simultaneously a compliance event, a vendor-risk event, and a production-continuity event, and all three can fire at once with no warning. If your PLM AI feature only works when one specific model answers the call, then your product’s availability is now downstream of decisions made by people who have never heard of your product.
There is a small detail in Friday’s events that proves the point and also points at the answer. When Fable 5 went dark, queries did not simply fail. Sessions routed automatically to Anthropic’s next-most-capable model, Opus 4.8, which was unaffected by the directive. The teams that felt the least pain were the ones whose systems already treated the model as a slot rather than a fixture. That is model independence working in real time, and it is the same instinct that let portable applications survive the database wars.
Your Value Lives in Data, Harness, and Workflows
For the engineers building PLM, manufacturing, and industrial software, the practical conclusion is almost boringly familiar, which is exactly why it is trustworthy. Your defensible value sits in three layers, none of which is the model.
The first is data. Models arrive and depart, but engineering data accumulates. A company’s BOMs, CAD files, requirements, supplier records, change history, and the relationships between all of them represent years of organizational knowledge that no model contains and no directive can switch off. The model is a way to interact with that data. It is not the asset.
The second is the harness, by which I mean everything that connects a model to that knowledge and makes its output trustworthy. The connectors, the context retrieval, the validation rules, the permission and access logic, the pipelines that decide what reaches the model and how its answers are checked before anyone acts on them. As raw model capability commoditizes, this layer is where reliability and differentiation actually live. A well-built harness can point at a different model on Monday than it pointed at on Friday, and the engineer using it should barely notice.
The third is workflow, and this is where the real differentiation has always lived. Engineering change processes, release management, procurement approvals, supplier collaboration, manufacturing planning, quality control. These encode how a specific company actually operates. A model can assist these processes, accelerate them, and sometimes reveal something in them, but it does not define them and it cannot replace them. The software that understands and automates a company’s workflows keeps creating value no matter which model is answering underneath.
Model Independence Is the New Portability
What is my conclusion today ? I increasingly think AI models will end up where databases ended up. Important, strategic, worth choosing carefully, and not where most of the application’s value resides. Customers will demand the same flexibility they demanded with databases. Some will prefer one provider, some will standardize on another, some will run local or open models for data they will not send anywhere, and many large enterprises will require the ability to mix and switch on their own terms.
In the CAD era, platform openness decided who could build an ecosystem. In the database era, portability decided who could sell into the enterprise. In the AI era, model independence is shaping up to be the trait that decides who survives a Friday-evening directive with a routing change instead of an outage.
A reference architecture for engineering AI is starting to take shape, and it reads from the top down, with value concentrated at the top and replaceability increasing toward the bottom:
Applications and Workflows: where engineers work, and where your differentiation lives.
Product Memory: the organized, persistent context that gives any model something real to reason on.
Data Sources: the BOMs, CAD files, requirements, supplier records, and change history the organization owns.
AI Harness: the layer that connects, retrieves, validates, and governs what passes between the knowledge above and the model below.
Foundation Models: powerful, improving, and interchangeable.
What happened on Friday touched only the bottom layer. Everything above it kept its value, and the systems built this way rerouted to another model and carried on. That is the whole argument in one picture. The single layer that a directive can switch off is the one layer you should never build your business inside.
The lesson has not changed across three cycles. Build your value above the platform, not inside it.
Disclosure: I am the co-founder and CEO of OpenBOM. The same conviction runs through how we build there: keep the value in connected product data and context, and treat the model underneath as replaceable.
Frequently Asked Questions:
What happened with Anthropic’s Fable 5 model?
On June 12, 2026, Anthropic received a US Commerce Department export control directive citing national security authorities, ordering it to suspend access to Fable 5 and Mythos 5 for any foreign national. Because narrow compliance was impractical, Anthropic disabled both models for all customers worldwide. Its other models, including Opus 4.8, were not affected, and the company says it is working to restore access.
Does this affect all Anthropic AI models?
No. The directive covered only Fable 5 and Mythos 5. Opus 4.8 and the other Claude models remained available, which is why many teams used Opus 4.8 as an immediate fallback.
What does the Fable 5 suspension mean for PLM and engineering software?
It shows that frontier model availability can become a compliance, vendor-risk, and production-continuity event simultaneously and without warning. PLM AI products that treat the model as a replaceable slot rather than a fixed dependency can absorb such an event with a routing change instead of an outage.
How should PLM AI software protect itself from model disruption?
By keeping defensible value in three layers that no model controls: the engineering data, the integration and validation harness, and the workflows, while keeping the model itself interchangeable.
