Configuration Management in PLM: Baselines, Effectivity and Product Structure Versioning

A field engineer calls about a failed pump on a machine delivered fourteen months ago. Support needs to know exactly which impeller, which firmware image and which seal kit were installed on that serial number, and whether the drawing the supplier built from is the drawing the customer was promised. The PLM system holds forty revisions of the assembly, three open change orders and a “released” flag on all of them. None of that answers the question. This is the gap that configuration management in PLM exists to close: not storing files, but being able to reconstruct, for any moment and any unit, what the product was.

It matters in 2026 because products are software-defined, variant-heavy and regulated at the unit level. Battery passports, cyber resilience obligations and right-to-repair rules all ask for unit-specific truth, and digital twins are only as good as the configuration they mirror.

You will leave with a precise vocabulary (configuration item, baseline, revision, version, iteration, effectivity), a reference data model with runnable SQL, a resolution algorithm for date and serial effectivity, and a catalogue of the failure modes that corrupt configurations in practice.

What this covers: the CM standards and the five functions, configuration items and baselines, revision vs version vs iteration, effectivity, a SQL data model, as-designed to as-maintained lineage, ERP and MES integration, and what goes wrong.

Context and Background

Configuration management (CM) predates PLM software by decades. It grew out of defence and aerospace programmes where a missile or aircraft was built by hundreds of suppliers and an uncontrolled drawing change could ground a fleet. The U.S. industry consensus standard is ANSI/EIA-649, first published in 1998 by the Electronic Industries Alliance and now maintained by SAE International; the current edition is EIA-649-C, dated 2019. It replaced the military MIL-STD-973 when the U.S. Department of Defense adopted it in 1999, per the EIA-649 summary on Wikipedia. The international counterpart is ISO 10007, “Quality management systems: guidelines for configuration management” (I believe the current edition is 2017; confirm against the ISO catalogue before citing an edition).

EIA-649 organises CM into five functions: CM planning and management, configuration identification, change management, configuration status accounting, and configuration verification and audit. Those five functions are the best checklist for judging a PLM deployment, because each one maps to a concrete system capability. Planning decides which items are controlled and how tightly. Identification gives every controlled item a unique, stable name. Change management governs how that item may be altered. Status accounting records what exists and what happened to it. Verification proves the physical product matches the documented one.

Most PLM projects implement the second and third function well and the fourth and fifth poorly. Identification and change workflow are visible, demoable features. Status accounting, the ability to answer “what is the configuration of unit 4471 on 12 March”, is a query problem that only shows up when someone needs the answer. It is also where engineering change management either pays off or turns out to have been paperwork.

This article takes a different angle from the change-process posts already on the site. Instead of walking the ECR/ECO workflow, it treats configuration as a data-modelling and query problem: what must be stored so that a configuration at any past instant, for any unit, can be recomputed deterministically. That framing also connects directly to the digital thread, which is only coherent if the configuration it threads through is well defined.

Configuration Management Reference Architecture

Configuration management in PLM is the discipline of identifying controlled items, freezing their definition at agreed points (baselines), governing every change, and recording effectivity so that the exact as-designed, as-built or as-maintained structure of any unit can be recomputed on demand. The system of record is a versioned product structure plus an effectivity layer, not a file vault.

A workable reference architecture has five layers, and the discipline is keeping them separate. The identity layer holds configuration items (CIs) and their immutable identifiers. The definition layer holds revisions and the structure (who uses whom). The control layer holds baselines, change objects and approvals. The effectivity layer says when and for which units each revision or structure link applies. The realisation layer holds what was actually built or installed: serialised units and their as-built records.

Figure 1: Five-layer configuration management architecture. Effectivity sits between definition and realisation; it is the join that lets one structure serve many units.

The figure shows the dependency direction. Nothing in the definition layer knows about serial numbers, and nothing in the realisation layer copies definition data. A unit points at a configuration item revision and a baseline, and effectivity decides which revisions of children apply. When teams collapse these layers, for instance by stamping serial numbers onto BOM lines, they lose the ability to answer retrospective questions.

Configuration items and identification

A configuration item (CI) is an aggregation of hardware, software, processing material or services designated for configuration management and treated as a single entity. The selection of CIs is a management decision, not a technical fact. Make an assembly a CI and you must control its revisions, interfaces and change history separately; make it merely a component of a larger CI and its changes ride along with the parent.

The practical test for selecting a CI is whether the item is independently procured, independently changed, independently maintained in service, or has a distinct interface that others depend on. A motor controller qualifies on all four counts. A bracket usually qualifies on none, and controlling it as its own CI adds change overhead with no traceability benefit. Over-selection is the more common error: teams make every part number a CI and drown reviewers in approvals for fasteners.

Identification has two parts that people conflate. The item identifier (part number, document number, software module ID) names the thing across its whole life and must never be reused or overloaded. The revision identifier names a state of that thing. The core rule of EIA-649 style identification is the form-fit-function test: if a change alters form, fit or function in a way that breaks interchangeability, the item needs a new part number, not just a new revision. Interchangeable changes keep the part number and increment the revision.

That rule is the single most violated one in practice, and violating it is expensive. If a supplier changes the mounting hole pattern and the revision goes from B to C with the same part number, then stock of B and C is physically incompatible but indistinguishable to the ERP. Every downstream system now has a latent defect.

Baselines: functional, allocated and product

A baseline is an approved, frozen snapshot of a set of configuration items and their documentation that serves as the basis for further change. After a baseline is established, changes go through formal control. The classical defence vocabulary recognises three levels, aligned with the system lifecycle.

The functional baseline captures the system-level requirements and the verification that they are met: what the product must do. The allocated baseline captures the requirements allocated to each configuration item below the system, including interface definitions: what each part of the product must do. The product baseline captures the detailed design and the production and acceptance criteria: how it is built and verified. Civil and commercial industry often uses different names (requirements baseline, design baseline, release baseline, manufacturing baseline), but the logic is the same: each baseline narrows the freedom to change and raises the cost of changing.

In PLM tooling a baseline is implemented as a named, immutable set of references to specific item revisions (and, for structures, specific structure link versions). It is not a copy of data. A baseline answers one question exactly: which revision of each member did we approve together. The cost model of a baseline is therefore cheap to create and expensive to violate, which is the correct economics.

Revision, version and iteration: three different clocks

Teams use “revision” and “version” interchangeably, and the confusion is a root cause of many configuration defects. A useful convention, used in most major PLM systems in some form, separates three clocks. An iteration (sometimes called a version or a minor save) is a working-state save of an object while it is being edited; it is private, cheap and disposable. A revision is a controlled, released state of the item that other people may depend on; it changes only through an approved change. A version in the strict sense is any identifiable state in the history of an object, so every revision is a version but most versions are not revisions.

Vendors differ in naming. Some systems number working saves as versions and letter the released ones as revisions; others use revision for both and distinguish by lifecycle state. The vocabulary matters less than the invariant: a released revision must be immutable, and anything that references it must be able to rely on that. If a released revision can be edited in place, no baseline built on it means anything.

Revision schemes should also say what a revision letter promises. Under the form-fit-function rule a new revision implies backward interchangeability, so a downstream user can substitute the latest revision for an earlier one. If the change breaks interchangeability, a new item identifier is required. Where the PLM system lets engineers bump the revision for a breaking change, effectivity is the only safety net left, and it is easy to misuse.

Product structure versioning

The product structure is a graph: assemblies use parts through structure links carrying quantity, position and find numbers. Versioning that graph is harder than versioning a single object, because a change can happen in three places: the item revision (the part itself), the structure link (quantity or position of a child within a parent), or the set of children (a component added or removed). Systems take two broad approaches.

In revision-specific (precise) binding, a parent revision points at specific child revisions. Release of a child change forces a new parent revision, and so on up the tree. Every state is explicit and a baseline is trivially a root revision, but one fastener change ripples to every ancestor, producing “revision storms” and large rollup workloads.

In late binding (floating), a parent points at the child item and a rule resolves which revision applies: latest released, latest released as of a date, or the revision effective for a unit. Ancestors are stable, and changes stay local. The cost is that the structure no longer has a single answer; you must evaluate it against a context (date, serial range, baseline, variant option set). Mature deployments mix both: precise binding inside a baseline, late binding in the working structure.

Effectivity and Structure Resolution

Effectivity states when, or for which units, a revision or structure link is valid, so one product structure can serve many units across time. Three kinds dominate: date effectivity (valid between two dates), unit or serial effectivity (valid for a range of serial or lot numbers), and event effectivity (valid from a milestone such as a plant cutover).

Figure 2: Effectivity ranges attach to structure links and map to unit ranges. Resolution picks exactly one revision per link for a given context.

Date, unit and serial effectivity compared

Date effectivity is the default in ERP-centred shops because dates are universal. It fails when production and release dates diverge: a change released on 1 March may only reach the line on 20 March, and units built in between carry the old part despite the new date. Date effectivity encodes plan, not reality, unless the date is the planned build date and is controlled.

Unit (serial or lot) effectivity is the standard in aerospace, defence, rail and heavy machinery, because it binds change to the individual product. Its advantage is that the as-built record can be derived without needing to know when anything happened. Its cost is that planners must commit to a cutover serial in advance, and the rule must be maintained for each variant and plant. Serial ranges are inclusive intervals and the open-ended upper bound (unit 1000 and above) must be represented explicitly.

Event or milestone effectivity ties a change to something like “first article after tooling approval”. It is convenient but ambiguous unless the event is itself a controlled object with a recorded date and serial.

A practical rule: use unit effectivity as the engineering truth, and derive date views from it for planning. The reverse derivation is lossy.

Resolution as a deterministic function

Resolution is a pure function: given a root item, a context (a unit identifier, or a date, or a baseline ID, plus option selections for variants), return the exact tree. Two requirements follow. First, effectivity ranges on sibling links to the same child position must not overlap; if they do, the result is ambiguous. Second, the function must be reproducible, which means that the effectivity rows themselves are versioned or append-only; otherwise the answer for a past date changes when someone edits history.

Overlaps and gaps are the primary integrity checks. For a given parent and position, ordered effectivity intervals should tile the unit range with no gaps (a gap means “no part specified for unit 500 to 540”) and no overlaps (two parts at once). Both are easy to detect with a query, and neither is checked by most PLM systems by default. The SQL in the next section includes the check.

Variants and effectivity are orthogonal

Effectivity answers “when”, options answer “which flavour”. A 150% BOM carries every variant’s links with option rules, as discussed in the 150% BOM and variant management post and the CPQ configurator post. Resolution therefore takes two coordinates: the unit axis, which comes from effectivity, and the option axis, which comes from the configuration order. Teams that implement only one tend to encode the other as separate part numbers, which multiplies items and defeats reuse.

The identification consequence: a unit’s configuration is the pair (baseline or effectivity context, option set). Store both on the unit record, not just the sales order number, because orders get amended and PLM options get renamed.

A Reference Data Model in SQL

The schema below is a sketch in PostgreSQL syntax, not a product schema. It is built to make three guarantees structural rather than procedural: released revisions are immutable, effectivity ranges on one structure position cannot overlap, and a unit’s configuration can be recomputed from stored facts. It uses range types and an exclusion constraint, which require the btree_gist extension.

CREATE EXTENSION IF NOT EXISTS btree_gist;

CREATE TABLE item (                       -- identity layer
  item_id      text PRIMARY KEY,          -- never reused
  item_type    text NOT NULL,             -- part, assembly, software, document
  is_ci        boolean NOT NULL DEFAULT false
);

CREATE TABLE item_revision (              -- definition layer
  item_id      text REFERENCES item,
  rev          text,
  state        text NOT NULL CHECK (state IN ('working','released','obsolete')),
  released_at  timestamptz,
  change_id    text,                      -- the ECO that produced it
  content_hash text,                      -- hash of attributes + files
  PRIMARY KEY (item_id, rev)
);

CREATE TABLE structure_link (             -- who uses whom
  link_id      bigserial PRIMARY KEY,
  parent_id    text NOT NULL REFERENCES item,
  position_no  int  NOT NULL,             -- find number
  child_id     text NOT NULL REFERENCES item,
  child_rev    text,                      -- NULL = late binding
  qty          numeric NOT NULL,
  option_rule  text,                      -- variant expression, e.g. 'VOLT=480'
  serial_range int8range NOT NULL,        -- unit effectivity, [lo,hi)
  date_range   daterange,                 -- optional date effectivity
  change_id    text NOT NULL,
  EXCLUDE USING gist (
    parent_id WITH =, position_no WITH =,
    coalesce(option_rule,'') WITH =,
    serial_range WITH &&)                 -- no overlaps per position
);

CREATE TABLE baseline (                   -- control layer
  baseline_id  text PRIMARY KEY,
  kind         text CHECK (kind IN ('functional','allocated','product')),
  root_item    text NOT NULL, root_rev text NOT NULL,
  approved_at  timestamptz NOT NULL, approved_by text NOT NULL
);

CREATE TABLE baseline_member (
  baseline_id  text REFERENCES baseline,
  item_id      text, rev text,
  PRIMARY KEY (baseline_id, item_id),
  FOREIGN KEY (item_id, rev) REFERENCES item_revision
);

CREATE TABLE unit (                       -- realisation layer
  serial_no    int8 PRIMARY KEY,
  product_id   text NOT NULL REFERENCES item,
  option_set   jsonb NOT NULL,            -- e.g. {"VOLT":"480"}
  built_at     timestamptz,
  as_built_hash text                      -- hash of captured as-built tree
);

Immutability of released revisions is enforced with a trigger that rejects any update to a row whose state is released, other than transition to obsolete. The content_hash lets an audit detect out-of-band edits: recompute the hash of the stored attributes and files and compare.

Note the exclusion constraint. It forbids two links for the same parent, position and option rule from covering overlapping serial ranges. That removes the “two parts at once” failure at write time. The “gap” failure still needs a query, shown here as a gap detector over ordered ranges:

SELECT * FROM (
  SELECT parent_id, position_no,
         upper(serial_range) AS gap_from,
         lead(lower(serial_range)) OVER (
           PARTITION BY parent_id, position_no, coalesce(option_rule,'')
           ORDER BY lower(serial_range)) AS gap_to
  FROM structure_link) s
WHERE gap_to IS NOT NULL AND gap_to > gap_from;

A recursive query then resolves the structure for one unit. It selects links whose serial range contains the unit’s serial number and whose option rule matches, then follows child items down. Late-bound links resolve to the latest released revision at the unit’s build time.

WITH RECURSIVE tree AS (
  SELECT l.parent_id, l.child_id, l.child_rev, l.qty, 1 AS depth
  FROM structure_link l
  JOIN unit u ON u.serial_no = 4471
  WHERE l.parent_id = u.product_id
    AND l.serial_range @> u.serial_no
    AND (l.option_rule IS NULL
         OR u.option_set ->> split_part(l.option_rule,'=',1)
             = split_part(l.option_rule,'=',2))  -- single KEY=VALUE rules only
  UNION ALL
  SELECT l.parent_id, l.child_id, l.child_rev, t.qty * l.qty, t.depth + 1
  FROM tree t
  JOIN structure_link l ON l.parent_id = t.child_id
   AND l.serial_range @> 4471::int8
)
SELECT * FROM tree ORDER BY depth;

The option-rule match here is deliberately simplified; real rule languages need an expression evaluator (see the configurator discussion in the linked variant posts). Everything else is ordinary SQL. For deep structures with heavy where-used traffic, a graph store can be faster, and the PLM graph database impact analysis post compares the options.

From As-Designed to As-Maintained

A product has several structures over its life, and configuration management is largely the discipline of keeping them related without forcing them to be identical. The as-designed structure (EBOM) expresses engineering intent, organised by function. The as-planned structure (MBOM) reorganises the same content by how it is built: phantom assemblies, consumables, tooling, plant-specific routings. The as-built record states what was actually assembled into a serialised unit, including the real serial or lot numbers of installed components. The as-maintained record continues the as-built record through service: replacements, repairs, upgrades and software updates.

The EBOM to MBOM transformation post covers the first transition in detail. The point here is what must be preserved across each transition: identity and traceability. Every as-built line must reference the as-planned line it fulfils, which references the as-designed link and revision. Break that chain and a field failure cannot be traced back to a design decision.

Figure 3: Structure lineage. Each downstream record references the upstream line and revision it realises, so a field serial can be traced back to a design baseline.

Why as-built is a recorded fact, not a computed one

A tempting shortcut is to compute the as-built from the as-designed plus effectivity, since the resolution function already exists. For nominal parts that gives the right answer on most units, and it fails exactly where it matters. Concessions, deviations and use-as-is dispositions put non-conforming parts into specific units. Supplier lots differ. Rework replaces a part on one unit only. A component swapped on the line because stock ran out of the new revision is invisible to effectivity logic.

Therefore keep two things: the computed configuration (what should have been built, from design and effectivity) and the captured configuration (what MES recorded). The difference between them, the configuration delta, is itself the most valuable status accounting output. A non-empty delta needs an explanation in the form of a recorded deviation or a rework order. An unexplained delta is a nonconformance that nobody has found yet. This is also the core of functional and physical configuration audits in the EIA-649 verification function.

As-maintained and the field loop

Once a unit ships, the configuration changes through events: part replacement, software update, repair, retrofit. The unit record must therefore be an event-sourced history, not a mutable row. Each event carries a date, the part serials removed and installed, the work order, and the authorising change (a service bulletin or retrofit ECO). With that, the current as-maintained structure of unit 4471 is a fold over its event log, and any past state can be replayed.

This is what makes the digital twin trustworthy. A twin that simulates wear on a pump must know which impeller revision is installed now, not which one was designed. The feedback path from service into engineering, described in the closed-loop PLM post, depends on the same configuration key: field failures aggregate meaningfully only when grouped by true installed configuration.

Software as a configuration item

Firmware, calibration tables and container images are configuration items too, and often the most volatile ones. They need item identifiers, immutable releases, and effectivity against hardware units, because the same hardware revision may run several firmware releases over its life. The practical pattern is to model a software release as an item revision whose content hash is the artefact digest, and to attach it to the unit as an as-maintained event whenever the over-the-air update completes. The SBOM for that release is then an attribute of the revision, linking CM to supply-chain compliance.

Change Control and Baseline Integration

Change management is the second EIA-649 function, but for configuration purposes the key property is that nothing in the definition or effectivity layers changes except through a change object. That is enforced in the data model by the change_id columns, and operationally by workflow gates.

What a change must record

An engineering change record should carry enough to rebuild the configuration question it answers: the affected items and their old and new revisions, the effectivity of each change (the cutover unit or date), the disposition of existing stock (use up, rework, scrap), and the baseline it modifies. The disposition and effectivity decisions are the part teams skip. Without them the change is released in PLM but nobody knows which physical units carry it. The ECR/ECO/ECN workflow post covers the process side.

Baselines as release gates

Baselines tie change to lifecycle. Before the product baseline is established, changes are cheap and handled informally by the design team. After it, every change to a baseline member needs formal approval, impact analysis across where-used, and an effectivity decision. The practical benefit is that the baseline becomes the unit of customer communication: “this order ships against product baseline PB-3”, a reference that survives later change.

A good implementation creates a new baseline rather than editing the old one. Baseline PB-3 plus approved changes becomes PB-4; both remain queryable. The difference between two baselines (a diff of member revisions) is then a ready-made release note and a ready-made list of what to retest.

Figure 4: Change control path. Approval produces new revisions, an effectivity assignment and a new baseline, all stamped with the same change identifier.

Integration with ERP and MES

PLM owns definition and effectivity; ERP owns planning and cost; MES owns execution and as-built capture. The integration contract should be explicit about who is master for what. PLM is master for item identity, revisions, structure and effectivity. ERP is master for plant-specific attributes, stock and costing. MES is master for as-built records.

The dangerous interface is the release to ERP. If PLM sends structures as flat snapshots with only a date, ERP loses unit effectivity and planners must reconstruct cutover from dates, reintroducing the date-versus-reality gap. Better: transmit the revision, the effectivity range (serial or date), the change identifier and the disposition. Most ERP systems have a native concept of engineering change number and effectivity date; unit effectivity may require customisation or a separate serial-controlled item model. Check how your ERP represents effectivity before promising unit-level truth.

The MES return path matters equally. As-built capture should post the installed component serials and lot numbers against the unit serial, with the process step and any deviation reference. Those records feed the configuration delta described earlier. For event-driven integration, change data capture patterns (see the Debezium CDC architecture post) can propagate released revisions without polling.

Trade-offs, Gotchas, and What Goes Wrong

Configuration failures are rarely dramatic. They are small inconsistencies that compound until someone asks a retrospective question and the data cannot answer it. The recurring ones are below.

Revision storms from precise binding. Strict revision-specific binding means a change to a leaf propagates new revisions up every ancestor. A single fastener change can force dozens of assembly revisions, each needing release, and teams respond by bypassing the rule. The mitigation is late binding within a working structure and precise binding only inside baselines.

Reusing part numbers for non-interchangeable change. Covered above, and worth repeating because it defeats every downstream control. Stock, purchase orders, supplier drawings and service catalogues all key on the part number. If form-fit-function is broken, a new number is cheaper than the cleanup.

Effectivity set at release, not at implementation. The effectivity date or serial is chosen when the change is approved, but the shop floor implements it later or earlier. The recorded effectivity then disagrees with reality for a band of units. Fix it by making the cutover serial a confirmed value, captured from MES when the first compliant unit is built, and by reconciling it against the planned value.

Overlaps and gaps. Without constraints, two engineers can each add a link for the same position with overlapping ranges, producing double quantities in the BOM explosion, or leave a hole so that units in the hole have no part. The exclusion constraint and the gap query above catch these; a PLM system that lacks equivalents needs scheduled integrity reports.

Mutable released data. Administrative “fixes” to released revisions, such as correcting an attribute directly in the database, destroy trust in every baseline that includes them. If a correction is necessary, release a new revision. Content hashes make silent edits detectable.

Over-selecting configuration items. Controlling every part as a CI creates change-board fatigue; approvers start rubber-stamping. Tier control to risk: tight control for safety-critical and interface items, light control (revision only) for standard parts.

Confusing configuration with variants. Teams sometimes model each effectivity step as a variant or each variant as an effectivity range. The two axes answer different questions, and conflating them is a design smell that shows up as an explosion of part numbers.

Migration damage. Legacy PLM data often lacks effectivity or has it only as free-text notes. Migrating structures without reconstructing effectivity yields a clean-looking system that cannot answer unit questions. Treat effectivity reconstruction as a first-class migration workstream; the PLM data migration post covers validation strategy.

There is also an honest cost to doing this well. Unit effectivity, captured as-built and event-sourced service history all add data-entry and integration work. For a low-volume, low-risk consumer product, date effectivity and a simple revision scheme may be the right trade. The depth of CM should follow the consequence of a wrong answer: recall cost, safety exposure, regulatory obligation and warranty liability.

Practical Recommendations

Start by deciding the unit of truth. If you ship serialised products with lifetime obligations, make unit effectivity the engineering truth and derive date views for planning. If you ship high-volume commodity goods, date or lot effectivity is probably enough, but still record lot genealogy.

Second, define the vocabulary in writing before configuring any system. Fix what an iteration, revision and version mean in your organisation, the form-fit-function rule for new part numbers, and which items are CIs. Most configuration pain traces back to an undefined term.

Third, model effectivity as data with constraints, not as notes or implied by release date. Put non-overlap in the database, run gap reports on a schedule, and test resolution against known units before go-live.

Fourth, capture the as-built and compute the delta. This is the cheapest high-value status accounting report you can build, and it surfaces uncontrolled change.

Fifth, treat integration contracts as part of CM: define master-of-record per attribute, and pass revision, effectivity and change identifier to ERP and MES, not flat snapshots.

A short checklist for a CM health review:

Every released revision is immutable, and an audit can verify it with a hash.
Each CI has a documented selection reason and a control tier.
Baselines are created, never edited; two baselines can be diffed.
Effectivity has no overlaps and no gaps per structure position, checked automatically.
Each change record states cutover effectivity and stock disposition.
Unit records hold option set, baseline reference and an event history.
Configuration delta between computed and captured structures is reported per unit.
ERP and MES receive unit effectivity or you have documented what is lost.
Software releases are items with artefact digests and per-unit effectivity.
A named person can answer “what is unit N, as of date D” in minutes, and you have tested that.

For vendor tooling, concepts map across systems but names differ, so check each product’s documentation for how it represents baselines and effectivity; the PLM vendor landscape and Aras vs Teamcenter vs Windchill comparisons are a starting point.

Frequently Asked Questions

What is the difference between a revision and a version in PLM?

A version is any identifiable state in an object’s history, including private working saves. A revision is a controlled, released state that others may rely on and that changes only through an approved change. Every revision is a version, but most versions are not revisions. Naming varies by vendor, so confirm the convention in your system, and keep the invariant that released revisions are immutable and referenceable from baselines.

What is a baseline in configuration management?

A baseline is an approved, frozen set of configuration items and documentation, at specific revisions, that serves as the basis for further work. Once established, changes require formal control. Defence practice distinguishes functional, allocated and product baselines, covering system requirements, item-level requirements and interfaces, and detailed design and acceptance criteria respectively. In PLM a baseline is an immutable set of references, not a copy of data.

What is effectivity in PLM and which type should I use?

Effectivity defines when or for which units a revision or structure link applies. Date effectivity is simple but encodes plan rather than reality; unit or serial effectivity binds change to individual products and suits regulated, long-life or high-value goods; event effectivity ties change to a milestone. A sound default is unit effectivity as engineering truth, with date views derived from it for planning.

Do I need unit effectivity if I already use date effectivity?

Only if you must answer unit-level questions: recall scope, warranty, repair parts, regulatory traceability. If production dates reliably match release dates and your obligations are batch-level, date or lot effectivity may suffice. If units built in the same week can carry different parts, or you serve units for years, date effectivity will eventually give wrong answers, and capturing serial-level as-built records becomes worthwhile.

How do EIA-649 and ISO 10007 relate to PLM?

Both are process standards, not software specifications. EIA-649 defines five CM functions: planning and management, identification, change management, status accounting, and verification and audit. ISO 10007 gives quality-management guidance for configuration management. PLM provides the data model and workflows that implement these functions, so the standards are a useful checklist for assessing whether a PLM deployment really supports traceability.

How is configuration management different from change management?

Change management is one of the five configuration management functions: it controls how controlled items may be altered. Configuration management also includes planning, identification, status accounting and verification. In practice, change management produces the events, and configuration management maintains the state: baselines, revisions, effectivity and as-built records that let you say what the product was at any point.

Configuration Management in PLM: Baselines, Effectivity and Product Structure Versioning (2026)