Earlier today, PTC officially launched Jetstream. Which brings me back to trip to PTC Next 2026 in Chicago. It is a useful moment to return to the questions I raised in June about collaboration, product context, and AI.
My first article after PTC Next asked what would make “intelligent” PLM an architectural change. The next article examined how a context layer could work alongside existing systems of record while remaining open.
Jetstream made that discussion more specific and interesting. In my article about its June announcement, I asked the question how does captured reasoning remain usable years later? My final article in the series extended that question across the lifecycle, asking how individual tools and their AI assistants could share product context.
The launch brings us back to those questions. So does Jon Stevenson’s LinkedIn post published earlier today. His description of knowledge disappearing after design reviews connects directly to what I have been calling Product Memory.
Jon starts with a familiar engineering situation. People with different experiences look at the same design. A supplier identifies a manufacturing constraint. A quality expert raises a concern. Someone asks a question that changes the direction of the work.
The product definition is updated, but the reasoning can become difficult to recover. Here is a passage from the post:
“Product data tells you what a product is, but it rarely tells you why it ended up that way.”
I agree with the problem he describes. PLM systems can hold rationale in change records, issues, and documents. The challenge is how much of the actual discussion reaches those records and how clearly it remains connected to the product.
Many contributors work outside engineering’s CAD and PLM environments. Their knowledge still shapes the design. Making participation easier creates an opportunity to capture that knowledge while the work happens, instead of asking someone to reconstruct it afterward.
What Jetstream brings to the review
According to PTC’s product page, teams create access-controlled Rooms, invite reviewers, and examine 2D and 3D content in a browser. Feedback stays associated with the version, participant, time, and relevant view. AI summaries help people follow the discussion and next actions. Windchill remains the system of record, and Jetstream also supports direct file uploads.
That gives review discussions a place beside the information being reviewed. Someone returning to a comment has a better chance of understanding what the contributor was looking at and what they meant.
The practical value begins there: fewer disconnected handoffs and less effort spent reconstructing a conversation. The longer-term opportunity is to make that context useful when another decision comes along.
Why the architecture matters
Back in June, I emphasized another part of Jetstream’s significance: a multi-tenant cloud collaboration layer built alongside existing systems of record. That architecture deserves attention when comparing products with similar review experiences.
For example, Aras Innovator Visual Collaboration is configured around Innovator items, connecting discussions to the objects being reviewed. The comparison needs to go beyond whether both products support model viewing, comments, and markups (some other products do it as well).
The architectural question is where the collaboration lives and who can participate. Are suppliers joining one company’s PLM environment, with the discussion centered on records managed there? Or can independent companies collaborate through a shared service while retaining control of their own product records? Similar screens can support different answers to that question.
Jetstream’s standalone Rooms appear to create an opportunity for the second approach. Participants can work together without everyone becoming a user of the host’s PLM system. That is an important starting point, but it does not establish how independently managed company environments connect.
Multi-tenancy alone does not prove that connection. A service can support many customers while keeping their work separate. A shared Room can also contain uploaded copies. The useful test concerns company boundaries, record ownership, and the links between shared data and its source, rather than the number of physical databases.
I would like to see an OEM using Windchill, a supplier using SolidWorks/PDM, and another partner using a different system for example Altium 365, contribute to a review. Can each retain control of its authoritative records, preserve source identities and revisions, and control what it shares? How are updates handled, and what review context can each company retain when the collaboration ends?
That would help validate the architectural distinction I raised in June. It also matters for Product Memory: reasoning about a product often crosses company boundaries, and its origin and scope need to remain understandable.
A decision also has conditions
The excavator pin example from PTC’s June demo is a useful way to explain the next step. The supplier does not stock the proposed 174 mm pin but offers 170 mm or 175 mm alternatives. The engineer adjusts the assembly to use the 175 mm option. The exchange connects the supplier’s constraint to the design choice.
Now consider a hypothetical continuation two years later. Procurement introduces a supplier that stocks 174 mm pins. An engineer asks why the assembly uses 175 mm and whether it should be reconsidered.
The original decision still matters. So does the condition that influenced it: what the earlier supplier could provide.
A new supplier does not automatically make the approved design wrong. Fit, strength, test results, maintenance requirements, or other considerations may support keeping it. Changing the design would still require engineering assessment and the appropriate approval.
What would help is access to the original reasoning: which supplier constraint mattered, which alternatives were considered, what else engineering evaluated, and who approved the result. Later evidence should be connected too.
This is where Product Memory becomes practical. It brings product information and history together with decisions, assumptions, evidence, and outcomes. It helps a future team understand why a choice was made and assess whether the reasoning still applies.
A changed assumption can become a reason to review a decision. The approved product definition continues to govern until the responsible people change it.
How review evidence becomes reusable context
PTC describes exporting Room activity as a PDF and checking it into Windchill. Its product page also describes links to associated product data and tracking which revisions were shared.
That is a useful way to retain review evidence with the product record. It gives a later reader something to inspect and a connection back to the review.
A PDF can contain the configuration, constraints, participants, and approval information. AI can extract information from it. The format alone does not determine whether the reasoning can become useful Product Memory.
The architectural question is how reliably that information can be found, interpreted, and connected to subsequent work. Can another application identify the decision and its scope? Can it follow the supporting evidence? Can it distinguish an accepted outcome from an unresolved suggestion, or recognize that a later decision superseded it?
The launch materials describe a capture and retention workflow. They do not establish the full range of ways other applications or lifecycle agents can reuse that context. I would be interested in seeing more of that connection in practice.
This also helps explain Jon’s statement that Jetstream is built into the lifecycle. A standalone service can participate in lifecycle workflows through integration. Working alongside Windchill and contributing to the lifecycle are compatible choices. The important question is how well the connections work.
The questions I will keep watching
The questions I raised in June remain useful, now we can assess the released product with questions.
The first is how context reaches subsequent work. AI summaries can help people understand a Room. I would also like to see how the captured decisions and evidence support tasks in CAD, PLM, manufacturing, or service. A useful demonstration would show an answer connected to its source, applicable revision, and decision status.
The second is openness across companies and systems. The architecture described in Chicago makes this an important test: can a Room connect contributions from independently managed product environments while preserving each company’s authority, permissions, and source references?
The third is authority and access. A supplier’s comment, an AI summary, and an approved engineering decision serve different purposes. Reusing context should preserve those distinctions, along with the permissions and responsibilities attached to the original information.
The fourth is adoption. Do people find the environment useful enough to conduct their actual reviews there? The quality of the captured context depends on the work taking place. Some important reasoning will continue to emerge in other conversations and systems, which makes connecting that evidence part of the longer-term challenge.
There are broader product-data related questions. For now, the launch provides a practical collaboration application to assess through use.
What is my conclusion?
Jetstream gives PTC a concrete way to capture discussions around product data and involve people beyond the usual engineering system users. The multi-tenant cloud layer is an important part of that direction. Its ability to connect independently managed company environments is a distinction worth validating.
Jon’s article explains why it matters. Engineering knowledge influences the product during a review and deserves to remain available afterward.
Product Memory extends that value over time. It keeps decisions connected to their assumptions, evidence, scope, and later outcomes, so future teams can understand what happened and make an informed next choice.
That is how I would close the loop from PTC Next. Jetstream is a useful step toward the context that an intelligent lifecycle needs. The next evidence I will look for is how that context stays connected and useful as products, suppliers, and systems change.
Jon asks where decisions get lost. Sometimes the reasoning is never recorded. Sometimes it is captured but becomes difficult to find or understand later. Both deserve attention.
Can your team find the reasoning behind a design choice made two years ago and tell whether it still applies?
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM. My work on connected product data and Product Memory shapes my perspective, and my opinion can be unintentionally biased.
