12 — Maturity, release and progressive definition

The commitment comes first

A manufacturing engineer needs to know whether a bracket may be fabricated today. The answer cannot be inferred from the percentage of the vehicle design completed. A cooling specialist may still be investigating fan performance while the bracket mounting interface is sufficiently established for a limited fabrication commitment. Conversely, an attractive and apparently complete model may lack an agreed load case. Its visual completeness says little about its fitness for fabrication.

Overlapping design and manufacture requires readiness to be assessed against the particular commitment: identify its evidence and authorise only the use that evidence supports. The fictional programme comprises four customised internal-combustion vehicles. Vehicle 01 is in build, Vehicle 02 has major components ordered, and Vehicles 03–04 remain in planning. These different physical and commercial states make a single fleet-wide maturity label inadequate.

Maturity is the degree of demonstrated readiness for a specified use. Release is the authorised issue of identified information for that use under controlled conditions. A baseline is an identified, controlled set of information and relationships established for a defined purpose. These working definitions distinguish three practical questions: is the information adequate, may this recipient use it, and exactly which information formed the agreed reference? NASA describes configuration identification, change control, status accounting and verification as related configuration-management activities; that guidance provides context, rather than a mandatory vehicle process. NASA configuration management.

Effectivity answers a further question: under which identified vehicle, serial, date or other controlled conditions does this definition apply? A mature definition may remain unreleased; a released definition may apply only to Vehicles 03–04. Neither its readiness nor its release proves installation on Vehicle 01. Effectivity must be evaluated against the specified context, while execution evidence establishes the physical result.

Evidence has a purpose and a configuration

Readiness for packaging discussion requires different evidence from readiness for manufacture. A preliminary cooling envelope can support a layout discussion if its uncertainty is explicit. Machining a mounting face needs controlled geometry, relevant characteristics and a justified interface. Installing the module needs a compatible vehicle configuration, assembly instructions and material identification. Acceptance needs results from the actual relevant configuration, assessed against agreed requirements. None of these uses is established merely because a dataset has a status called approved.

The readiness record therefore identifies the intended action, consuming organisation, definition revisions, contextual occurrences, vehicle applicability, evidence references, unresolved issues and decision owner. It records what would invalidate the decision. It also identifies the next commitment that remains prohibited. A release for quotation must not silently become authority to place an unrestricted production order.

Requirements, architecture, analysis and product definition have different evidential roles. A customer hot-climate requirement in DOORS states an expected outcome. An architecture allocates cooling responsibilities. Analysis predicts behaviour under stated assumptions. Product definition specifies the radiator, fan, mounting and interfaces. Manufacturing planning defines how those items will be assembled. Execution records and test results establish what happened. Readiness requires the relevant chain, without forcing every element into one document or calling every element a model revision.

Evidence must identify its configuration. A thermal calculation for an earlier fan cannot justify the current module simply because its report title still says cooling analysis. The reviewer must establish whether changed inputs invalidate the conclusion. An unchanged conclusion can be retained through a recorded applicability assessment; repeating an expensive analysis is not inherently better than showing why its original result remains valid.

Review, approval and release

A review is a structured examination. Its output may include findings, recommendations, accepted evidence and unresolved actions. Approval is an authorised decision within a defined scope. Release makes identified information available for an authorised use. Contractual agreement is another decision, made by parties with contractual authority. One meeting can inform several decisions, but minutes saying review complete do not substitute for all of them.

A preliminary design review can conclude that the approach is credible while leaving detailed bracket definition unfinished. A local bracket release can be justified before a later whole-vehicle review if the required dependencies are controlled. Equally, a successful vehicle review cannot legitimise an unreviewed replacement connector. The lifecycle review chapter owns review purposes; the present chapter owns the resulting use permissions.

The decision sequence is practical. The definition owner assembles the evidence. Relevant consumers confirm that it supports their intended action. The technical authority decides adequacy within its delegation. The commitment owner accepts the resulting business exposure. Configuration management checks identification, applicability, restrictions and decision records before controlled issue. Quality or assurance contributes where the applicable acceptance or assurance plan requires it. A workflow administrator routes these decisions but does not acquire their authority.

Controlled conditional use

Conditional use is useful where uncertainty remains but can be bounded. It is not permission to proceed with an unspecified problem. For the cooling bracket, the open fan selection might be acceptable if all candidates fit an agreed envelope and impose loads within an agreed assessed range. The bracket decision would identify those bounds and the evidence supporting them. If the candidates do not share credible bounds, the commitment is premature.

The condition must be visible at the point of use. A note buried in a review presentation is insufficient if the shop receives an unrestricted drawing. The released package should state the permitted operation, affected vehicles, hold points, prohibited follow-on operations, responsible owner and condition-clearance evidence. A conditional release may permit cutting stock while withholding final drilling; that distinction must be reflected in the issued instructions and production controls.

Conditions require an expiry event or reassessment trigger. A customer change, supplier interface revision or test result outside the assumed range reopens the decision. An owner must decide whether existing work remains usable, needs rework or must stop. Merely changing the information status does not recover material already cut. Restriction withdrawal therefore needs acknowledgement from affected consumers and a record of work already performed.

A hot-climate change across four vehicles

Suppose the customer proposes hotter operating conditions in DOORS. The proposal is first assessed against the current agreed requirement baseline; receipt does not automatically accept its technical or contractual consequences. The cooling authority considers thermal demand, the electrical authority fan demand and protection, and integration checks packaging, air paths and interfaces. Manufacturing reports which brackets and installations already exist. Procurement identifies orders that can still change.

For Vehicle 01, a released bracket may already be installed. The team identifies its physical state and available evidence before deciding whether it can remain. For Vehicle 02, a supplier order might be amended before manufacture, subject to commercial agreement. Vehicles 03–04 may adopt a revised module directly once its definition and implementation are authorised. These are possible dispositions, not predetermined engineering solutions.

The old baseline remains necessary to explain the earlier build. A new baseline records the authorised future configuration and its applicability. A bracket part identity, its revised definition, each occurrence in a vehicle and each actual installed bracket are separate subjects. Changing a revision does not demonstrate physical replacement. The implementation record must show which vehicle received which configuration and what inspection or test evidence applies.

The module crosses assembly boundaries. A fan connector belongs to an electrical relationship as well as a physical installation; a hose joins module and engine-side endpoints. Release adequacy must include compatibility across both sides. It cannot stop at a supplier assembly boundary. The module may be procured as one item, installed as one package and maintained as several replaceable items. Readiness is assessed against the relevant view rather than assuming those boundaries coincide.

Information and system behaviour

A logical release package links a decision to a fixed configuration reference, evidence set, permission, restrictions and recipient acknowledgement. These are logical requirements, not asserted Teamcenter object names. NX supplies selected mechanical definition, Capital selected electrical definition, Teamcenter lifecycle and configuration coordination, and SAP purchasing and production context. Customer requirements remain in DOORS. Exact integrations and modules remain to be selected.

The consuming system must distinguish current information from information authorised for the current order or vehicle. A screen that always displays the newest revision can undermine a carefully controlled baseline. Exchanges should therefore carry identity, revision, applicability, intended use and restriction references, with acknowledgement and failure handling. Where a recipient cannot enforce a restriction electronically, the operating process must provide a controlled instruction and hold point.

A failed transfer is an unresolved release task. Publishing a package in Teamcenter does not prove that a supplier received it, that SAP orders changed, or that a technician stopped using an earlier instruction. Release completion and change implementation completion should be separately visible. The detailed change lifecycle follows in chapter 13.

Scale and proportion

At millions of occurrences, readiness cannot depend on manually opening every assembly. The enterprise needs queries by definition, use context, release purpose, applicability and outstanding condition. Reuse makes evidence inheritance valuable, but the inherited justification must state its limits. A bracket approved in one load environment does not acquire universal readiness through repeated use.

During multi-year manufacture, evidence and decisions outlive personnel and software releases. Durable identifiers, reproducible configuration references and readable reasons matter as much as a current dashboard. Thousands of people need consistent permission semantics across suppliers and sites. This is a governance requirement, not a measured performance claim for any selected platform.

Proportion comes from the commitment. A reversible study can use a short recorded agreement. An irreversible fabrication decision affecting several suppliers needs stronger evidence and acknowledgement. Neither deserves automatic treatment based solely on drawing size or meeting seniority. The practical result is a controlled path from sufficient knowledge to a specific action, with the remaining uncertainty still visible.