The code boundary: what an AI agent can and cannot change in your PLM

Abstract

Every PLM vendor says their platform is configurable, and every one of them is telling the truth. The useful question is not whether a platform is configurable but to what depth — and specifically, where its code boundary falls: the line past which a change stops being data an administrator can make live and becomes source code that must be written, compiled, packaged, deployed and usually restarted.

This paper locates that boundary precisely on three major platforms. It finds that the shallow layers — new types, new attributes, lifecycles, workflows, access rules — are runtime-configurable almost everywhere, which means the industry's "low-code" marketing is broadly honest and broadly useless as a differentiator. The difference appears at one specific element: executable server-side behaviour. On PTC Windchill and Dassault 3DEXPERIENCE that behaviour is compiled code behind a deployment cycle. On Aras Innovator it is an item in the database, compiled dynamically at runtime.

That architectural detail was a modest convenience for twenty years. It has just become the difference between a PLM an AI agent can genuinely extend and one it can only decorate, and this paper argues that is the most consequential platform distinction of the next decade.

1. "Configurable" is not a differentiator any more

Ask any PLM vendor whether an administrator can add a field without a developer and the answer is yes. It has been yes for years. The marketing category called low-code has made the claim universal and therefore uninformative.

To get a real answer you have to decompose "configurable" into the things a model actually consists of, and ask about each one separately. There are six that matter:

• E1 — adding a new object type with new attributes
• E2 — adding a new relationship between two types
• E3 — defining a lifecycle: states and the transitions between them
• E4 — defining an approval workflow
• E5 — changing permissions for a type
• E6 — adding server-side behaviour: logic that runs on create, update or promote — validation, derived values, side effects

And one more that decides how any of it is governed:

• E7 — whether the entire configuration can be exported as data, diffed, version-controlled and re-imported

Asked element by element, "is it configurable" turns into a question with a different answer per platform, and the answers are not where the marketing suggests.

2. Where the boundary actually falls

Here is the honest map, and the first thing to say is that the competition does better on the shallow elements than an Aras partisan would like.

PTC Windchill's runtime typing is real. PTC's own documentation is explicit that soft types and soft attributes are created through the Type and Attribute Management utility and that extended types and subtypes "are non-modeled and do not require recompiling or interrupting operations" — the capability lets you "augment out-of-the-box business objects by adding additional attributes, or by adding new object types with different attribute sets without changing the object model or writing code", and explicitly "without requiring server restarts" (PTC Help Center). Lifecycle templates, workflow templates and access policies are likewise administered live. Anyone claiming Windchill needs a developer to add a field is simply wrong, and this paper does not claim it.

Then it stops. Server-side behaviour in Windchill is Java. Adding it means writing code, building it — the documented cycle runs ant against a target such as installSiteChanges, then xconfmanager to propagate the configuration — and then restarting Windchill and Tomcat. Hot code replace exists, but it is a developer's Eclipse debugging convenience, not a production deployment path.

3DEXPERIENCE sits similarly. Types, relationships and attributes are schema, changed through MQL and moved between environments as a deployment. Behaviour is triggers and JPOs — compiled Java stored and deployed, where "MQL needs to be restarted if already running to pick up copied JARs", and JSP hooks require the Tomcat instance to be restarted to compile the pages (community documentation).

Aras has no such line. In Aras the ItemType is an item, the RelationshipType is an item, the Life Cycle Map is an item, the Workflow Map is an item, the Permission is an item — and so is the Method. Aras's Programmer's Guide describes the mechanism directly: the "Item Action" relationships on ItemTypes simulate object-oriented programming, where the ItemType is the class and Item Action relationships to Methods are the class methods, and "literally the Method code is compiled dynamically to extend the Item Class with this method and calls it" (Aras Programmer's Guide).

Executable behaviour is a row in the database, compiled on the fly. There is no build, no package to deploy, no service to restart — and, critically for what follows, no separate interface for changing it. The same API that creates a part creates the logic that validates the part.

Five rows are near-parity. The interesting rows are the last two, and until very recently they were a matter of taste.

3. Why a twenty-year-old detail suddenly matters

For most of Aras's life, "methods are items" was an implementation curiosity with a modest practical benefit: changes were quicker and upgrades were easier, which is the argument made elsewhere on this site. It was not a reason to choose a platform, and honest analysis should admit that a build step is not a catastrophe. Engineering organisations deploy software constantly.

What changed is who is making the changes.

An AI agent can only reliably extend a system through an interface it can call. Give an agent an API and it can create data, read data, relate data. That is the shape of every "AI in PLM" demonstration currently being shown: the assistant drafts a change request, summarises a BOM, answers a where-used question. Useful, and all of it strictly within the model that already exists.

Now ask an agent to do something a real engineering organisation asks for every month: "we need to track supplier certification expiry on purchased parts, warn the buyer sixty days out and block release of any assembly containing an expired part."

That request decomposes into all six elements. A new type for the certification (E1). A relationship to the part (E2). States for valid, expiring and expired (E3). A notification workflow (E4). Access rules so suppliers see only their own (E5). And — the part that makes it real rather than decorative — logic that runs on promote and blocks the release (E6).

On a platform where E6 is compiled code, the agent can do five-sixths of the job and then must stop and file a ticket. It can create the type and the fields and the states, and it cannot create the rule that gives them meaning. The result is a data model with no behaviour: a place to record certifications that does not actually stop anything, which is worse than nothing because it looks like a control and is not one.

On Aras the agent finishes the job, because the sixth element is the same kind of object as the other five and reachable through the same API.

That is the claim of this paper. Not that Aras is more configurable — the table above shows it mostly is not, at the shallow layers. The claim is that Aras has no code boundary, and that in an era where the agent is the one doing the configuring, the code boundary is exactly where an agent's usefulness ends.

4. The self-extending system

Follow the consequence and it goes further than convenience.

If the model is entirely data, and an agent can read and write that data, then the system can be asked to extend itself — and, more interestingly, to explain and revert its own extensions, because every part of the extension is an item with a history like any other item.

That enables a working pattern that does not exist on the other platforms:

Describe the capability, review the diff, apply or discard. An engineer describes the need in a sentence. The agent proposes the complete extension — the type, the relationships, the lifecycle, the workflow, the permissions and the server logic — as a package of items. A human reads it as a diff, in the same form as any other configuration change, and applies or rejects it. Because it is a package of data, applying it is one transaction and reverting it is another.

This is why E7 matters as much as E6. A change that is data can be exported, diffed, put under version control and rolled back. A change that is partly data and partly compiled artefacts cannot be reviewed as a single thing — you review the config in one place, the code in another and hope they were deployed together.

The pattern also inverts a long-standing PLM problem. Configuration drift — the gradual divergence between what the system does and what anyone documented — happens because changes are made through several interfaces and recorded in none. When every change including behaviour is an item with an author, a date and a reversible package, the system's own history becomes the documentation, which connects directly to the argument for recording intent as data.

5. The obvious objection: this sounds dangerous

It is, and a paper that skipped past that would not be worth reading.

Letting an AI agent write server-side logic that compiles dynamically into a production PLM is the single most alarming sentence in this paper. The same property that makes the extension possible — no build, no gate, immediate effect — removes the friction that has historically prevented bad code reaching production. A deployment pipeline is slow, and slowness is a safety feature.

So the pattern only works with the friction deliberately reintroduced, in a place where it does some good:

• Never apply directly to production. The agent proposes into a development instance. The package is applied to production through the same promotion path a human change would use.
• Human review of the diff is mandatory, and it is a real review. Reading a proposed server method is a skill; the reviewer must be someone who could have written it. The agent removes the typing, not the judgement.
• The agent operates under its own identity, with its own permissions. An agent that can modify the permission model is an agent that can grant itself anything. Its identity must be scoped so that the access model itself is outside what it may change without a second approval — the standard separation-of-duties argument from permission design, applied to a non-human actor.
• Every applied package is revertible as a unit, and reverting is tested, not assumed.
• Behaviour changes carry tests. If the agent proposes logic that blocks a release, it proposes the test that proves the block fires and the test that proves it does not fire when it should not.

None of this is exotic. It is ordinary software discipline applied to a system that historically did not need it, because historically only developers could reach that layer, and the deployment pipeline enforced the discipline for you. Remove the pipeline and you must supply the discipline explicitly. Platforms that have a code boundary get this discipline free; platforms that do not must choose it.

Two further honest caveats:

Dynamic compilation is a security surface. Code that can be written through an API and executed on the server is, viewed uncharitably, a remote code execution path with an approval workflow in front of it. That is a real property of the architecture. It is why method-editing rights belong to very few identities and why any organisation adopting the pattern should be able to answer precisely who can create a Method and what stops them.

Agents are not yet reliably good at this. Proposing a correct server method that interacts safely with lifecycle events, permission elevation and transaction boundaries is genuinely hard, and current models get it wrong in ways that are not always obvious on reading. The architecture makes the pattern possible; it does not make it safe, and the gap between those two is the review step. Anyone selling the first as though it were the second is selling something.

6. What to do with this

For an organisation already on Aras, the practical implication is that the agentic capability every vendor is promising for some future release is architecturally available now, and the work is governance rather than product: decide who reviews, which instance the agent proposes into, how packages are promoted and what the agent's identity may not touch.

For an organisation evaluating platforms, this is a question worth putting to every vendor in a proof of concept, and it is answerable in an afternoon:

Show me an agent, through your API, adding a new object type with a relationship, a lifecycle, a workflow, an access rule and a server-side validation that blocks a promotion — with no build and no restart. Then show me that whole change as one exportable, revertible package.

Ask that in a proof of concept run on your own data. The first five will be demonstrated smoothly on any platform. Watch what happens at the sixth, because that is where the architecture stops being a slide and starts being a fact.

7. Where this goes

The industry is about to spend several years marketing AI assistants for PLM, and most of them will be able to read the model and draft documents. That is genuinely useful and it is not what this paper is about. The distinction that will matter is between systems an agent can use and systems an agent can extend — and that distinction is not a feature any vendor can ship next quarter, because it is a property of where the code boundary was drawn twenty years ago.

We are designing LitePLM with no code boundary by intent, for exactly this reason: not because dynamic behaviour is elegant, but because a model in which behaviour is data is the only kind an agent can safely and completely extend. On Aras that property already exists and is under-exploited. On the platforms where behaviour is compiled, it is not a roadmap item — it is a rewrite.

---

White paper. PLMClub implements on Aras Innovator and is developing LitePLM, an AI-native PLM platform; read the argument with that interest in mind, and note that section 2 deliberately credits Windchill's runtime typing because the case does not need it to be worse than it is. Platform mechanisms are as documented in September 2026 and all three vendors change them. If you can demonstrate a production path to runtime server-side behaviour on Windchill or 3DEXPERIENCE that we have missed, tell us and we will publish the correction.