Part 2 of my PTC Next 2026 series. In Part 1 I asked whether “intelligent” PLM is a new architecture or just a new label, and I promised to test PTC’s actual pieces. This is the first test, and it’s about the most consequential structural choice in the strategy: the decision to build two layers instead of one.
In Part 1, I ended on a gap. A data foundation tells you what the data is: the parts, the BOMs, the items, the telemetry. It does not, by itself, tell you why a decision was made. And the rep at the booth conceded that the layer which would capture the why mostly isn’t built yet.
Going back through my notes from Chicago, I realized PTC is, in effect, trying to close exactly that gap, and the way they’re doing it is the most interesting architectural decision at the event. They are not pouring everything into one system. They are building two layers: the existing systems of record, preserved and connected in the thread, and a new layer on top of them where product data is supposed to become usable. Orbit and Jetstream are the evidence.
That is the right shape. It’s also where the hard question lives. So I want to set the news aside and ask one thing: how far, and how clean, can PTC actually keep those two layers?
The Signal Worth Naming
Let me start above PTC, because the important thing here is bigger than any single launch.
PTC opened with an IDC figure: nine in ten executives now name a product data foundation as critical. Take the exact number with the usual grain of salt for a stat in a vendor deck. The direction is what matters, and the direction is consensus. Nobody is arguing anymore about whether the data foundation matters. That argument is over. I’m not going to re-run it here; I did that in Part 1.
So the signal at PTC Next 2026 is not “PTC shipped Orbit” or “PTC shipped Jetstream.” Vendors ship things. The signal is what shape the strategy takes: a large, incumbent PLM vendor choosing to build a new layer while deliberately preserving the old one. No rip-and-replace. The installed base stays. The new value gets built on top.
That is what a change in the PLM cycle actually looks like. For two decades the center of gravity in this industry was managing product data: owning the vault, controlling the database, being the system of record. The competitive question was who holds the master. What PTC is signaling (and they won’t be the only one; Siemens, Dassault, and SAP will narrate some version of this too) is that the center of gravity is moving to making product data usable: across engineering, manufacturing, service, quality, and AI workflows. The competitive question is becoming who can make the data act, not who can hold it still.
If that read is right, the interesting vendors over the next few years won’t be the ones with the biggest database. They’ll be the ones who figure out how to build a usable layer on top of databases they don’t necessarily own. PTC has decided to try. That decision deserves to be taken seriously, which means it also deserves to be pressure-tested.
Two Layers, Named
Let me name the two layers precisely, because the whole article turns on the boundary between them.
Layer 1 is the record. Windchill, Codebeamer, Creo, ServiceMax: the existing sources of truth, preserved in place, connected into a thread. This is the what: items, BOMs, revisions, release states, requirements linkages, the authoritative facts. PTC’s “openness, no rip-and-replace, modernize at your own pace” lives here, and as a commitment it is genuinely not the old monolith. The monolith’s defining pain was that it required you to rip and replace. Disclaiming that is a real choice.
Layer 2 is the context. New, cloud-native, multi-tenant, collaborative platforms (Jetstream for the design-and-change side, Orbit for the service-and-asset side) with AI agents working over the result. This is meant to be the why and the usable: where data from many systems comes together, where decisions get made and captured, where an agent can reason across the lifecycle instead of inside one silo.
Read charitably, this is PTC building a context layer on top of a record layer, almost exactly an attempt to close the what-without-why gap from Part 1. I want to give that its due. It’s the correct diagnosis, turned into an architecture. The question is not whether the diagnosis is right. It’s whether two layers can be held apart cleanly enough to work, or whether, over time, the new layer quietly becomes a new monolith and the old one becomes an archive.
The Catch: Far vs. Clean
Here’s the part a keynote glides over. Announcing two layers is easy. Keeping them as two layers is the entire engineering and commercial problem, and it contains a built-in tension.
“How far” and “how clean” pull against each other.
The further Layer 2 reaches (the more context it holds, the more decisions it captures, the more of the lifecycle it spans), the more it starts holding things that look authoritative, and the harder it becomes to keep a clean line between “the record” and “the layer on top of the record.”
The cleaner you keep the boundary (Layer 2 only ever references Layer 1, owns nothing), the less Layer 2 can actually hold. Because the richest material it’s supposed to capture, the why, was never sitting in Layer 1 to be referenced. You cannot reference a decision rationale nobody ever wrote down.
So PTC is threading a needle with a knot in it. A maximally clean boundary gives a thin context layer that mostly points at the record. A maximally useful context layer has to start holding the living work, and that’s the moment “two clean layers” begins sliding toward “a new platform that everything feeds.” The challenge isn’t can PTC build two layers. It’s how much of both, reach and cleanness, they can hold at once.
What “Clean” Actually Looks Like
I’m not scoring this on instinct. Two prior arguments give me a real test.
The monolith piece from 2025 laid out three pillars for the alternative to the single-database dream: scalable multi-tenant platforms, composable data services that are modular and API-driven instead of one giant database, and AI as an orchestration layer. Jetstream and Orbit clear pillar one cleanly: multi-tenant, cloud-native, built to go beyond silos. Full credit. But the test was never pillar one. It’s pillar two: do the layers stay independently evolvable, connected by real services, or held together by background sync behind a “seamless facade,” the failure mode where a conglomerate pretends to be a platform? A real architecture, in that piece’s one line, connects rather than controls.
The master-data war I mapped in 2024 named the captive-stack trap: incumbents will try to grab a portion of master data. Applied here, a Layer 2 that only really federates PTC’s own Layer 1, lighting up over Windchill but treating a competitor’s record as second-class, isn’t an open thread. It’s a moat in a thread’s clothing.
Together they make “clean” checkable, not poetic. The single cleanest tell: does Layer 2 hold net-new context, or a second copy of Layer 1’s facts? A context layer stays clean when it captures what was previously falling on the floor (the rationale, the field data, the collaboration) rather than duplicating the authoritative record. It goes dirty when the same fact is authoritative in two places and has to be reconciled by sync, when it only works over PTC’s own backbone, or when work slowly migrates into it and the record layer decays into an archive. Re-monolithization by drift.
Hold the actual products against that.
Reading Orbit and Jetstream Against the Test
Orbit leans clean, and the reason is the data it targets. Once a product ships, engineering loses line of sight; “as-designed” and “as-maintained” live in separate silos. Orbit bridges them: AI-first, with AI agents as the primary consumer of the data, answering natural-language queries and rendering BOM hierarchies, drawings, and graphs on demand. The point is that as-maintained data, for most manufacturers, had no prior system of record at all. Building a home for it isn’t grabbing a master from anyone; it’s creating one where none existed. The Southern Water case is the tell: scaling from roughly 8,000 to 40,000 managed devices, Orbit surfaced previously-unknown mean-time-to-failure data that let them right-size crews and budgets. That’s net-new context by definition. Nobody had it before. (Worth noting Orbit is the productized, renamed evolution of what was in early access as Asset 360, so it’s real and in production, not a slide. Part of the “intelligent rename” pattern from Part 1, but backed by a shipping product.)
Jetstream is where the argument gets interesting, and where PTC tells on itself.
Here is PTC’s own framing of the problem Jetstream solves: in Windchill, collaboration happens outside the system (in meetings, PowerPoints, email, shared drives), so the decision rationale is lost and only the approval gets recorded. That is an honest, precise statement of the what-without-why gap. And Jetstream’s answer is genuinely the clean pattern: email sign-in, 3D visualization, measure/section/annotate, a comment stream tied to the exact views under discussion. When wired to Windchill’s change process, it pushes the affected objects in, captures the discussion around them, and publishes the result back.
The record stays in Windchill. What Jetstream keeps is the conversation: the rationale that used to die in an inbox. Then AI mines that accumulated decision history for future change-impact analysis. That is net-new context, captured where the decision actually happens, referencing the record rather than replacing it. On my own test, that’s about as clean as a context layer gets.
But now put two of PTC’s own slides side by side. The differentiator slide claims PTC’s foundation already captures “decision intent, not just outcomes.” The Jetstream slide says Windchill records only the approval, and the rationale is lost. Both cannot be true. And the architecture settles the argument, because Jetstream exists precisely because the foundation does not capture the why. If Windchill already held decision intent, there would be no reason to build a new multi-tenant product to capture decision rationale. The existence of Layer 2 is the refutation of the Layer 1 claim.
I want to be fair about what PTC does have, because it’s real. Decades of structured relationships (versions, release states, requirements linkages, field relationships) are a genuine asset, and Joseph June was right that this is what makes the data trainable rather than merely searchable. That structure captures traceable intent: what links to what, what a part is for. What it does not capture is deliberative rationale: why this option over that one, what was weighed, what was rejected. The structured what is strong and is a real differentiator. The deliberative why is the part that was lost, and Jetstream is the admission, and the attempt at a fix.
The Verdict
Here’s where I land, and it’s warmer than a reflexive skeptic would land it, because the shape and the mechanics both earn it.
PTC is building the right shape for the new cycle, and building it about as cleanly as the current products show. Two layers, old one preserved, new value on top, no forced migration. Orbit creates a master where none existed; Jetstream captures rationale where it happens and publishes outcomes back to the record. June’s platform sketch reinforces it: a data layer of semantic models, vector stores, and connectivity (a reasoning overlay, not a new vault), with agents embedded in each product and reachable over MCP rather than locked behind one UI. That is the connect-don’t-control pattern, and it clears more of my 2025 test than I expected going in. This is more than a rename.
But the boundary is held today by product immaturity, not yet by proven discipline. Jetstream is, by PTC’s own description, the simplest product the company has shipped. It also works standalone, ships monthly, and roadmaps toward design-review spaces and a supplier portal, and the agents are built to self-learn and accumulate memory. That is a product engineered to grow into a platform. Nothing wrong with that; it’s the point. But every one of those growth vectors is also a way the context layer could stop pointing at the record and start being the place the work lives. Clean today. The slope runs toward the monolith, and the discipline that keeps it clean (references not copies, open to non-PTC records, the record staying authoritative) is exactly the discipline that gets hardest to hold as a product gets more capable and more central. So my verdict is: right shape, genuinely clean start, and the real test is whether the boundary survives Jetstream’s own roadmap.
The Opportunity Hiding in Jetstream
I just called those growth vectors a drift risk, and as a risk they’re real. But read them the other way and they may be the most interesting opportunity in the whole strategy. So I’ll plant the idea here and take it up properly on its own.
A simple, multi-tenant, cloud-native place to hold and share product data (think Onshape for product data, not Onshape for CAD) isn’t only a context layer. It’s the seed of a new system of record on a fundamentally different architecture than Windchill: SaaS, multi-tenant, connected by default, and able to reach exactly where the old systems of record can’t: contractors, suppliers, and the mid-market that enterprise PLM has never served well. PTC doesn’t position Jetstream this way, and that restraint makes complete sense: a new-architecture system of record competes with the very installed base the “preserve Layer 1” promise exists to protect, so the platform ambition stays quiet. But it’s there in the architecture, and it turns my own warning inside out. The drift toward a platform isn’t only a regression toward the monolith; it could be the connected, multi-company product-data platform I’ve long argued the market actually needs, if it stays open rather than captive. Which of those two it becomes is a question big enough for its own article. Here, it’s enough to notice the door is built in.
Why the “Why” Decides It
The deepest point this frame surfaces is about the why, and it carries straight into the rest of the series.
PTC cannot recover the rationale already lost. Decades of decisions made in meetings and emails are gone; you can’t mine what was never written down. What Jetstream can do is stop the loss going forward: capture the next decision’s reasoning at the moment it’s made, tied to the exact geometry under discussion. That’s the whole logic of the flywheel PTC put on stage: better data feeds better decisions, whose captured context feeds better AI. It only spins forward. And as a forward-looking bet, it’s a credible one. I’ll say plainly that this is the most convincing piece of the strategy.
But notice where the forward-looking bet lands. Jetstream only captures the why if engineers actually collaborate inside it instead of in email, PowerPoint, and a shared drive, which is exactly the behavior that lost the rationale in Windchill in the first place. The architecture can offer the place; it cannot make people decide there. So “can PTC capture the why” quietly becomes “can PTC get people to do their real thinking inside the system,” which is not an architecture question at all. It’s the oldest, hardest problem in PLM: adoption. It’s the same wall Stephen Olive named from PTC’s own stage in Part 1: the barrier isn’t the tools, it’s the long-relied-on processes nobody wants to touch.
That’s the thing I’ll be watching across this series. Not whether PTC can connect the what; Orbit and the structured backbone show they can. Whether the context layer can capture enough of the why to be worth building, which depends less on the elegance of two layers than on whether the people doing the deciding will move inside them.
What Is My Conclusion?
The two-layer architecture is the best structural idea PTC put on stage, and the commitment to preserve and connect the existing source of truth, rather than rip it out, is real. Orbit and Jetstream, as they shipped, mostly hold net-new context and publish back to the record. That is a clean start and it separates this from a rename.
But a new layer is not automatically a new architecture. It earns that word only if it stays a layer (connecting the record rather than replacing it, holding net-new context rather than a second copy of old facts, opening to systems PTC doesn’t own), and only if the people whose rationale it’s meant to capture actually show up inside it. The challenge I’d put to PTC is the one in the title: build the context layer without rebuilding the monolith, while genuinely connecting the existing source of truth. Far and clean, at once, as the products grow. The start is good. The hard part is still ahead, and some of it isn’t even technical.
I’d be glad to be proven wrong, and there’s a clean way to do it: show me Jetstream federating a competitor’s system of record as readily as Windchill, the record staying authoritative as Jetstream’s roadmap fills in, and show me engineers actually deciding inside it a year from now instead of in their inboxes. Until then, I read PTC’s two layers as the right diagram, cleanly drawn, with the adoption and the drift both still to be tested.
Next, I’ll follow the thread I just left open: whether Jetstream is quietly becoming a new kind of system of record (a connected, multi-tenant product data platform reaching the suppliers, contractors, and mid-market the old architecture never could) and what that would mean for the very Layer 1 PTC says it’s preserving. The text-to-CAD argument and what the agents expose come after that.
What do you think: can a PLM vendor build a new context layer without it slowly becoming the next monolith, and can it get people to do their thinking inside it?
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-native collaborative digital thread platform connecting engineers and manufacturing teams, built on federated CAD-PDM and PLM architecture. I argue for connected, two-layer thinking (record plus context) for a living, so on this particular question my opinion can be unintentionally, and maybe intentionally, biased.
Frequently Asked Questions
What is PTC Jetstream?
PTC Jetstream is a new cloud-native, multi-tenant collaboration platform introduced at PTC Next 2026. It captures the discussion and decision rationale around product changes, ties comments to specific 3D views, and integrates with Windchill and Creo while also working standalone. Select-customer early access begins in July 2026.
What is PTC Orbit?
PTC Orbit is an AI-first SaaS application introduced at PTC Next 2026 that connects “as-designed” and “as-maintained” data across the product lifecycle. Built with AI agents as the primary consumer of the data, it answers natural-language queries and is available today for three initial use cases. It is the productized evolution of what was in early access as Asset 360.
Is PTC’s product data foundation a single source of truth?
Not in the old sense. Rather than pulling everything into one database, PTC preserves the existing systems of record (Windchill, Codebeamer, Creo, ServiceMax) as a record layer and adds a new context layer (Orbit and Jetstream) on top. As shipped, that layer mostly holds net-new context and references the record rather than replacing it. How cleanly the two layers stay separated as the products grow remains an open question.
