Product Lifecycle Management provides complete part and document versioning, engineering change control, bill of material management with date and unit effectivity, formal approval and release workflows, and controlled custody of CAD and other engineering documents. Every part and every document is a revision-controlled object with a defined lifecycle state, so the platform always knows which revision is in work, which is released, which is obsolete and which is superseded. Bills of material are structured, multi-level and versioned, expressed as manufacturing, engineering and service structures that can differ deliberately while remaining traceable to one another.

The module maintains classification and part numbering schemes, attribute libraries, unit-of-measure and reference designator handling, alternate and substitute parts, and make-versus-buy designation. It manages the full population of controlled documents: native CAD models and drawings, specifications, test procedures, work instructions and certificates, each versioned, viewable and linked to the items they describe. Change is never silent. Redlines, deviations, waivers and change orders are first-class objects, and the release of any revision is an auditable event with an attached electronic signature, a reason for change and a record of who approved what and when.

At the centre of the module sits the part: the enduring identity of a component, material or assembly, distinct from any one revision of it. A part accumulates revisions over its life, and at any moment each revision occupies a defined state, from in-work through under review to released and finally obsolete. Because identity and revision are separated, the enterprise can talk about a component as a stable thing while its detailed definition legitimately evolves.

Parts relate to one another through the bill of material, the structured statement of what an assembly is made from and in what quantity. These structures are governed by effectivity, the rule that determines from which date, or from which serial or lot, a particular child revision applies. Effectivity is what lets a design change take hold cleanly at a chosen point without rewriting history or disturbing units already built. Around parts and structures sit documents, which carry the drawings, models and specifications that give a revision its meaning, and change records, which capture the intent, justification and authorisation behind every transition from one revision to the next. The relationships between these concepts, identity to revision, revision to structure, structure to effectivity, and everything to its governing change, are what make the product definition both stable and safely changeable.

Work enters the module as a request. An engineering change request captures a problem or an opportunity: a field failure, a cost reduction, a supplier substitution, a customer requirement. Once accepted, it becomes an engineering change order, the controlled instrument through which affected parts, documents and bills are revised together as one coherent package. The change order assembles the before-and-after picture, identifies every affected item, sets the effectivity, routes the package for review and, on approval, releases the new revisions atomically so that the product definition never exists in a half-changed state.

Approval and release run on configurable routing. A package moves through defined review roles, each with its own criteria and electronic sign-off, and cannot advance while any required approval or precondition is outstanding. New product introduction follows the same discipline from the other direction: concepts mature into designs, designs are captured as controlled documents and structures, and release gates confirm that a definition is complete, reviewed and manufacturable before it is handed to production. Retirement and obsolescence are handled with equal rigour, ensuring that end-of-life parts are superseded cleanly, last-time-buy needs are flagged and downstream consumers are redirected to current revisions.

The value of the module lies in the controls that surround the definition. Effectivity is enforced on every structure so that manufacturing always resolves the exact revision valid for a given build date or serialised unit, and where-used analysis runs in both directions, revealing every assembly a part touches before a change is committed. The module maintains full revision history and difference comparison, so any two revisions of a part, document or bill can be compared line by line, and it preserves an immutable audit trail of every state change, approval and signature.

Change management embeds the discipline expected of regulated and safety-critical industries: segregation of duties between originator and approver, mandatory reason-for-change coding, deviation and waiver control with defined expiry, and closed-loop verification that a change has been implemented and its effectivity honoured. Electronic signatures are captured with intent and identity, supporting the evidentiary standards required for controlled records. Classification and reuse controls reduce part proliferation by surfacing existing equivalents before a new part is created, and validation rules guard the integrity of numbering, attributes and structure quantities. Together these controls give the enterprise a product definition that is not merely stored but genuinely governed, defensible under audit and reliable as the input to everything downstream.

Product Lifecycle Management is the upstream authority for the physical and engineering side of the suite. It feeds released, effectivity-controlled bills of material and item masters directly into Manufacturing and Operations, which plans, routes and builds against exactly the revision the change order made effective. It supplies validated part definitions and approved-manufacturer information to Procurement and controls make-versus-buy designation that shapes sourcing. Released structures and stocking attributes flow to Inventory and Warehouse Management, so that what is held and moved reflects the current definition.

The module works closely with Quality Management, which returns nonconformances, corrective actions and field failures as the raw material for engineering change, and with Compliance, which draws on part and material attributes for regulatory and material-declaration reporting. Product and configuration data support Sales and Configure-Price-Quote so that quotable configurations map to real, releasable structures, while cost roll-ups and standard costs are shared with Finance. Controlled documents are custodied through the suite's document services, and every approval, signature and change event is written to the shared audit and identity layer that governs the whole of Nashua 360.

AI Workers are first-class participants in Product Lifecycle Management, not an overlay on it. Engineers query the product definition conversationally, asking where a part is used, which assemblies a proposed change would disturb, what differs between two revisions or which open change orders touch a given programme, and receive precise, source-linked answers drawn from the live model. Workers execute actions under the same permissions and controls as any user: raising a change request, assembling the affected-items list for a change order, proposing effectivity, or drafting a new part from an existing equivalent to curb proliferation.

They extract structured data from incoming engineering documents and supplier declarations, reading drawings, specifications and material certificates to populate attributes and flag mismatches against the controlled record. They monitor continuously for anomalies and exceptions: structures released without a governing change, effectivity gaps or overlaps, unresolved redlines, deviations approaching expiry, or a released revision still referencing an obsolete child, and they alert the responsible owner. In decision support they summarise the impact and cost of a change, surface reuse candidates and highlight risk before approval. Crucially, an AI Worker can stand as a named review or approval node in a release workflow, applying defined engineering and compliance criteria, signing or returning a package with its reasoning recorded, and escalating to a human wherever judgement or authority requires it.