System architecture

PLM reference architecture, with Cympha as the case study

October 2026

A PLM is two systems under one roof: a product model that has to be exact, and a workflow that has to be usable. They are different engineering problems, and an architecture that treats them as one does one of them badly.

This article is in two layers. The concept layer sets out a reference architecture for both halves, organised around four points: workflow orchestration, an agent execution layer of three kinds, mesh and CAD as equal representations, and change governed by confidence and policy. The implementation layer then takes Cympha as the case study and shows that architecture already running — a parametric catalogue of 103,966 lines, five agent modules in service, and a parametric assembly edited in a browser.

Prefer to watch? An AI presentation of this article — the same material, presented rather than read.

Two systems: the product model and the workflow

The product model answers what the thing is: items, catalogues, structure, instances, revisions, effectivity. It is long-lived, every other function queries it, and it is the half where convention should be followed exactly rather than reinvented.

The workflow answers who does each step: task assignment, approvals, decomposition, change governance, audit — and which steps a machine may take. It decides whether a deployment is used or quietly worked around.

Both are necessary, and they are built differently. One is a data model that has to be exact. The other is a runtime people have to be willing to work inside. Designed as a single system, one of them suffers, and in practice it is the second: engineering teams run their real work in task trackers and schedules, and bring the PLM only the formal gates.

Where PLM ends and ERP begins

The engineering process belongs to PLM. Change management as request, order and notice; lifecycle states and release gates; project plans and deliverables; requirements and their traceability — all of it sits on the PLM side.

ERP begins at release. It buys, makes, schedules and costs against a bill that is handed to it as given, and it has no opinion about how the design arrived. There is no second system that will pick up the workflow if the PLM does it badly.

That matters because the workflow is where PLM deployments are usually conceded. The project modules exist — schedules, tasks, deliverables, gates — but they are built as object routing: they answer who must approve this item to move it to the next state, and answer badly the question an engineer actually has, which is what am I working on and what is blocked.

Four architectural points

Four things separate this architecture from ordinary PLM practice. Everything below expands one of them.

1. Workflow orchestration — tasks, holders, subcontracting. The engine schedules tasks and holders rather than walking an object through a state machine. A subtask carries its own context and its own deliverable definition, which is why assigning work internally and subcontracting it to another organisation are the same call rather than two mechanisms.

2. An agent execution layer of three kinds — design, file-handling, AI model. Three kinds of agent, and people, share one task contract: claim, lock, return, adjudicate. Adding an executor is a plug-in module rather than an integration programme.

3. Mesh and CAD as equal representations. Scanned mesh and exact boundary representation are both first-class. Representation is an attribute of the geometry handle, not a fork in the schema, so revision, effectivity, where-used and permissions behave identically for each.

4. Change with AI in the loop — confidence and policy. The proposal object is a superset of an engineering change order: it carries a confidence so that a machine can propose honestly, and a policy that sets the auto-apply threshold and daily cap per organisation and change type.

Running underneath all four is a parametric catalogue as item master. Parts carry stable identifiers and dimensional parameters, and those parameters drive geometry generation. Without stable identifiers there is no where-used and no change propagation; without parameters there are only files.

The reference architecture

The important property is the seam between the top two rows. Executors are plug-in, which is what lets a browser and a CAD workstation — and later a CAD system nobody has integrated yet — sit side by side under one governance model. Anything that accepts a task and returns a result can occupy that top row.

The product model

This triple — catalogue item, chosen variant, placed occurrence — is what a mechanical PLM is built on, and reuse lives at the catalogue rather than at the top assembly. That is what lets made-to-order and series production share one model.

The multi-level bill of materials is an adjacency list with a closure table, and it is not where the difficulty sits. Effectivity is. Once a structure link carries “effective from this date, this serial”, every read becomes a question asked as of a point in time, and that pervades every query path. It is far cheaper to design in than to retrofit.

Workflow orchestration: tasks, holders, subcontracting

Classic PLM workflow routes an object through states. This architecture routes work to a holder. Every unit of work names who holds it right now and in what role, so a handoff is an explicit act with an actor rather than a side effect of a status change.

Four pieces carry it:

• Holder — the current owner and their role, written on the record.
• State — a guarded machine that people and machines both pass through. The rule about who may do what is enforced in exactly one place.
• Decomposition — a unit splits into child units that are themselves complete, each with its own holder, artifacts, approvals and audit trail.
• Event log — append-only, with actor, type, payload and a visibility flag that decides what an external party sees of the same record.

Recursive decomposition matters more than it looks. When a sub-task is a full unit of work rather than a scheduling row, it carries its own deliverables and review — and a child unit can sit in another organisation, which makes splitting work and sourcing it the same operation with one audit trail. Supplier collaboration stops being a separate module and becomes a property of decomposition.

Assignment follows from the same model. Filter the roster by the competency the step requires, pick by live load, keep the current holder when they still qualify, and show who each possible next step would route to before anyone commits to it.

Change management with AI in the loop: confidence and policy

The classic change record is a request, an order and a notice. This is the same object with two additions. A confidence, so a machine can raise one honestly. And a policy dial — per organisation, per kind of change — so an organisation decides for itself which classes go through without a meeting, up to a daily cap.

Whether a change is neutral in form, fit and function stays a human judgement. The system computes the affected set over the structure and records the verdict; it does not pretend to make it. One mechanism then serves both routine propagation and a formal change board, and the dial is the only difference between them.

Three kinds of agent, sharing one task contract

A person reviewing a model, a script running headless inside a licensed CAD session, and a model running in a browser are the same shape to the workflow: each claims a task, locks the record while it works, returns artifacts and a verdict, and has that verdict taken by policy or by a person.

The three kinds are distinct in what they do and identical in how they are governed. A design agent runs headless inside a licensed session, generating geometry from parameters, placing catalogue parts and solving constraints, and returns the engineering file together with the product structure. A file-handling agent watches folders and object storage, moving files directly to storage, converting formats, checking integrity and delivering with receipts — it is how device output enters the system without anyone uploading it, and the only kind that has to sit inside the customer network. An AI model agent runs segmentation, detection, landmarking, registration and mesh repair on a workstation, a server or the viewer’s own machine, and always returns a confidence for policy to judge. They share no implementation, only the contract.

The payoff is that automation arrives governed from the first day — capped, auditable, reversible — rather than as a side channel that quietly bypasses the review everyone else goes through. It is also the seam by which a CAD system nobody has integrated yet joins later as an executor rather than as a programme of work.

Where the compute runs

Three tiers, chosen by what each one owns.

The portability strategy that makes this work: extract the computational core from the application, make it headless, and compile it twice — a native library for the server and the workstation, the same source as WebAssembly for the browser. A kernel with no interface layer, no spawned processes and bounded memory is already in the shape WebAssembly requires.

CAD file tiers: native, integration, viewable, neutral

Native support comes from the CAD vendor's own API running in a licensed seat — nobody reverse-engineers the formats. The derived viewable carries the volume, which is why the browser never needs to see exact geometry. And it creates an obligation worth naming: every viewable must be traceable to the revision it came from and regenerated when that revision moves, or it quietly goes stale.

Mesh and CAD: two representations, one product structure

A real assembly contains both kinds of part. Catalogue parts arrive from a supplier as exact boundary representation, with parameters, identifiers and a where-used trail. Field parts are scanned or generated — triangle meshes with no feature tree and no parent model. Most PLM treats one of the two as a first-class citizen and demotes the other to an attachment, which is how half the data ends up outside the system permanently.

Mesh geometry (STL, OBJ, PLY) is one-off and carries no parameters; what it needs is repair, self-intersection removal, booleans, decimation and registration. CAD geometry (STEP, IGES, BREP) carries an assembly tree, placements, part names and dimensional parameters; what it needs is tessellation at a per-view deflection, structure extraction and revision comparison.

The architectural answer is that representation is an attribute, not a branch. The product structure hangs instances, an instance holds a geometry handle, and whether that handle resolves to mesh or to boundary representation is one attribute on it. Revision, effectivity, where-used and permissions are identical for both, so there is no second-class channel in which CAD goes through process and mesh goes through attachments.

The fork happens only at the operator. One measure task resolves to a closest-point distance field on a mesh and to exact surface evaluation on a boundary representation; one display task sends mesh straight to the renderer and tessellates the boundary representation first. The task type is unchanged — the executor picks the implementation from the representation, which is precisely why agents are plug-ins. The two must also coexist in one scene and measure against each other, because assembly constraints, clearance checks and interference all happen across representations rather than within one.

Part II — the implementation layer: Cympha as the case study

A file put in the cloud, opened in Studio, processed by the agent and approved in the application is the same object throughout. Each surface can be adopted on its own; together they close the loop from intake to delivered artifact.

Against the PLM pillars, the component mapping is one-for-one, and every row names a mechanism that is running rather than planned.

What is already built

The part library. ImplantCatalog.xml is 103,966 lines shipped with the product. The library and the catalogue inside it each carry a version attribute, the tree runs manufacturer to family to part, every part has a durable identifier a plan refers to, and the dimensions — platform diameter, diameter, length, apical diameter, real length — drive geometry rather than labelling it. A part library is normally the expensive thing a PLM programme has to go and build. Here it was a precondition of the design engine, so it was built years ago and is maintained commercially.

Orchestration. Assignment filters the roster by the roles a step declares, then picks whoever holds the fewest open items, counted live with a stable tie-break. A holder who still qualifies keeps the work. And before anyone acts, the interface names who each possible next step would route to — computed by the same function that performs the assignment, deliberately, because a predicted assignee that differs from the real one destroys trust in the whole mechanism.

The browser does real work. The visual client navigates a model tree with each component's catalogue specification attached, computes surface-to-surface distance maps in a worker, annotates and reports — and repairs geometry through an eight-pass pipeline aligned with the desktop routine, so a model repaired in a tab and on a workstation agree. Plan editing there is parameterisation: select a catalogue part, set diameter, length and depth, place the occurrence, watch mated components follow, and write back into the same project document the desktop application reads. That moves the configure step off the CAD seat entirely.

Inference runs on the client. Detection, promptable segmentation, landmarking and measurement tracing all execute on the viewer's own machine. No inference server, no GPU fleet, and — the argument that matters for engineering data — the image never leaves the machine.

WebAssembly, twice. The desktop product's exact-geometry core was compiled to WebAssembly with an exact-predicate kernel and a header-only replacement for its arbitrary-precision arithmetic. A second module, an analysis core, carries a declared memory-layout version and typed views into linear memory that refresh as the heap grows. Both follow one recipe: take the computational core, cut it free of the interface, give it a flat data interface, build it twice.

Three kinds of agent, five modules. The agent host on the workstation implements one plug-in interface, and five modules run against it today. AlignerBot is the design agent in full — an entire design chain run unattended rather than a single assisted step, with a designer reviewing the result. Volumetric segmentation is the AI model agent: a CBCT pipeline whose model assets are versioned and distributed separately from the host, so a model upgrade is not a reinstall. The remaining three are file-handling: watched-folder ingestion takes device and scanner output as it appears, select and upload lets a browser session pick local files and create a case through a direct-to-storage transfer, and the cloud activity monitor is the channel the others claim work on and return through. Getting data into the system at all is the most underrated problem in PLM, and three of the five modules exist to solve it.

A worked example: one assembly, end to end

One assembly, followed end to end. A surgical guide is a jig built to a single workpiece — the analogy is exact and travels to a mechanical audience without any domain knowledge: catalogue hardware, placed by parameters, held by a body generated to fit a datum nobody chose.

One parameter set drives two different things — diameter, length and depth choose which catalogue part, while angulation and pose decide where it goes. And the placements are constrained rather than free: a sleeve is coaxial with its implant and offset by a system-defined height, which is a mate relationship, and it is already enforced.

Read as a bill of materials, the mapping is mechanical:

The engineering and manufacturing bills are genuinely different here — what ships is a printed body plus purchased sleeves to press-fit, pins and a protocol — in a product small enough to hold in your head.

And it gives the change machinery a test with consequences. A manufacturer revises a sleeve: which assemblies in flight hold it, and which delivered ones were built against the old geometry? That is where-used and effectivity, exercised on a question where a wrong answer matters, against work that already runs — before a second domain is ever connected.

Integrating further CAD systems

For a CAD system nobody has integrated yet, three questions settle the whole shape of the work:

1. Does it run unattended? A programmatic interface that executes with no user present is what makes it an executor. With one, it becomes another agent module, and everything else follows.
2. Can it emit a viewable? Any tessellated export written from inside its own licensed session feeds the browser tier directly, with no third-party translator licence.
3. Can it hand over structure? If it returns the assembly tree with placements, the product model is fed from the authoring tool rather than re-entered — which is the whole value of integration.

Three yeses and the work is a module against an interface that already has five implementations, not an integration programme. The same three questions apply whether the system is new, acquired, or being brought back into development.

For established systems there are two routes, and most deployments want both. Through a seat: an agent module runs a program through the vendor's own API inside a licensed session — full fidelity, the real assembly tree, no translator licence, but it needs a seat and tracks that product's releases. On the server: a mature open-source geometry kernel reads the exchange formats, returns the assembly tree with names and colours through its data-exchange layer, tessellates, and emits the viewable — no seat, no licence contention, and it handles supplier files, archives and bulk migration. A commercial translator is the paid upgrade to the second route when native files must be read without a seat.

The path from here

The dependency order is the argument. Each move makes the next one cheaper, and none of them requires faith that a later one will land — which is what makes the sequence safe to start. The first two validate the entire product model against production traffic, with no second domain connected to it.

One deliberate omission: scheduling splits in two. Dependency is data and belongs in the model. Sequencing is dispatch, decided at run time from readiness and capacity by the orchestration layer, while commitment dates come from measured cycle times rather than a plan drawn in advance.