SYSE.13 - Establish Configuration Identity, Variants, and Effectivity

SYSE.13:0 - Use This When

Use this pattern when an engineering decision depends on an actual System’s identity and configuration or on a description’s applicability—for example, which physical unit has which part and installed software, or which description edition applies to that unit—but records reuse a label such as a part number, version, baseline, release, or status as if it answered all of those questions.

Begin with the receiving decision and the actual Systems whose differences can change it. Select only the configuration-item boundaries needed for that decision. Restore every distinction used by the case—for example, actual units, product-family variants, software packages and installed realizations, description editions, reference baselines, or effectivity. Then state the supported correspondences that allow one record to be used with another.

The first useful result is a decision-specific configuration basis: an episteme that tells an engineer which actual units and descriptions can be used for one decision, where each claim applies, which collisions or gaps remain, and what later change reopens it. The actual Systems and configurations are its subjects; descriptions carry its claims; evidence supports them; and release decisions and performed Work remain separately identified. Use the governing FPF pattern directly when one identity, structure, characteristic, edition, or temporal claim already answers the question. Use SYSE.7 when several descriptions must be made jointly usable, SYSE.14 when a proposed or performed change must be connected to release, and SYSE.19 when a changed source may reopen earlier decisions.

SYSE.13:0.1 - Terms and Distinctions

Name in this pattern	What it denotes
actual configuration	The decision-relevant actual constituents, obtaining relations, and characteristic values of one identified actual System over an interval. A configuration description carries claims about that configuration; a database value or dashboard status is not the configured System.
configuration item	A decision-local designation of an already identified entity whose separate identity, parthood where relevant, and change matter to the receiving decision. The entity may be, for example, a System, physical part, software-package episteme, or description episteme. The designation creates no universal kind.
physical or serial unit	One actual System individual. Its part number, family description, bill of material, variant name, and status record are separate descriptions or claims.
product family	A stated grouping of actual Systems or possible-future System referents under a classification and variation scheme. The current claim must say whether it concerns a kind, set, lineage, or description.
variant	A combination of design or configuration claims, normally carried by a description and possibly realized by actual units. A variant label does not prove realization.
software package and installed realization	In this pattern, a package or build episteme specifies software content. The content installed in a unit and its actual operation in that unit are separate world-side facts whose correspondence to the package needs evidence.
description edition	One episteme related to an earlier edition only under an edition-continuity relation. A changed filename, timestamp, or revision number is insufficient.
baseline	A selected reference episteme or claim set used for one comparison. Actual configuration, evidential support, authority, and release require their own claims or decisions.
effectivity	A claim that a description, change, release, or configuration claim applies to identified subjects and conditions—for example, Systems, serial units, lots, sites, intervals, operating conditions, or a stated combination. A date alone is insufficient when the subject or condition is unknown.
status	A claim or decision value about a subject for a use and interval. A value such as approved, released, installed, or current in one tool does not establish the corresponding world-side fact.
comparison labels such as as-designed, as-realized, as-integrated, or as-maintained	Source terms for local comparison roles of configurations and descriptions. Recover the role used by the decision; the label imposes no lifecycle and guarantees no correspondence.

Record the performing Agent, assignment, Method, and Work separately from the configuration basis and from the Systems, descriptions, and evidence it concerns. Record the deciding Agent separately when another Agent performs the configuration Work.

SYSE.13:1 - Problem Frame

Continuing engineering keeps several configurations relevant at once—for example, candidate architectures, manufactured variants, installed software realizations, experimental units, or service replacements. Engineering, manufacturing, operating, and maintenance descriptions can also differ. Each kind of receiving Work may need different item boundaries.

Shared identifiers and records—whether kept in a product-data system, a bill of material, linked-model infrastructure, or a naming standard—do not remove the semantic problem. These resources can preserve identifiers and links, while engineers still decide what each identifier denotes, which differences matter to the decision, and what evidence connects the record to the actual System. One label can hide incompatible granularity; different labels can denote the same unit under different schemes.

SYSE.13:2 - Problem

A decision-specific configuration basis answers eight questions:

Which actual or intended subject does the decision concern—for example, a System, part, serial unit, lot, or site?
Which boundaries need independent identity for this decision, and why?
For each identifier, which reference scheme gives it meaning, which Agent issues or maintains it, over what interval, and in which record?
Which variant and software-package claims are candidates, and which actual units have evidence of realizing them?
Which constituents and relations obtain for each unit and interval, and which characteristic values are supported—for example, installed realizations or parameter values?
To which subjects and conditions does each description or change apply—for example, units, lots, sites, intervals, or operating conditions?
What does each cross-tool mapping preserve or lose, what evidence supports it, and is that loss acceptable for receiving Work such as build, integration, release, operation, service, or modernization?
Which Agent can settle a disputed identity or mapping, which receiving Work relies on the answer, and what change reopens it?

Without those answers, every local record can be internally consistent while the engineering decision is wrong. Firmware can fit one board variant and fail another; an engineering bill of material can disagree with an installed unit; a release can name the right part number but omit the units to which it applies.

SYSE.13:3 - Forces

Recurring tensions include:

A change can preserve or end an entity’s identity; reusing its earlier label settles neither case.
Design, manufacturing, integration, operation, and maintenance need different item boundaries, while receiving Work needs supported mappings among them.
Family descriptions enable reuse; release, service, and failure decisions often depend on serial units and installed configurations.
Extra fields and links cost maintenance, while one omitted unit, edition, condition, or correspondence can invalidate the choice.
Several descriptions can agree with each other and still be wrong about the actual System.
Automated comparison exposes differences among identifiers, bills, hashes, and editions quickly. Engineers still determine the intended referent, applicability, and acceptable loss.
A selected reference basis aids comparison while experimental, installed, and service configurations can legitimately coexist.

SYSE.13:4 - Solution

Develop the smallest configuration basis that lets one engineering decision distinguish actual Systems, variants, descriptions, and applicability.

Use the record-and-time explanation when this correspondence is unfamiliar; continue with an adequate existing basis when it is already established.

SYSE.13:4.1 - Perform the Move

Name the decision and differences that matter. State the deciding Agent, question, use, project System-of-interest or other subject, interval, and configuration differences that can change the result. Do not begin by inventorying everything.
Identify actual and intended subjects. Name every subject needed by the decision—for example, an actual unit, part, site, or possible-future referent. State needed part–whole and structure relations; a product code or bill-of-material row is not the bearer.
Choose item boundaries for this use. Designate only the entities that must be distinguished independently, such as Systems, parts, software-package epistemes, or descriptions. Different kinds of receiving Work may choose different boundaries; relate them instead of forcing one granularity.
State identifier schemes and mappings. For each item, name the identifier, scheme, issuing or maintaining Agent, interval, and supported mapping to another scheme. Shared spelling is not identity; a mapping need not be symmetric or lossless.
Separate variants, units, packages, installations, and editions. Name the variant description, actual units claimed to realize it, software package, observed installed realization, and description edition. Mark unsupported realization claims as gaps.
State actual configuration and effectivity. Name the actual constituents, obtaining relations, and characteristic values needed by the decision—for example, parts, interfaces, installed software, or parameter values. State the supporting evidence and interval, then name the subjects and conditions to which every description or change applies. Keep candidate and intended configurations modal.
Choose a baseline only for comparison. Identify the reference episteme and its decision. Keep it unchanged for that comparison; establish actual configuration and decision authority separately.
Check collisions and return the basis. Align bearer, boundary, scheme, edition, interval, and tolerance before comparing. Classify each problem by the action it requires—for example, repair an actual incompatibility, reconcile contradictory descriptions, qualify a lossy mapping, obtain missing evidence, or accept a harmless naming difference. State receiving Work, the Agent with revision authority, blockers, and the smallest reopen condition.

The numbered presentation is an A.22.CGUS learning unfolding, not a lifecycle. Work may overlap—for example, identification, design, realization, integration, observation, or change Work—but receiving Work can rely only on claims whose bearer and effectivity are known for that use.

SYSE.13:4.2 - Record the Result

Field	Required content
receiving use	Decision, deciding Agent, actual System or intended-system designator selected as the project system-of-interest, or another subject, interval, affected Work, and differences that can change the result.
subjects and item boundaries	Actual Systems, serial units, parts, or sites; possible-future referents where needed; selected item designations; rationale; and needed part–whole or structure claims.
identifiers and mappings	Schemes, issuing or maintaining Agents, intervals, directional mappings, preserved meaning, losses, evidence, and use limits.
variants, units, software, and descriptions	Candidate variant descriptions, actual-unit realization claims, software packages, installed realizations, description editions, and unresolved gaps.
configuration and effectivity	Actual constituents, obtaining relations, characteristic values, supporting evidence, and interval; subjects and conditions to which each description or change applies.
reference and collisions	Optional baseline and purpose; incompatible actual elements, contradictory claims, unsupported or lossy mappings, missing evidence, and harmless naming differences.
maintenance and return	Agents and authority for revision, receiving Work, reliance limits, blockers, and smallest reopen conditions.

The basis may be published in a form such as text, a table, a product-data query, a model view, or a generated report. Publication form and repository location determine neither its identity nor its truth.

SYSE.13:4.3 - What Changes in Practice

Engineers ask whether the current configuration basis distinguishes the units, variants, descriptions, and conditions needed by the decision. Product-family reuse remains available, while release and service claims become serial-unit and effectivity aware.

Tools may expose a mismatch without deciding what it means. Engineers resolve the first collision that can change the decision and leave unrelated inventory alone. A changed source reopens the smallest affected claim rather than freezing the whole product or silently rewriting the reference baseline.

SYSE.13:4.4 - Use a record for one configuration-dependent claim

Use this explanation when you can work with the records of your practice but are unsure which state, event or period a record supports. Start with the claim your present decision needs. An adequate established correspondence can be used directly.

Name the actual or intended subject of the record and the subject of the decision. Recover the description edition, identifier scheme and conditions when they can change this use. A common name or a later date does not establish the correspondence. Keep an installed state distinct from a design, plan or status entry. Different identifiers can be harmless when their supported mapping preserves the subject needed by the decision.

Distinguish three questions about time. When was the record made or the account entered? When did the reported state or event actually obtain? At what time, or over what interval, must the claim needed by the decision apply? The answers can coincide, but one answer does not establish the others. Recover only the distinctions needed by your claim.

An entry date helps recover the history of an account. Use evidence of installation to establish or bound when it occurred. A quotation has its own subject and conditions: it can be written before installation yet cover the subsequently installed configuration, or be written later and still cover a different configuration. Its issue date does not establish the period for which its terms apply.

Place the relevant states and events on the interval the decision concerns. Attach an observation to the supported state at its observation time. To use that observation over a longer interval, identify the grounds for that extension. Split an interval at a configuration change that affects the claim. Keep unsupported parts qualified.

When a later record supplies a supported correction of the earlier account, revise the affected correspondence and retain the earlier account as history. Entry of that correction is not another physical installation. When the sources do not settle the state or event, return the uncertainty to the receiving decision.

SYSE.13:4.4.1 - When the change time is uncertain

Suppose the evidence supports an earlier state, a later state and exactly one transition between them, but bounds its time τ only by a ≤ τ ≤ b. The case treats the transition as one boundary: from τ onward the state is the later one. Before a the earlier state is supported; from b onward the later state is supported. At times in [a,b), a claim that depends on which state obtained remains conditional unless further evidence settles it. Additional transitions, reversals or gaps require a different history.

Apply the receiving calculation or decision to the admissible event times. Retain conclusions that remain supported across them. Qualify the parts that change and obtain the smallest worthwhile observation or source answer that could settle the receiving question. A midpoint is an estimate only when there are grounds to use it; it is not a recovered event time.

Quantities calculated from the same unknown event can vary together. If one component leaves when another enters and this is the only replacement in a continuously operating window [u,v), their durations are τ−u and v−τ; their sum is v−u for every admissible τ. For τ∈[8,10] in [6,12), the paired durations include (2,4), (3,3) and (4,2): the total is always 6. Combining both separate maxima would describe no admissible history. Stops, different duty or another exposure measure require the receiving practice’s own calculation.

Return to your task. Bring back the supported correspondence, its time limits and remaining uncertainty. Explain which record supports which claim and which changed fact would change the answer. Use the receiving method to decide whether a gap matters, which further result is worth obtaining and which subject-specific evidence or permission is still needed. Retain unrelated usable results.

If you came from EAM.3’s first use, return to its quotation task and discussion. If you came from MNT.12’s first use, return to its event and exposure task. Otherwise return to the decision you named at the start.

SYSE.13:5 - Worked Case: Pump-Controller Variants and Ten Installed Units

A pump manufacturer is deciding which of ten installed controllers may receive a cold-start protection change. The first export gives all ten the same product number and the status current. Inspection results and source records show four different decision-relevant groups:

Installed units	Observed configuration	Effect on the release decision
S001–S004	Input board IO-A and the older installed firmware realization.	Outside the candidate firmware package’s hardware compatibility claim.
S005	Input board IO-B and temperature sensor TS-2, but no current sensor calibration evidence.	Possible candidate after calibration evidence; not currently eligible.
S006–S008	IO-B, TS-2, current calibration evidence, and an installed realization corresponding to the supported firmware lineage.	May enter the current release comparison, subject to installation and verification Work.
S009–S010	IO-B and TS-2; the database says installed, but current calibration evidence is absent.	Possible candidates after the missing evidence is obtained; status alone is insufficient.

The candidate firmware package is an episteme describing support for IO-B. It is not the software realization currently executing in any controller. Installation and observation are needed before that correspondence can be claimed.

The engineering and manufacturing bills of material use different item boundaries. Engineers maintain a directional mapping from the engineering board item to the manufacturing board-and-harness items. The mapping loses installation-routing detail and cannot be used in reverse without another check. They do not create configuration items for every fastener or database row because those differences cannot change this release.

The effectivity proposal names S006–S008, the supported operating-temperature conditions, the candidate package edition, and the required installation and verification Work. S001–S004 are excluded; S005 and S009–S010 retain explicit evidence gaps. A selected reference configuration supports comparison but does not claim that every installed unit realizes it.

The configuration basis can inform SYSE.14 and bound the integration Work in SYSE.11. It establishes neither installation, permission, release, nor successful operation. A changed board, sensor, package edition, calibration source, inspection, or release question reopens only the affected unit and correspondence claims.

When the full pattern is unnecessary. If a laboratory engineer needs only to know whether one already identified controller contains IO-B at the current inspection time, direct System, structure, temporal, and evidence patterns answer the question. A product-family configuration basis adds no value.

SYSE.13:6 - Bias Annotation

Document-control practice can make the record or baseline appear more real than the physical unit. Software-centred records can hide installed hardware and effectivity; hardware-centred records can collapse software packages and description editions into part numbers. Start with actual Systems and the receiving decision.

A signal such as an official identifier, required form, vendor schema, digital-thread label, or declared conformance status supports only the claim it actually records; actual project use and configuration correspondence require their own evidence. Use expert judgment with an explicit epistemic status when broad field evidence is unavailable.

SYSE.13:7 - Conformance Checklist

One receiving decision and the configuration differences that can change it are stated.
Each actual System and part has its own identity; descriptions, identifiers, records, and status claims have their own bearers.
Every configuration-item boundary has a decision-specific reason.
Product-family variants, actual units, software packages, installed realizations, and description editions remain distinct.
Each load-bearing effectivity claim names the units or lots, sites, intervals, and conditions required by the use.
Cross-scheme mappings state direction, preserved meaning, loss, evidence, and use limits.
Reference epistemes, status claims, actual configurations, decisions, permissions, releases, and performed Work retain separate identities and relations.
The basis records collisions, unsupported correspondences, missing evidence, receiving Work, revision authority, and the smallest reopen conditions.

SYSE.13:8 - Common Failures and Repairs

These recurring failures can change the engineering decision:

Failure	Repair
Treat one identifier as one bearer everywhere	Name the bearer and reference scheme for each use; state supported mappings among schemes.
Treat configuration item as a universal kind	Use it as a local designation of an already identified System, part, software package, or description chosen for this decision.
Treat a variant as an installed unit	Keep the variant description and unit separate and require realization evidence.
Treat latest as applicable	Name the edition and effectivity; current publication does not establish compatibility with the unit.
Treat a baseline or green status as reality	Keep the reference or status episteme separate from the observed actual configuration.
Make one product-data system the ontology	Use it as a resource and recover Systems, parts, epistemes, relations, schemes, and losses outside its schema when needed.
Inventory everything before deciding	Select the smallest item boundaries and claims that can change the receiving decision.

SYSE.13:9 - Consequences

Release, integration, service, and modernization decisions can identify the units and descriptions they concern. Product-family reuse keeps serial-unit differences visible, and cross-tool automation can support comparisons through declared identifier schemes and supported mappings.

The cost is maintaining selected identifiers, mappings, evidence, and effectivity claims. Some questions remain unresolved until actual-unit observation or authority is available. Application profiles may still need specialized Methods for domain relations—for example, interchangeability, software-package identity, regulated genealogy, ship configuration, or electrical qualification.

SYSE.13:10 - Rationale

The configuration basis is an episteme for one engineering decision. Starting from one decision makes the boundary and maintenance burden testable. Keeping actual Systems, variant descriptions, software packages, installed realizations, episteme editions, baselines, and status claims separate prevents the situation in which every record is valid but no one knows which unit may be changed or released.

Effectivity is load-bearing because change rarely applies uniformly across a family. Time is only one condition; another condition—for example, serial unit, lot, site, installed part, software realization, environment, or operating envelope—may determine applicability.

SYSE.13:11 - SoTA and Source Use

During configuration Work, distinguish product kinds, actual units, variants, versions, description editions, releases, status and effectivity. Configuration Work can continue concurrently with other engineering Work; select the needed identities and relations for the configuration question.

Source line	Retained contribution	Limit and guard
Frank B. Watts, Configuration Management for Senior Managers (2015), historical practitioner lineage	Recurring manufacturing distinctions among part identity, revision, interchangeability, bill of material, technical release, effectivity, implementation, status, and field change.	The paper-form, phase, central-department, sanction, and universal-policy recommendations are not current DPF authority.
Brovar, Sadeghzadeh, and Fortin 2024	One engine-front-mount case shows that engineering and manufacturing descriptions need explicit configuration links rather than a shared label.	One directional matrix case; reverse use and universal digital-thread architecture are not established.
Wu et al. 2025	One landing-gear case connects heterogeneous model semantics, conflict handling, traceability, and model versioning.	The study concerns MBSE model versions in one case; it does not establish physical-unit effectivity, release, supply coordination, or broad dominance.
Lehner et al. 2025	A systematic mapping study makes the heterogeneity of model-driven digital-twin uses and domain dependence visible.	Publication volume and tool capability do not establish one twin ontology, one configuration Method, industrial prevalence, or effectiveness.
Bantwal and Fatahi Valilai 2026	A proposed engineering-change framework and brake-caliper demonstration connect parts, representations, supply constraints, CAD/CAE, ERP/PLM, and validation.	One proposed framework and demonstration support the need for connected configuration claims, not a universal item granularity or adopted SoTA workflow.

Refresh a source-dependent claim when a new edition changes an item-boundary distinction, mapping capability, effectivity rule, evidence limit, or transfer conclusion used here. Standards status, academic visibility, vendor promotion, or a product named digital thread supplies no prevalence or effectiveness claim. When no affordable empirical prevalence evidence exists, state an expert estimate as such.

SYSE.13:12 - Relations

A.1 and A.1.SCR distinguish actual Systems from intended referents. A.22 governs selected structures, A.19.SPR state-like claims, and C.27.TA temporal aspects. None by itself produces an engineering configuration basis.
C.2.1 keeps descriptions, editions, subjects, reference schemes, carriers, and publications distinct. A.10 and B.3 govern evidence and assurance when current; neither proves the actual configuration.
F.10, A.21, A.2.8.PER, C.11, A.15.1, and A.3.4 distinguish status, gate, permission, choice, Work, and transformation from configuration claims.
A compatible SYSE.6 result can supply architecture constraints for the same System, decision, configuration, and horizon. It neither selects item boundaries nor proves an actual configuration.
A decision-specific configuration basis can inform SYSE.14 only for the same change and release question and can inform SYSE.11 only for the named integration or modernization increment. It establishes neither release nor realization.
SYSE.7 coordinates several decision-usable descriptions. SYSE.19 revalidates decisions after a relied-on source changes. Co-use creates no additional dependency or temporal order.
Application profiles—such as software, electrical, mechanical, manufacturing, medical-device, ship, or building profiles—may specialize item identity, effectivity, interchangeability, evidence, and release when the kinds or uses of Systems designated as project systems-of-interest change the working move. A profile label alone adds no pattern.