Your model is data, not our schema
Every PLM says it is configurable. The question is what happens when a configuration change turns out to be wrong — whether that is an afternoon with a rollback, or a vendor ticket and a migration window.
What it is, and what it is not
A metadata-driven core. ObjectType, AttributeDefinition, RelationshipType, LifecycleDefinition, WorkflowDefinition and PermissionPolicy are rows in your tenant, not classes in our code.
It is not a fixed schema with custom fields bolted on. That distinction matters at the first requirement the vendor did not anticipate: with custom fields you get somewhere to put the value and nothing that understands it — no lifecycle, no relationship semantics, no validation, no place in the resolver.
It is also not a platform you have to build a PLM on. Manufacturing PLM ships an opinionated model for electro-mechanical manufacturers that works on day one. The engine is what lets you change it afterwards, rather than a toolkit you are expected to assemble first.
The mechanism: config is versioned like code
Every tenant gets a sandbox with the same object model as production, and changes are made there. The path to production has four steps and the third is the one that matters.
Diff compares sandbox against production and reports what changed — three changes, one of them breaking. Preflight then runs that diff against your real data and says what it would cost: one thousand two hundred and forty parts would need the new required attribute; two open changes sit in a lifecycle state the numbering replacement removes.
That is the number nobody has before they commit a model change, and it is why model changes get deferred until they are urgent and then made under pressure. Promote captures an immutable configuration version. Rollback returns to the previous version in one action, because the previous version still exists as a snapshot rather than as something to be reconstructed.
Configuration environments are a discriminator on the definitions themselves — production, staging, sandbox — so a sandbox is not a copy of the database that drifts. It is the same objects at a different environment value.
The failure it prevents
A rollout stalls at the modelling exercise. Somebody has to decide part types, attributes, lifecycle states, numbering and approval routing before anyone has used the system, and the decisions are expensive to undo — so they are made carefully, slowly, by people learning what they need while committing to it.
Six months later the model reflects the organisation as it was understood at kickoff. It is maintained by one person who has since moved on, and nobody will touch it because nobody is confident what depends on what.
The alternative failure is faster and just as bad: somebody changes a required attribute on a Friday and discovers on Monday that one thousand two hundred and forty parts are now invalid and the import job has been failing all weekend. Preflight is the difference between those two outcomes and it is unglamorous enough that most tools do not bother.
How it meets the rest of the product
Everything else in the product is built on these definitions rather than beside them. A part is an ObjectType. A change is an ObjectType with seven kinds discriminated on it. A document is an ObjectType with the same revision and lifecycle semantics as a part — which is why a drawing and a part cannot end up with revision schemes that disagree at the boundary.
Because lifecycles are definitions, the state machine a change moves through is yours, and the workflow engine runs over the same definitions rather than a parallel copy. Adding a review state is a configuration change with a preflight, not a feature request.
Terminology overrides are display-layer only. If your organisation says *item* rather than *part*, the label changes and the underlying type does not — so an integration, an export and a support conversation all still refer to the same thing. Renaming the model to match local vocabulary is how two tenants become impossible to support with one set of documentation.
Custom agents are defined against the same types, so an agent cannot be given a capability the framework does not already govern.
How it meets your ERP
The connector maps to your object model, so extending the model does not break the integration — a new attribute is mappable or it is not mapped, and either way the existing field map is unaffected.
Preflight covers the seam too. A configuration change that would alter something the connector publishes is reported as such before promotion, because discovering it afterwards means discovering it in your ERP's data rather than in a diff screen.
What the engine will not do is let you model your way around ownership. Adding an attribute called cost to a part does not make cost yours; the system-of-record matrix is enforced at the data layer beneath the model, so an ERP-mastered field stays read-only whatever it is called locally.
Where the boundary is
Configurability is not unlimited, deliberately. The platform/tenant compatibility contract defines what a tenant may change and what it may not — you cannot redefine what a revision means, remove the tenant predicate, or model your way out of change control. A tenant that could do those things could not be upgraded, and a multi-tenant product that cannot be upgraded is a set of forks.
There is also no scripting. Behaviour comes from definitions, rules and workflows rather than from code you write, because arbitrary code in a tenant is where business logic hides from review and what makes an upgrade an archaeology exercise.
Facts
| Definitions | ObjectType · Attribute · Relationship · Lifecycle · Workflow · Policy |
| Stored as | Tenant data, not compiled schema |
| Environments | Production · staging · sandbox, as a discriminator |
| Preflight | What a change costs against real data, before promoting |
| Promotion | Captures an immutable configuration version |
| Rollback | One action — the previous version still exists |
| Terminology | Display-layer only; the type never changes name |
| Not offered | Scripting · redefining revisions · escaping the tenant predicate |
Frequently asked
How is this different from custom fields?
A custom field gives you somewhere to put a value and nothing that understands it — no lifecycle, no relationship semantics, no validation, no place in the resolver. Here a new type is a first-class object with all of that, because the model is data rather than schema.
What does preflight actually tell me?
What a configuration change would cost against your real data before you commit it: how many parts would need a newly required attribute, which open changes sit in a lifecycle state you are removing. That number is what nobody has when model changes get deferred.
Can we roll back a bad change?
Yes, in one action. Promotion captures an immutable snapshot, so the previous version still exists rather than needing reconstruction. That is the property that makes it safe to change the model at all rather than deferring until a change is urgent.
Do we have to model everything before we start?
No, and that expectation is what stalls rollouts. Manufacturing PLM ships an opinionated model for electro-mechanical manufacturers that works on day one. The engine exists so you can change it after three months of real use, rather than deciding permanently at kickoff.
Can we rename parts to items?
Yes, as a display-layer terminology override — the label changes and the underlying type does not. Renaming the model itself is how two tenants become impossible to support with one set of documentation, one integration mapping and one support conversation.
Is there a scripting layer?
No. Behaviour comes from definitions, rules and workflows rather than code you write. Arbitrary code inside a tenant is where business logic hides from review, and after two years of it nobody can say what the system does or upgrade it safely.
Can we model around ERP field ownership?
No. Adding an attribute called cost to a part does not make cost yours — the system-of-record matrix is enforced at the data layer beneath the model, so an ERP-mastered field stays read-only regardless of what it is called locally in your configuration.