#Built-Asset Architecture Description and Reference Designation

C.30.AD.BA · Cluster C.IV - Composite & Macro-Scale · Stable · Architecture-description subpattern under C.30.AD · Normative for built-asset architecture-description, asset-information, digital-twin, and reference-designation use. · Part C - Kernel Extension Specifications

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Architecture-description subpattern under C.30.AD Status: Stable Normativity: Normative for built-asset architecture-description, asset-information, digital-twin, and reference-designation use.

Builds on. C.30, C.30.AD, C.30.ASV, A.1, A.22, E.17, E.17.0, E.17.1, E.17.2, E.24.PUB, and A.7.

Coordinates with. A.6.F, A.6.M, C.30.TFS-REL, C.30.LCA, C.29, C.16, A.10, B.3, A.20, A.21, A.15, C.11, C.28, C.27, and F.18.

Use this when. Use this pattern when a BIM model, IFC exchange, asset register, dashboard, digital-twin view, handover table, maintenance information set, cost or energy view, or ISO/IEC 81346-style reference designation is used as an architecture description for a built asset.

Not this pattern when. If the current question is the architecture claim itself, use C.30. If the current question is the general architecture-description mechanism, use C.30.AD. If the current question is one structural view, use C.30.ASV. If the current question is selected structure as such, use A.22. If the current claim is evidence, assurance, decision, causal use, work, or gate passage, keep this pattern only for the built-asset description boundary and use the direct governing pattern.

What goes wrong if missed. A BIM model, asset register, dashboard, digital-twin view, or reference designation starts acting as the built asset, architecture, evidence, assurance, gate, work, or decision.

What this buys. Built-asset descriptions remain usable while the asset, architecture claim, views, designations, publications, source relations, and currentness boundaries stay separate.

Built-asset practice uses many useful descriptions: BIM models, IFC exchanges, asset-information models, COBie-like handover tables, reference-designation systems, dashboards, digital-twin views, maintenance records, energy views, cost views, and sensor feeds. These descriptions help engineers operate across design, construction, operation, maintenance, repair, refurbishment, and end-of-life use.

#Relations

#Content

#Problem Frame

Built-asset practice uses many useful descriptions: BIM models, IFC exchanges, asset-information models, COBie-like handover tables, reference-designation systems, dashboards, digital-twin views, maintenance records, energy views, cost views, and sensor feeds. These descriptions help engineers operate across design, construction, operation, maintenance, repair, refurbishment, and end-of-life use.

The danger is semio-bias. The description starts acting like the built asset, the architecture, the evidence, the assurance, the gate record, the work, or the decision because it is detailed, current, standardized, or tool-readable. C.30.AD.BA keeps the built asset, its architecture claim, its architecture description, its views, its reference designations, its publications, and its source relations separate.

#Problem

Built-asset descriptions often carry enough structure to look like the built asset, enough designation discipline to look like identity, enough current data to look like evidence, and enough lifecycle coverage to look like authority. The problem is to admit BIM, IFC, asset-information, reference-designation, digital-twin, telemetry, maintenance, and handover material only after the described holon, architecture claim, selected structures, views, sources, publications, and admissible uses are explicit.

#Forces

#Solution

Use a BuiltAssetArchitectureDescriptionUseCard@Project for the first controlled slice:

BuiltAssetArchitectureDescriptionUseCard@Project:
  architectureClaimRef: ArchitectureOf@ContextRef
  describedHolonRef:
  boundedContextRef:
  builtAssetKindCue:
    facility | plant | bridge | campusBuilding |
    infrastructureAsset | productAsset | otherDeclared
  selectedStructureRefs:
  structureKindRefs:
  architectureStructuralViewRefs:
  referenceDesignationRefs?
  assetInformationRefs?
  digitalTwinViewRefs?
  publicationOrExchangeRefs?
  correspondenceRefs?
  sourceReturnCondition?
  DesignRunTagRefs?
  admissibleUse:
  nonAdmissibleUse:
  firstNeighborPatternApplication?

@Project guard: in this card name, @Project marks a project-side use card for first-pass built-asset architecture-description triage. It is not U.Project, not a bounded context, not project authority, and not a part-whole relation. If one of those claims is current, use the governing project, context, authority, or part-whole pattern named by value.

Expand to BuiltAssetArchitectureDescription@Context only when durable description use is current:

BuiltAssetArchitectureDescription@Context:
  architectureDescriptionRef: ArchitectureDescription@ContextRef
  architectureClaimRef: ArchitectureOf@ContextRef
  describedBuiltAssetRef: U.HolonRef
  boundedContextRef: U.BoundedContextRef
  viewSetRefs:
  referenceDesignationSchemeRefs:
  assetInformationModelRefs:
  digitalTwinDescriptionRefs:
  exchangeOrPublicationRefs:
  sourceEpistemeRefs:
  correspondenceRefs:
  sourceReturnCondition:
  currentnessOrEditionBoundary:
  admissibleUse:
  nonAdmissibleUse:

BuiltAssetArchitectureDescription@Context is a specialization of ArchitectureDescription@Context. It is a Description episteme about ArchitectureOf@Context; it is not the built asset and not the architecture itself.

#View and Relation Discipline

#Reference Designation Boundary

A reference designation helps identify an object across aspect-sensitive descriptions. It does not prove that the functional object, product object, location object, property object, and activity-side object are one FPF entity in all uses. Recover the designation relation first:

BuiltAssetReferenceDesignationUse@Context:
  designationRef:
  designationSchemeRef:
  designatedEntityRef:
  aspectOrViewRef:
  architectureClaimRef:
  selectedStructureRef?:
  correspondenceRefs?:
  sourceReturnCondition?:
  admissibleUse:
  nonAdmissibleUse:

Use the designation to coordinate descriptions. Do not use the designation code as part-whole proof, function proof, evidence sufficiency, assurance, gate passage, or decision authority by appearance.

#Digital Twin and Design-Run Boundary

A digital twin can describe, monitor, simulate, or forecast a built asset. It does not become the built asset by being connected to sensors or operations data.

Use DesignRunTagRefs when a description crosses design-side and run-side material. A design model, built asset, sensor relation, operation record, maintenance work, and physical transformation remain different objects unless a direct governing pattern relates them.

Example boundary: a lathe can transform a workpiece without becoming the workpiece's super-holon. Likewise, a building-management system can change equipment state without becoming part of that equipment merely because the dashboard shows both in one operational view. Use HolonBoundaryCrossingRelation@Context, U.Transformation, U.Work, evidence, source, and architecture-description relations before any MHT or part-whole claim is admitted.

#Archetypal Grounding (Worked Slice)

A hospital facility has a BIM model, IFC exchange, asset register, fire-safety dashboard, energy view, maintenance records, and reference designations for rooms, systems, and equipment.

C.30.AD.BA records the built asset as described holon, the ArchitectureOf@Context claim, the selected structures being described, and the view set. The fire-safety view may involve control structure and evidence; the energy view may involve characteristics and current sensor claims; the asset register may carry source-return conditions; the reference designation coordinates object identity across aspect-sensitive views. None of these descriptions is treated as the hospital, the architecture, a safety proof, a gate record, or a work occurrence by appearance.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

The gain is a practical bridge between FPF architecture-description discipline and current built-asset practice. Engineers can use BIM, IFC, asset-information, reference-designation, and digital-twin material without treating descriptions as the asset or as automatic proof.

The cost is extra relation recovery. The description must say which asset, architecture claim, selected structures, views, designations, sources, and admissible uses are live before it can guide architecture work.

#Rationale

Built-asset engineering already relies on rich description systems. Their practical value comes from disciplined relation use: which asset is described, which architecture claim is current, which structures or views are being used, which source edition or run-side state is current, and which authority claim is actually being made.

The pattern specializes C.30.AD for built assets because BIM, IFC, asset-information, reference-designation, and digital-twin practice make the description/asset boundary especially easy to overread. It keeps standards and tools useful while preserving the FPF distinction between holon, architecture claim, description episteme, publication, source relation, evidence, work, and authority.

#SoTA-Echoing

#Relations

• Specializes: C.30.AD for built-asset architecture-description use.
• Uses architecture and structure owners: C.30, C.30.ASV, A.1, and A.22.
• Uses description and publication owners: E.17, E.17.0, E.17.1, E.17.2, E.24.PUB, and A.7.
• Coordinates built-asset views with: A.6.F, A.6.M, C.30.TFS-REL, C.30.LCA, C.29, C.16, C.27, and F.18.
• Returns authority claims to: A.10, B.3, A.20, A.21, A.15, C.11, and C.28.

#C.30.AD.BA:End

Last Updated: 2026-06-20 — this section last modified in upstream FPF commit fe0df9dc (github.com/ailev/FPF)