Configuration Baseline Management: Know What Changed

A flight-ready thruster bracket failed vibration qualification because a junior stress engineer rounded down a wall thickness to shave 40 grams. The CAD model was updated in SolidWorks on a Tuesday. The thermal analyst ran simulations off a branch created two weeks earlier. The drawing released to the machine shop reflected the lighter geometry, but the structural analysis report archived in the design history file referenced the thicker revision.

Nobody made an intentional mistake. The team just had no shared configuration baseline. When engineering artifacts live in separate silos, approval stamps are decorative fiction.

A configuration baseline is an agreed snapshot of requirements, architecture, CAD geometry, and verification data. It also means knowing the exact delta whenever anything changes. Teams that set up functional, allocated, and product baselines, capture design rationale, and map change deltas against CAD updates avoid costly redesigns and stay audit-ready.

Step 1: Name the baselines and define what goes into each one (functional, allocated, product)

A baseline is not a single, static milestone. Systems engineering standards define distinct baselines across the development lifecycle, and each serves a different programmatic purpose. Name them upfront, and nobody has to argue about whether an unexpected drawing tweak violates an executive commitment.

The functional baseline defines system-level operational expectations. It captures customer requirements, top-level constraints, and mission-critical performance criteria. Teams establish it at the System Requirements Review (SRR). It rarely contains part numbers. It contains operating temperatures, mass limits, duty cycles, and regulatory mandates.

The allocated baseline maps those system requirements down to subsystems and physical assemblies. It gets formally locked at the Preliminary Design Review (PDR) and documents functional allocations, interface definitions, and technical budgets. Here you define how total power divides across motor controllers and radio transmitters. To keep interfaces from slipping, tie these allocations into your interface control document.

The product baseline is the complete build-to specification, locked at the Critical Design Review (CDR). According to NASA configuration management guidance, configuration items and their documentation are formally identified and controlled, with the specific assets governed determined by project planning. If a shop floor technician can't assemble the product using only the assets named in this package, the product baseline is incomplete.

Step 2: Record the reasoning and verification evidence the baseline rests on

A configuration baseline that only records final numbers invites rework. An engineer sees a 3.2 mm wall thickness six months after CDR and wonders whether 2.5 mm would save weight. Without the recorded rationale, they have to rerun the original analysis or risk breaking the structural margin.

Every locked parameter in a configuration baseline must cite two things: the design rationale that selected the value and the evidence that verified it. If the allocated baseline sets a peak housing temperature of 65 degrees Celsius, link the trade study that compared passive radiation against active cooling. A disciplined engineering trade study shows the team which constraints eliminated the alternatives.

Verification evidence has to connect directly to requirement lines. A 200-page structural test PDF in a loose network folder verifies nothing. Index the specific page and pass/fail criterion to the requirement ID, and keep that link inside a structured verification cross reference matrix.

Capture context while the decision is hot. If thermal modeling in NX shows the component passes only with an anodized finish, record that constraint next to the CAD part number. Platforms like Tandem act as the context layer for hardware teams, connecting design intent, requirements, CAD models, and validation evidence in one place so institutional knowledge outlasts the original authors.

Step 3: Track changes against the baseline as they happen, not at the next review

Batch review is where configuration control dies. Engineers save intermediate CAD tweaks to local drives or temporary PDM branches and plan to reconcile them before the next formal gate. Undocumented drift piles up. By the time the gate arrives, reconciling the model against the requirements takes three weeks of forensic investigation.

Track changes against the approved baseline in real time. If an engineer opens SolidWorks, Onshape, Fusion, or NX and alters a bolt circle diameter, the system should register that as an unapproved delta against the product baseline immediately. Don't wait for an Engineering Change Order (ECO) meeting to discover that geometry moved.

Connect CAD repositories directly to requirements structures. A mechanical engineer updating an O-ring groove depth should see which sealing requirement and environmental qualification report depend on that face. When change tracking happens inside everyday authoring tools, teams catch baseline violations before cutting metal.

Tandem integrates with CAD tools including SolidWorks, Onshape, Fusion, and NX. When an engineer adjusts geometry, Tandem surfaces the change impact and runs requirement checks against the linked CAD to flag broken constraints right away.

Step 4: Scope the delta after a change: which requirements, decisions and results are touched

A geometric change rarely stays contained to one part. Shifting a mounting boss by 3 mm affects cable harness routing, structural load transfer, bolt torque margins, and assembly clearance. Scoping the delta means finding every downstream requirement, architectural node, and test result that edit invalidated.

Run an explicit impact assessment across three layers. First, the functional layer: does moving the boss reduce clearance below the minimum 5 mm required for shock isolation? Second, the architectural layer: does the revision push component mass past the allocated subsystem limit? Track these limits with active mass and power budget tracking. Third, the verification layer: does this change invalidate physical shake-table data collected on Rev A hardware?

If the answer to any verification question is yes, flag that test result as stale. It can't be shown to an auditor as evidence for the new design.

Give downstream engineering documents the same rigor. When a mechanical interface shifts, revisit the failure mode analyses and update your risk matrices by reassessing your DFMEA. Changes that invalidate previously verified physical characteristics also demand updated AS9102 first article inspection reports or renewed production sign-offs under a PPAP after design change.

Step 5: Decide when to re-baseline and what to carry forward

Re-baselining is a formal administrative decision. An individual engineer doesn't trigger it by committing an updated subassembly. Increment the baseline too often and the team loses a stable target. Wait too long and nobody trusts the documented baseline because daily engineering work has raced ahead of it.

Re-baseline when delta volume overwhelms the current record, or when a major milestone hits. Programmatic triggers include moving from PDR to CDR, approving a major Class I engineering change that alters form, fit, or function, or restructuring a system-level technical budget. If a new battery chemistry shifts the system thermal boundary condition by 15 degrees Celsius, keeping the previous baseline creates dangerous confusion. Re-baseline the allocated and product levels.

When you cut a new baseline, be ruthless about what carries forward. Mark obsolete verification test results as archived. Never port a pass verdict forward from an earlier revision unless an engineering assessment explicitly confirms the geometry delta doesn't alter the physical loading or thermal profile.

Document the re-baseline rationale in a formal record. Detail which baseline identifiers advanced (for example, System Allocated Baseline 1.2 to 2.0) and record who authorized the change. This audit trail shows program leaders and certification authorities the exact lineage of every system parameter.

Troubleshooting: when the baseline record and reality have already diverged

Most hardware teams don't work in greenfield conditions. They inherit programs where the documented product baseline lists Revision C drawings, the PDM vault holds Revision E models, and the physical test unit on the bench carries manual, unrecorded machine modifications.

Stop forward design changes until you reconcile the divergence. You can't control what you can't measure. Pick a physical serial number or a specific CAD assembly and run a physical configuration audit (PCA) and a functional configuration audit (FCA).

Walk through the physical hardware and compare every feature against the engineering drawings. Redline drawing mismatches immediately. Next, pull the active CAD model and compare it against the formal requirement allocations. Where the CAD contradicts the specification, investigate whether the requirement was obsolete or the CAD author made an unauthorized deviation.

Build a baseline delta register. Document every discrepancy, classify its severity, and assign an engineer to either update the baseline documentation or revert the physical design. Once reconciliation is complete, cut a fresh baseline (for example, Baseline 1.0-Reconciled) and freeze it. From then on, ban undocumented side revisions.

What Tandem does not do

Tandem is the context layer for hardware engineering, connecting design intent, requirements, CAD changes, and validation evidence. It does not replace your existing mechanical CAD or product lifecycle software.

Tandem is not a CAD tool and does not generate 3D geometry or 2D engineering drawings. It is not a PLM or PDM replacement.

Tandem does not run engineering calculations, execute simulation suites, or perform test case execution. Instead, it helps teams store and link validation evidence, track changes against technical requirements, and maintain the traceability thread throughout development.

Conclusion

A configuration baseline is not a paper archive for auditors. It is an operational tool that tells your team what is true about the hardware right now. When requirements, CAD modifications, and test evidence drift apart, schedule delays and physical failures follow.

Take control of your hardware baseline before your next design review. If you need to connect design intent, CAD changes, and test evidence in a single traceable system, look at how Tandem keeps your baselines synchronized across every revision.