SYSE.7 - Keep Engineering Descriptions Usable Together for Decisions

SYSE.7:0 - Use This When

Use this pattern when an engineering decision depends on several epistemes—for example, descriptions, models, requirements, analysis reports, configuration records, test results, or records of operating observations—but the project cannot yet tell whether they concern the same subject, compatible configurations and intervals, mutually interpretable claims, or the evidence needed by that decision.

The first useful move is to name one receiving decision and the smallest set of claims that could change it. For every description used by those claims, identify its subject, edition, reference scheme, intended use, currentness, and the Work that relies on it. State a cross-description relation only when its participants and meaning are recoverable.

The result is a decision-bounded account of usable descriptions and their relations: it names usable claims, contradictions, unsupported correspondences, omitted claims, and refresh conditions. Its technical label is EngineeringDescriptionEnsembleAccount@Project, a project-local U.Episteme. The account remains distinct from the described engineered System, the descriptions it selects, their publication carriers, configuration baselines, and evidence that their claims obtain.

Use a simpler description directly when one episteme already supports the decision and no material cross-description claim is being made. Use SYSE.10 when the problem is the credibility of an evidence source—for example, a model, experiment, or trial—for a named engineering claim; use SYSE.13, SYSE.14, or SYSE.19 when configuration identity, change, release, or a changed source edition is the governing problem.

SYSE.7:0.1 - Terms and Distinctions

Words such as model, view, specification, requirement, data, digital thread, digital twin, traceability, and single source of truth are recognition cues. Before relying on them, restore the objects and relations that matter to the decision.

Cue	Decision-usable interpretation in this pattern
description	One claim-bearing `U.Episteme` with a recoverable `EntityOfConcern`, claim content, effective reference scheme, edition, and current use. An expression or carrier—for example, a file, diagram, database row, screen, or spoken utterance—may carry it or be used in a publication occurrence; identify the episteme and publication relation separately.
model	A description episteme used under a stated modeling purpose, assumptions, omissions, interpretation, and validity boundary. Record these conditions independently of its executable, mathematical, visual, or tool form.
view	The same episteme individual qualifies as `U.View` only when a `U.Viewpoint` episteme and obtaining `EpistemeViewpointConformanceRelation` are present under `E.17.0`. Establish that membership through the conformance relation; presentation labels—for example, a page title, diagram type, dashboard face, or `viewpointRef`—remain publication cues.
viewpoint	A claim-bearing episteme specifying concerns and conformance rules for a view. A cue such as a stakeholder name, discipline label, screen layout, or familiar view list qualifies only when it supplies that content.
representation	A visible or formal expression and, when current, its correspondence to an independently recovered object, relation, claim, or mathematical structure. Treat expressions—for example, diagrams, tables, queries, graphs, or executable files—as representations. Ground performed Work through Agent–Work attribution, authority through its own relation, and depicted claims through evidence. Use `C.29` for a declared mathematical-lens use and its preserved and lost structure.
publication	An `E.24.PUB` publication occurrence with its form, carrier, audience, bounded use, and selected source edition when those identities matter. Ground the described world-side relation independently and use `E.17.0` when `U.View` membership matters.
engineering data	Claim-bearing epistemes and values used in engineering Work, together with the identities, editions, reference schemes, provenance, applicability, and relations needed by that use. Ground their world-side subjects separately.
trace or link	A recoverable direct relation: for example, a claim depends on a source claim; a test result assesses a named claim; an interface description concerns a selected configuration; or a change affects a configuration item. A hyperlink or same-name token is only an index until the intended relation and participants are stated.
digital thread	A maintained arrangement of description, source, configuration, change, publication, and use relations across named engineering Work. State its bounded use, participating relations, Agents assigned to maintenance Work, and currentness conditions instead of inferring them from one chain or repository.
digital twin	A selected description, model, data, automation, observation, and use arrangement concerning a named subject. Support every additional claim—for example, about System kind, fidelity, synchronization, beneficial use, or completeness—on its own grounds.
ensemble	The selected description epistemes and relations needed by one bounded set of decisions. This is an ordinary collective word. Identify each carrier and governing reference scheme independently.
consistency	A named set of claims can be jointly used under stated schemes, configurations, intervals, and tolerances. Establish it from claim content under those conditions; syntactic agreement, shared identifiers, and storage co-location are only comparison cues.
coherence	The selected claims and their correspondences support the receiving decision without an unresolved contradiction or missing distinction material to that use. Its scope is the named decision and material claims.

The described subject, description episteme, model use, representation, mathematical lens, view, viewpoint, publication occurrence, carrier, source, evidence relation, configuration, and performed Work remain different objects. Restore only the distinctions that can change the receiving decision.

SYSE.7:1 - Problem Frame

Engineering decisions rarely depend on one self-sufficient description. A controller architecture can involve, for example, an outside-use account, a description of functional organization, a bearer-and-interface description, an equation-based plant model, a control-state description, a wiring schedule, a component catalogue claim, a configuration record, a test procedure, recorded test observations, or an assurance argument. These epistemes may concern different subjects, scales, configurations, and intervals. They may use different reference schemes and intentionally omit different characteristics.

The difficulty is not solved by putting every expression into one repository or by declaring one model authoritative. Engineers need to know which claims support which decision, what each claim concerns, how a cross-description comparison is warranted, and what world-side or evidence result would expose a mistake. Otherwise a coordination cue—for example, a model identifier, diagram label, common part number, generated link, or synchronized timestamp—is silently treated as identity and agreement.

Two symmetric failures recur.

One-model overreach. A familiar product—for example, an architecture model, CAD assembly, requirements database, ontology, simulation, or digital-twin product—is expected to contain every useful engineering distinction. Its local ontology and omissions then become hidden project law.
Unrelated-description accumulation. Specialists maintain useful local epistemes but no one states their shared subjects, configuration applicability, interpretation, evidence, contradictions, or receiving decisions. The project has many artifacts and little joint decision support.

SYSE.7 describes the applied engineering move between these failures. FPF supplies the transdisciplinary distinctions for representations, epistemes, publications, views, evidence, configurations, and source currentness. This pattern specializes their joint use for engineering descriptions supporting decisions—for example, concept, architecture, realization, integration, operation, assurance, or modernization decisions— about an engineered System and its affected Systems.

SYSE.7:2 - Problem

A hidden gap in the description set can invalidate an engineering decision. Check whether the descriptions make the following clear:

the receiving decision and the claim that a description is expected to change;
the actual System, intended referent, configuration, part, environment, Work occurrence, or other holon that a claim concerns;
whether two descriptions concern the same individual, the same kind, related parts, successive configurations, or merely similarly named subjects;
the reference scheme, scale, coordinate frame, units, tolerance, assumptions, omissions, and modeled interval;
whether an alleged cross-description link is a representation correspondence, source dependency, configuration relation, transformation relation, evidence relation, or only a navigation aid;
the edition and currentness of each source episteme and the Work that still relies on it;
whether a diagram or simulation output describes a candidate, an intended configuration, an actual configuration, an observed occurrence, or a possible-future structure;
which Agents produced, checked, changed, published, or use each result, through which Work and with what capability and authority;
which contradiction, unsupported relation, or omitted characteristic blocks the next decision;
what observation, configuration change, source change, or decision change requires refresh.

The result is often a false impression of precision. Every artifact may have an identifier and version while the central engineering claim remains ambiguous. Automated trace generation can multiply this impression: thousands of links exist, yet the project cannot say which direct relation each link records or which decision would change if the linked claim failed.

SYSE.7:3 - Forces

Force	Tension to manage
Local specialist fitness and cross-specialist use	A local model should use the distinctions needed by its specialist Work; a receiving engineering decision still needs explicit correspondences and limits.
Minimum useful set and missing perspectives	Every additional description costs maintenance and collision checking; an omitted claim—for example, a functional, physical, temporal, affected-System, realization, or evidence claim—can make the decision unsound.
Stable subject identity and changing configurations	Several epistemes may concern one enduring System while referring to different particulars—for example, parts, variants, versions, effectivities, or intervals. Recover the identity relation instead of relying on a shared name.
Human readability and machine-supported checking	Text and diagrams can reveal meaning to people; formal expressions and automation can expose selected contradictions. Warranted reliance still requires an explicit interpretation, completeness boundary, and world-side correspondence.
Executable model and physical result	Simulation and generated code can shorten feedback; they can also reproduce shared assumptions and omit physical effects—for example, manufacturing, installation, environmental, or operating effects.
Shared model and federated descriptions	One common model can reduce translation for a bounded use; independently maintained descriptions can preserve needed expertise and authority. Choose from the receiving decision and the losses of each arrangement.
Current decision and future reuse	General data structures can enable later use; speculative completeness can delay the present decision and preserve obsolete distinctions.
Publication convenience and epistemic identity	One publication occurrence can make several epistemes available, and one episteme can appear through several publication forms. Carrier consolidation leaves claim content and editions distinct.
AI-assisted production and warranted reliance	AI Systems can produce candidate outputs—for example, text, code, diagrams, mappings, checks, or summaries—quickly. The outputs still need recoverable sources, subjects, error checks, and decision-specific acceptance.
Standards compatibility and present practice	Standards supply useful distinctions and exchange constraints. Treat conformance, official publication, and academic visibility as evidence of declared content; assess practical adoption, effectiveness, and current engineering Methods separately.

SYSE.7:4 - Solution

Maintain the smallest current set of engineering description epistemes that can change the receiving decisions, and make every material cross-description use explicit. Select descriptions from decisions and Work. Existing document inventories, notations, process presentations, and tool repositories are candidate sources rather than the selection rule.

SYSE.7:4.1 - Perform the Move

Name the receiving decision and its decision-changing claims. State the decision, decision subject, intended use, project focus, current option set, and the claims for which a changed value, contradiction, or evidence result could change the choice.
Recover each described subject. For every needed claim, identify the actual System, intended referent, selected structure, configuration, part, environment, Work occurrence, Method, or other holon concerned. Distinguish an individual from its kind, one part structure from another selected structure, and a current configuration from a possible-future candidate.
Select the description uses. Choose the smallest set of epistemes needed, for example, to express, calculate, compare, communicate, realize, observe, or assure those claims. Examples include a use account, functional description, physical-structure description, equation model, state model, interface account, configuration record, trial result, or operating observation. Include each one only for a stated use.
Identify each episteme and expression. Record claim content, EntityOfConcern, effective reference scheme, edition, source, provenance, modeled interval or effectivity, assumptions, omissions, and relying Work. Separately identify any material expression or publication object—for example, a carrier, publication form, rendering, executable expression, database object, or generated summary—when its identity changes use.
State interpretation and model-use conditions. As needed by the decision, name conditions such as units, coordinate frames, scales, tolerances, abstractions, parameter sources, boundary conditions, solvers or inference procedures, and validation limits. State the project’s interpretation separately from language rules and tool capabilities.
Recover cross-description relations. For every material link, state its participants and relation: same subject under different schemes; part or interface correspondence; claim dependency; source derivation; configuration applicability; transformation from one expression to another; test-to-claim assessment; or another direct relation. If the project lacks a governed relation kind or evidence for that claim, record an unsupported correspondence rather than inventing a generic trace edge.
Check collisions at the claim level. Compare claims only after subject, configuration, interval, scheme, scale, and tolerance are aligned or their differences are explicit. Classify the result as agreement for the bounded use, an explainable difference, an unresolved contradiction, a missing interpretation, or a missing world-side check.
Check correspondence to realization and observation. Identify which claims describe candidates or intentions and which concern actual configurations or occurrences. Connect design claims to relevant observations—for example, from realization, integration, trials, commissioning, operation, or affected Systems—through their evidence and configuration relations. Do not let description-to-description consistency substitute for physical adequacy.
Choose publication forms for actual users. Publish only the forms needed by the receiving Work and its users. Reuse or author a viewpoint only when U.View membership and conformance matter. Keep the source episteme, view, publication occurrence, form, carrier, and audience use separate.
Assign maintenance Work. For each material entry, identify the Agent assigned to change its description, decide a contested interpretation, accept a cross-description relation, or stop reliance, together with the needed capability and authority. Specify the observations that call for refresh and the Work that will update the affected account.
Return the bounded result. Make the usable claims, contradictions, unsupported correspondences, gaps, reliance limits, and refresh conditions available to the named engineering decisions and dependent Work.

This numbered list is a learning unfolding governed by A.22.CGUS, not a claim that description Work occurs in one serial lifecycle. Description production, realization, checking, operation, and decision Work can overlap. The displayed order expresses a logical dependency: claims cannot be compared until their content and subjects are recoverable. It does not prescribe the order of performed Work.

SYSE.7:4.2 - Record the Result

Use a compact EngineeringDescriptionEnsembleAccount@Project when several descriptions materially support one decision. It is a project-local episteme; the FPF kinds of its participants remain unchanged.

Field	Required content
receiving decision	Decision, decision subject, intended use, interval, and downstream Work that will use the result.
decision-changing claims	The smallest claim set whose value, contradiction, evidence, or absence can change the decision.
description entries	For each episteme: source and edition, claim content, `EntityOfConcern`, reference scheme, configuration/effectivity, modeled interval, assumptions, omissions, and relying Work.
expression and publication entries	Material carriers, publication occurrences and forms, renderings, executable expressions, database objects, or generated summaries, each kept separate from the source episteme.
model-use conditions	Purpose, scale, units, coordinates, tolerances, boundary conditions, parameter sources, interpretation, calculation or inference Method, and validity limits needed by this use.
relations	Direct same-subject, part, interface, configuration, source, transformation, evidence, or other governed relations; unsupported correspondence hypotheses are marked as such.
collision results	Claim-level agreements, explainable differences, unresolved contradictions, missing interpretations, and missing world-side checks.
realization correspondence	Actual configuration or occurrence, observation/evidence basis, and the decision claim it can confirm, weaken, or reopen.
maintenance assignments	Assigned Agents, their system-role assignments, authority, capability, Work, and acceptance conditions for producing, checking, changing, or retiring description uses.
return and refresh	Receiving Work and the Agents assigned to it, accepted reliance limits, current gaps, triggering observations, and the smallest affected account or decision to reopen.

The account can be published through, for example, linked text, tables, model queries, a repository view, or generated reports. Its identity and sufficiency do not depend on one storage technology.

SYSE.7:4.3 - What Changes in Practice

Engineers stop asking whether documentation or “the model” is complete. They ask whether the current description ensemble can support a named decision without hiding a subject mismatch, configuration mismatch, interpretation gap, contradiction, or unsupported world-side claim.

The Agent performing modeling Work enacts the Method; modeling tools are resources. Ground decision authority and warranted reliance on modeling results through their own relations. Traceability becomes a collection of testable relations rather than a link count. A digital thread is a maintained arrangement for named engineering uses. Use the local label digital twin only when its selected subject, descriptions, automation, observations, and use are stated.

The account includes conditions for reconsideration. A change to, for example, a configuration, source edition, environment, model assumption, trial result, or receiving decision can call for refresh. The assigned Agent then refreshes the affected claims and relations. Unaffected descriptions remain usable under their stated conditions.

SYSE.7:5 - Worked Case: Controller Architecture Description Ensemble

The project is preparing evidence for a controller-architecture decision: whether plant configuration HP-2 should use direct compressor modulation alone or modulation coordinated with thermal storage over the next three heating seasons. The plant, use, configuration, and decision focus are the same across the selected inputs. Outside-use, functional, and bearer descriptions already exist, but the decision-changing claims remain distributed across several descriptions. The engineering team constructs this bounded account:

Entry	Subject and use	Material interpretation or relation
use and operating-scenario episteme	The intended heat-pump plant in occupied-building use; supplies temperature, noise, maintenance, power-price, and grid-response situations.	Scenarios are possible use descriptions, not performed operation or test evidence.
functional-organization episteme	Candidate control organization: demand estimation, compressor modulation, storage dispatch, limit protection, and fault handling.	Treat the listed elements as functions until separate bearer and realization relations assign them to controller modules or software processes.
bearer-and-interface account	Candidate controller hardware, plant sensors, actuator connections, storage valve, communication interfaces, and allocations.	Names candidate Systems, physical interface specifications, and many-to-many function allocations for the decision.
equation-based plant model	Thermal plant and storage behavior under selected boundary conditions.	Modelica equations describe one selected physical abstraction; solver output is not observed plant behavior.
controller state and timing description	Control states, transitions, sampling assumptions, fallback conditions, and actuator commands.	The description concerns intended controller behavior and must correspond to the hardware timing and sensor claims.
component and wiring records	Sensor variants, controller I/O, update rates, error bounds, cable and connector configurations.	Catalogue claims apply only to component variants and conditions.
bench and commissioning results	Observations from controller-in-the-loop Work and later installed-plant trials.	Engineers use `SYSE.10` to qualify which engineering claims those results support and `SYSE.13` to keep tested configurations explicit.

A collision check finds that the plant simulation and controller description assume a two-hertz supply-water temperature update with an error bound of plus or minus 0.1 kelvin. The currently selected procurement variant is specified only for a half-hertz update and plus or minus 0.3 kelvin under the installed cable length and filtering arrangement. Matching the token SupplyTemperatureSensor across three tools had hidden the difference.

The engineers recover the sensor variant and interface configuration instead of merely synchronizing names. They update the model-use assumptions, evaluate another component and estimator option, and perform a controller-in-the-loop trial. The resulting evidence revises the architecture comparison: direct modulation remains acceptable for one building profile, while the storage branch remains unselected until it has either the faster sensing configuration or a different estimator and the corresponding assurance result. This evidence informs the current decision; it does not approve a later storage increment.

The account records the usable description editions, the unresolved estimator claim, the tested configuration, and a reconsideration condition tied to component substitution or a changed grid-response requirement. Controller, procurement, integration, configuration, and assurance Work use different publication forms over recoverable source epistemes while the decision-changing relations remain explicit. The result stays bounded to this decision.

An AI System also produces a proposed cross-description summary and candidate correspondence list. Those outputs are new epistemes produced by performed Work. They are checked against source editions and accepted only where the relation and participants are recoverable. The generated confidence score supplies neither an evidence relation nor authority to alter the architecture decision.

SYSE.7:6 - Bias Annotation

This pattern resists four recurrent source and practice biases.

Artifact bias. Sources such as standards, university curricula, tool vendors, and process descriptions often organize engineering around named documents or model kinds. The pattern preserves useful distinctions but begins from current decisions and Work.
Official-model bias. A heavily published source—for example, a normative language, standard, ontology, or repository—may have limited or ceremonial use in projects. Official publication establishes scope and declared capability; assess practical adoption, beneficial use, shared interpretation, and current SoTA separately.
Software-transfer bias. Software practices such as executable models, generated links, continuous integration, and automated checks can be valuable. Physical concerns—for example, realization, supply, installation, calibration, environmental exposure, or operating evidence—remain distinct and may require slower or destructive checks.
Academic-evidence bias. A bounded study—for example, a prototype consistency checker, digital-twin mapping study, or one case—can sharpen a Method without establishing broad industrial effectiveness. Use the best available expert judgment with a stated epistemic status when comparative field evidence is unavailable; do not demand an unaffordable prevalence study or upgrade publicity to use evidence.

SYSE.7:7 - Conformance Checklist

One receiving engineering decision, its decision subject, and the decision Work are named.
Every selected description has a source episteme and edition, claim content, EntityOfConcern, effective reference scheme, configuration or effectivity where material, modeled interval, and use.
Actual Systems, intended referents, kinds, parts, configurations, and occurrences are not merged by name.
Model purpose, assumptions, omissions, scale, units, tolerances, and interpretation are sufficient for the receiving decision.
A U.View claim cites a viewpoint episteme and obtaining E.17.0 conformance; otherwise view stays ordinary source wording.
Publication occurrence, form, carrier, rendering, and source episteme remain separate where their identities change reliance.
Every material “trace” is resolved to a relation or marked as an unsupported correspondence.
Cross-description comparison aligns or explicitly distinguishes subject, configuration, interval, reference scheme, scale, and tolerance.
Claims about physical realization, benefit, safety, compliance, and acceptance use their own evidence; description consistency supplies only its stated comparison result.
AI-generated, transformed, or summarized descriptions retain source provenance, subjects, check results, and reliance limits.
The maintenance Agent, assignment, capability, authority, triggering observations, and refresh Work are stated for material entries.
The returned account names contradictions, gaps, unsupported relations, accepted reliance limits, and the smallest decision or account to reopen.

SYSE.7:8 - Common Failures and Repairs

Failure	Repair
Start from a compulsory document or view list	Start from the receiving decisions and decision-changing claims; add a description only when its use changes Work or reliance.
Treat one repository as one model	Recover each claim-bearing episteme, source edition, subject, scheme, and use independently of storage co-location.
Treat same names as same subjects	Resolve actual identity, kind, part, configuration, interval, and designation separately.
Count links as traceability	For each material link, name its participants, relation, relying decision, and failure consequence.
Call every publication face a view	Apply `E.17.0` only when `U.View` membership matters; otherwise name the publication form and bounded use plainly.
Let a simulation stand for the plant	State the modeled subject, assumptions, validity boundary, and evidence needed for the physical claim under `SYSE.10`.
Freeze one baseline as lifecycle truth	Keep configuration and effectivity under `SYSE.13`; refresh affected claims and relations when the world or source changes.
Demand one shared ontology	Use a shared scheme only where its benefits exceed lost specialist distinctions; otherwise maintain explicit correspondences and unresolved differences.
Create a digital twin by label	Name the selected subject, description/model set, automation, observations, current use, evidence, and maintenance Work; drop the label if it changes nothing.
Accept generated correspondence by confidence score	Treat it as a candidate episteme; inspect sources, subjects, relation, exceptions, and decision consequence.
Let specialists exchange files without a receiving use	Use `SYSE.9` to state the requested professional contribution, receiving decision, acceptance condition, and result to return.
Make the pattern or account act	Name the Agent, Method, and performed Work; epistemes describe, support, or constrain through use relations.

SYSE.7:9 - Consequences

Benefits. Decisions can use several specialist descriptions with their different boundaries intact. Contradictions become claim-sized and actionable. Model, configuration, and evidence changes reopen bounded uses rather than the whole project. Publication can be tailored to actual readers without changing source claims. Automation can check more relations because the relation kinds and subjects are explicit.

Costs. Engineers must maintain subject identity, editions, interpretation, configuration applicability, and selected correspondences. Some attractive links will remain unsupported. Specialists must expose enough of their assumptions for the receiving decision, and the integration team must understand where formal checks stop.

Risks. The account can itself grow into a master-model bureaucracy. Prevent this by requiring a receiving decision for every maintained entry and by retiring a relation when no current Work relies on it. Conversely, aggressive minimization can omit a slow feedback channel—for example, a physical, affected-System, or specialist channel; the result check therefore asks what decision would become unsound if the omitted claim failed.

SYSE.7:10 - Rationale

FPF already gives general precision for the needed transdisciplinary objects and relations, including epistemes, descriptions, publications, views, reference schemes, representations, mathematical lenses, evidence, currentness, configurations, and Work.

Select a heterogeneous set of descriptions for the engineered-System decisions. Preserve subjects and configurations across functional, physical, behavioral, analytical, realization, and assurance uses. Expose conflicts between claims, connect candidate and intended descriptions to evidence from actual realization and operation, and turn gaps into questions for the engineering Work that can change the System or revise the decision.

The ensemble is decision-bounded because no description is complete for every use. The same plant can require different selected structures and representations for different uses—for example, control design, installation, maintenance, economic choice, safety assurance, or operator training. Choose and relate descriptions by the claims that must be jointly usable now.

SYSE.7:11 - SoTA and Source Use

Select descriptions for the engineering decision while keeping the subject, description, scheme and carrier distinct. Relate simultaneous descriptions through their correspondences, conflicts, gaps and update needs. Select aspects, levels, creator relations and model-federation links for that decision. Use descriptions to support research, realization and integration, and identify who performs the Work and who may authorize it.

Source line	Retained contribution	Limit and guard
ISO/IEC/IEEE 42010:2022 and ISO/IEC/IEEE 15288:2023	Current standard vocabulary separates entity, architecture description, viewpoint, view, model kind, correspondence, and iterative or concurrent process application.	Use the standards for their declared vocabulary and constraints. Ground the project architecture, modeling Method, practical adoption, shared interpretation, and current practice separately; let the receiving engineering problem select the descriptions needed now.
Lehner et al. 2025	A systematic mapping study shows heterogeneous model automation and uses in digital-twin engineering, with domain and subject dependence.	Treat the manufacturing- and transport-heavy literature as evidence of heterogeneous arrangements. Select ontology, Method, and subject kind for the current engineering use.
ISO/IEC 30173:2023, ISO 23247-5:2026, and ISO 23247-6:2026	Current institutional work makes maintenance, continuity, connectivity, and integrated, unified, or federated composition visible as engineering-data arrangement choices.	Use these manufacturing standards to expose arrangement choices. Assess completeness, effectiveness, adoption, and the need for a digital-twin or digital-thread arrangement in the current engineering Work.
Wu et al. 2025	One landing-gear case connects heterogeneous model semantics, conflict handling, traceability, and versioning.	Use it as a worked case for those relations. Physical configuration selection, release, supply, and broader use require their own evidence and Methods.
SysML 2.0, Modelica 3.7, ModelingToolkit 11, and Dyad 3.3.0	Rechecked 2026-08-25: the maintained families serve different uses—for example, architecture, requirements, acausal physical, symbolic-numeric, simulation, calibration, control, or integration uses—and a project may need several. Dyad 3.3 adds compiler-resolved editing and 3D multibody capabilities; each use still needs decision-led selection and explicit cross-description correspondence.	Specifications, changelogs, and provider documentation establish declared capabilities and maintenance. Assess comparative adoption and effectiveness separately; choose the model boundary, evidence, and correspondence from the engineering decision.
Riedmaier et al. 2021 and Schwarzburg et al. 2024	Model use requires decision-specific verification, validation, uncertainty and extrapolation attention; warranted reliance can depend on model history, competence, access, and decision risk.	Treat confidence as one evidence result under stated conditions. Establish physical adequacy, decision correctness, and reliability separately; interpret the small non-probability practitioner sample accordingly.
Becker et al. 2025 with the 2026 METR update, Agarwal et al. 2026, and Pradas Gomez et al. 2025	AI Systems already participate in bounded software and engineering-design Work; task-specific allocation, provenance, review, integration, and observation remain necessary.	Use the sources for bounded contribution claims. Ground further claims—for example, productivity transfer, autonomous performance of larger Work, decision authority, or generated-description correctness—separately.

Refresh a source-dependent claim when a new edition changes a relied-on language capability, composition option, model-use boundary, automation result, or engineering-data relation. Treat publicity, standards announcements, university curricula, and vendor demonstrations as evidence of what is declared or taught. When evidence with a stated epistemic status changes a bounded engineering use, refresh the affected project claim, correspondence, or reliance decision.

SYSE.7:12 - Relations

C.2.1 supplies episteme identity, EntityOfConcern, effective reference scheme, and edition discipline.
C.2.P.DR repairs declarative-representation overread; C.29 applies only when a mathematical-lens use and its explicit correspondence, preserved structure, loss, and stop condition are current.
E.17.0 supplies the dependent U.View membership and viewpoint-conformance relation; E.17 and E.24.PUB keep selected episteme, publication occurrence, form, carrier, reader, and use distinct.
A.6.3.RT governs a representation-scheme transition when the same EntityOfConcern is deliberately redescribed; it does not establish world-side identity or the correctness of the receiving claims.
A.10, B.3, and G.11 govern evidence reliance, assurance, and source-edition currentness. SYSE.10 specializes the return from research, models, and trials to engineering decisions.
E.15, C.27, SYSE.13, SYSE.14, and SYSE.19 govern configuration continuity, temporal claims, change, release, and revalidation when those are the current problems.
A compatible SYSE.1 result can supply the scope and intended-result frame for the same subject and decision. It does not prescribe Work order. If it does not fit, use a qualified direct source or record the missing result. Descriptions such as concept, candidate, provider, affected-System, or specialist descriptions remain governed by their own subject patterns.
SYSE.7 supplies evidence to SYSE.6 only when the account can change the same architecture decision at the same configuration and horizon. The account neither authorizes nor entails that decision. If the account cannot serve the use—for example, because it is unavailable, stale, outside scope, or incompatible—SYSE.6 uses a qualified direct source or records that missing result.
SYSE.7 supplies a MethodDescription or representation input to SYSE.19 only for the named receiving use. Description order or conformance does not establish Method order or effectiveness. If the account cannot serve the use—for example, because it is unavailable, stale, outside scope, or incompatible—SYSE.19 uses a qualified direct source or records that missing result.
When the current problem is requesting and accepting a professional contribution, apply SYSE.9 to that result and receiving decision. When neighboring Work—for example, realization, integration, supporting-System engineering, description federation, or assurance Work—needs a description, its governing pattern uses the source episteme through its own subject, configuration, evidence, and use relations. The Agent performing each neighboring Work applies its governing Method, and that Work produces its own result for the named receiving use.
Engineering profiles—for example, engineering-data, physical, software, electrical, control, manufacturing, medical-device, ship, or building profiles—may specialize description Methods where their subjects, formalisms, evidence, and realization relations change the working move. A profile name alone adds no pattern.