C.30.AD.BA:2.4 - Keep a digital-twin description coupled without merging its objects
The phrase digital twin can cover a model episteme, software system, sensor systems, telemetry epistemes, simulation methods, operational Work, interfaces, representations, and publications. Recover each current object by its direct kind and relation. C.30.AD.BA uses only the exact descriptions and views that contribute to the built asset’s architecture-description use.
When one declared architecture-description use crosses design-side and run-side material, fill the optional by-value record named by designRunSeparationUse:
BuiltAssetDesignRunSeparationUse:
designSideDescriptionRefs: FinSet(U.EpistemeRef)
runSideDescriptionRefs: FinSet(U.EpistemeRef)
designSideWorkOccurrenceRefs?: FinSet(U.EntityRef constrained to U.Work)
runSideWorkOccurrenceRefs?: FinSet(U.EntityRef constrained to U.Work)
telemetryEpistemeRefs?: FinSet(U.EpistemeRef)
sourceToUsePathRefs: FinSet(U.RelationRef)
descriptionFreshnessClaimRefs?: FinSet(U.EpistemeRef)
publicationCurrentnessRelationRefs?: FinSet(U.RelationRef)
designToRealizationCorrespondenceClaimOrRelationRefs?:
FinSet(U.EpistemeRef | U.RelationRef)
directCouplingRelationRefs?: FinSet(U.RelationRef)
actualTransformationRefs?: FinSet(U.EntityRef constrained to U.Transformation)
classificationBasis:
admissibleCrossLifecycleUse:
blockedMerge:
This is a by-value classifier for one built-asset description use, not a new FPF kind, a generic tag, or a relation constructor. designSideDescriptionRefs cite exact epistemes used for intended, required, proposed, or design-state material; runSideDescriptionRefs cite exact as-built, observed, operating, inspection, or maintenance-state epistemes. The classification is local to the declared use, not intrinsic to an episteme. If one publication carries both, identify the exact description or ClaimGraph loci before classifying them.
Every referenced object and relation keeps its subject pattern. C.2.1 governs description identity; A.15.1 governs each exact U.Work; G.11 governs freshness, currentness, and decay; the exact source-use owner governs each source path; the direct correspondence or coupling owner governs an affirmative relation; and A.10 or B.3 governs reliance or assurance. C.28 governs a causal use of telemetry, simulation, maintenance, or a claimed physical or energy change; C.27 continues to govern the temporal adequacy of the change statement. A.3.4 governs an actual physical transformation only when the exact changed referent, boundary, conditions, before/during/after facts, and continuity or reidentification basis are complete. A required or desired effect, live value, simulation result, control-view row, or local design/run classification is not that actual transformation. The local classification states only which already identified references belong on each side of this one cross-lifecycle use. Its nested source and currentness refs must resolve to the same exact refs cited by the enclosing use record, not duplicate or replace them. When an exact side, source path, Work occurrence, currentness boundary, or required direct relation cannot be recovered, state that gap in blockedMerge and narrow or block the cross-lifecycle use.
| Local anti-pattern | Symptom | Repair |
|---|---|---|
| Design/run collapse | A design description, realized asset description, telemetry episteme, operation or maintenance Work, and physical change are treated as one because a platform links or displays them together. | Fill BuiltAssetDesignRunSeparationUse with the exact side-specific descriptions, Work, sources, and currentness refs; cite correspondence, coupling, or transformation only under its subject pattern, or block the merged use. |
| Lifecycle view merge | Original design, as-built model, operation record, maintenance Work, and an alleged transformation are merged because one dashboard presents them as one lifecycle view. | Keep each existing object and relation reference explicit; actual change enters only through A.3.4, and identity, parthood, evidence, assurance, or architecture adequacy is never inferred from co-display. |
The twin’s coupling to the asset establishes neither parthood nor identity between the digital and physical objects. Connection, synchronization, rendering, bundling, and publication also establish neither architecture relation, selected structure, description truth, empirical grounding, view membership, evidence sufficiency, assurance, gate passage, Work, nor project-use relation.
A green twin, dashboard, exchange result, or release screen is therefore a cue, not gate passage. Use A.21 when a named gate must decide a bounded action or when its decision result is being relied on. Establish or recover the GateDecisionResult episteme, its applicable profile application and exact check-application results. Publication and the optional DecisionLog follow A.21:4.10 when publication, audit, or reuse is needed; an ordinary one-time decision can stop at its result and rationale. If no named gate decision is current, keep the display as a cue and handle any evidence, work-entry readiness, assurance, Work, or neighboring claim under A.10, A.15.5, B.3, A.15.1, or its exact direct governor. Even a GateDecisionResult with decisionValue=pass establishes neither release, readiness, permission, authorization, nor performed Work.
Recover the release-looking claim before routing it. An actual release action is one exact A.15.1 U.Work occurrence. Use A.15.5 for work-entry readiness, A.2.8.PER for a non-prohibition, granted permission, permission exercise, non-violation, or permission conflict, and A.2.9 for an instituting or revoking grant act. A further claim that a subject was released needs its named subject predicate and participants. Keep the display as a cue while either is unresolved; return A.6.RCD missing-governor only when the predicate cannot be recovered, and state any missing participant information separately. No current model, source, gate result, dashboard, or the word authorized supplies one of these relations by appearance.
Currentness and smallest reopen. When a decisive input changes, reopen only the built-asset description-use locus and conclusion that depend on it. A changed asset or selected structure reopens the dependent description identity, built-asset trace, or structural-view use; changed view conformance reopens that one view admission; a changed designation scheme, referent, or qualification window reopens only its BuiltAssetReferenceDesignationUse; a changed source, model, publication, or telemetry edition or freshness/fidelity boundary reopens its exact source-to-use or currentness locus; changed design/run classification, cited Work, source/currentness ref, correspondence, coupling, or transformation reopens only the affected BuiltAssetDesignRunSeparationUse and dependent admissible cross-lifecycle use; and a changed project-use relation or direct governor reopens only that exact relation reference and dependent admissible-use conclusion. Update the affected description, designation, design/run, or currentness locus; when the required input cannot be recovered, narrow or block only that use while unrelated views, descriptions, designations, and uses stay closed.