The Complete Object: Who Owns Which Truth?

Technical information architecture · Authority and boundaries

The complete object has no single owner.

BIM, engineering, automation, IT and asset management can each be excellent within their domain. The foundation fails when one discipline mistakes a powerful representation for authority over the complete technical object.

12 minute readOwner governanceInteractive authority map

TL;DR

Expertise has a boundary.
Authority needs a mandate.

A complete technical object is a federation of governed truths, not the contents of one model, platform or discipline.

The owner must declare which domain controls each kind of fact.
Contributing information is not the same as approving it.
Coordination gives visibility across boundaries; it does not automatically grant authority across them.
A strong specialist states both what they know and where another authority must decide.
The dangerous role is not the narrow expert. It is the role whose claimed mandate grows faster than its competence, evidence and accountability.

01 · The distinction

Being involved is not the same as being authoritative.

Most technical information failures do not begin with bad intent. They begin with imprecise verbs. A team is asked to “manage the model,” “own the data,” or “coordinate the information.” The phrase sounds clear until a disagreement appears.

Who may define the requirement? Who may change the geometry? Who decides whether a signal is operationally correct? Who accepts the installed asset record? Who can reject a delivery?

These are different powers. Treating them as one role makes accountability disappear precisely where specialist domains meet.

01 · ParticipateContributeCreate or supply information from a recognised competence area. Contribution does not include unilateral approval.

02 · AlignCoordinateExpose clashes, dependencies and missing inputs across teams. Coordination does not make every coordinated fact yours.

03 · DecideGovernSet rules, assign authority, approve exceptions and determine what counts as accepted. Governance requires an explicit mandate.

04 · ChallengeAssureIndependently test whether rules and evidence are sufficient. Assurance should not mark its own homework.

The right to see the whole is not the right to decide the whole.

A multidisciplinary model can be visible to everyone and still require several authoritative owners. The objective is not to reduce collaboration. It is to prevent collaboration from becoming untraceable decision-making.

02 · A useful example

BIM is exceptionally powerful. That is exactly why its boundary matters.

BIM teams can be among the strongest information practitioners in a project. They understand model federation, spatial coordination, object properties, information deliveries and the practical reality of getting many disciplines into a shared environment.

That competence creates enormous value. It does not automatically make BIM the authority for process function, automation semantics, maintainable asset identity, cybersecurity, operating state or owner acceptance.

The risk appears when the most visible model is mistaken for the complete object. A coordinated geometric representation begins to absorb requirements, asset records, control signals and lifecycle decisions simply because the platform can store them.

BIM should lead or coordinate

Accepted geometry, placement and spatial composition
Model federation and geometric clash coordination
Representation requirements and model-delivery checks
Traceable links from model objects to other authorities

BIM should not decide alone

Functional intent and cross-system architecture
Control behaviour, signals and operational semantics
The permanent asset record and maintenance lifecycle
Security risk, owner acceptance or enterprise identity

This is not an argument against BIM.It is an argument for giving BIM a strong, explicit mandate instead of an unlimited, ambiguous one. The mature BIM professional knows when a question has crossed from representation into another domain’s authority.

Same principle · four boundaries

Lead your domain. Hand off the next decision.

A clear mandate names both the work a domain should lead and the truth it must not redefine.

IT

Lead shared digital servicesAPIs · identity and access · integration platforms

Hand off technical meaningDesigners, engineers and domain owners define what the data means.

OT

Lead runtime controlPLC/DCS/SCADA · signals · alarms · operating state

Hand off contractual intentThe owner and engineering define what the system was required and designed to do.

EAM

Lead the maintained asset recordInstalled assets · maintenance plans · work and replacement history

Hand off design representationEngineering and BIM govern technical intent and accepted geometry.

ENG

Lead technical definitionRequirements · functions · ratings · interfaces

Hand off current operating truthOT and operations govern what is happening now.

03 · Interactive model

Build the complete-object house.

Select a role or information brick. The detail panel shows what that authority controls, where its truth lives, who contributes and where its mandate stops.

Build the information scope Complete enough for what? Completeness is defined by a declared purpose, lifecycle state and decision. Start with the core, then add only the context that matters.

Core architecture Seven roles, but not seven identical kinds of authority Fact, normative, representation, lifecycle, operational and protection authorities work alongside an enabling digital capability.

Object facts and states Technical intent, representation, installed lifecycle and runtime truth

Cross-cutting rules and services Normative governance, protection and enabling digital services

Complete for purpose Decision · lifecycle state · evidence

Cross-cutting identity, semantics, federation and protection

One identity can participate in functional, physical, spatial, product and maintenance structures. No single hierarchy is the object.

Complete enough for what? Core view

Completeness is never absolute. It means sufficient authoritative information for a declared purpose, lifecycle state and decision.

Declared scopePurpose, lifecycle state and decision determine which facts and evidence are required.

Authority typesDifferent roles govern facts, rules, representations, records, operations, protection or enabling services.

Federated truthThe complete view links authoritative sources. It is not one master model or database.

Multiple structuresThe same object can have several valid compositions and topologies for different purposes.

Try itSelect a role or brick, then progressively add business context and specialist splits.

Core colours show primary authority. Scope-dependent blocks use neutral markers because their inclusion varies by context.

04 · Division of responsibility

Give every authority a job and a stop line.

The exact organisation varies, but the control logic should not. For every important fact, name one primary authority, the contributors it needs and the decisions it must not make alone.

Domain	Should control	Should contribute	Should not own alone
Owner governance	Identity rules, requirements, acceptance, provenance	Every lifecycle domain	Detailed discipline design or platform operation
Systems engineering	Function, interfaces, technical intent, system boundaries	Operations, BIM, OT, IT, suppliers	Installed history or current operational state
BIM / spatial	Geometry, placement, spatial representation, model coordination	Engineering, suppliers, survey, asset information	Complete-object identity, control semantics or maintenance truth
Asset management	Installed asset master, maintenance and replacement history	Commissioning, suppliers, operations	Design intent, geometry or high-frequency observations
OT / automation	Executable control configuration, signals, alarms, runtime state	Engineering, operations, security, OEMs	Contractual requirements or long-term enterprise semantics
IT / integration	Federation, access, platform availability, validation services	Every authoritative domain	The domain meaning of the information being transported
Security	Risk decisions, protection requirements, continuity objectives	Owner, IT, OT, engineering, operations	Engineering function or operational process ownership

A tool is never an authority by itself. Revit, an IFC repository, a CDE, Maximo, an OPC UA server, a data platform and a digital twin can all hold important records. Authority comes from the owner’s operating model: mandate, competence, source, approval and consequences.

05 · The danger

Mandate inflation often looks like helpfulness.

Overreach rarely announces itself as overreach. It arrives as efficiency: “We already have the model,” “the platform can store it,” or “someone needs to decide.” The short-term gap is closed. A weak foundation is embedded.

01

The tool becomes the truth.The most visible platform is called the master without defining which facts it is actually authoritative for.

02

Coordination becomes approval.The team that collects inputs begins changing or accepting domain facts it was only asked to coordinate.

03

Unknowns disappear from the model.Questions outside the team’s competence are simplified until they fit the available schema or workflow.

04

Temporary project power becomes permanent truth.A delivery organisation defines lifecycle structures without the future operational authority accepting them.

05

Confidence replaces provenance.Nobody can show who approved the assertion, from which evidence, for what purpose or during which effective period.

The most dangerous specialist is not the one who knows too little. It is the one whose authority expands faster than their awareness of what they do not know.

This standard must also apply to the owner, the architect and the systems engineer. Cross-disciplinary responsibility does not mean pretending to possess every discipline’s depth. It means recognising the right authority, forcing boundary decisions into the open and refusing unsupported certainty.

06 · The owner response

Govern the handoffs, not just the boxes.

A role chart is not enough. The owner needs a decision chain for every critical information class, especially where several domains contribute to the same object.

01 · DeclarePurposeWhich decision, lifecycle state and use case must the information support?

02 · AssignAuthorityWho controls the fact, who contributes and who may approve an exception?

03 · ContractEvidenceWhich source, schema, acceptance criteria and provenance must be delivered?

04 · AssureBoundaryWho independently checks completeness and resolves conflicting authorities?

For critical objects, an authority register should state at minimum: information class, primary authority, contributors, authoritative source, validation rule, approval role, effective lifecycle stage and escalation path.

The owner-side systems roleSomeone must hold the whole without pretending to be every brick. That role defines boundaries, exposes gaps, resolves conflicts and verifies that the assembled house is complete enough for its declared purpose.

The house is not strongest when one discipline owns every brick. It is strongest when each brick is controlled by the right authority and every interface has a named decision owner.

The core principle

Competence builds the bricks.
Governance carries the load.

A complete technical object is not one perfect model. It is a governed assembly of requirements, technical intent, representation, installed records, operational truth, protection and evidence.

Know your domain. Declare your boundary. Link the whole.

2026-08-07

Brick: The Semantic Interface

Brick · Part 3 of 3 · The production contract

The Semantic Interface.

A graph becomes infrastructure when applications can discover dependable context, locate external data and rely on controlled validation, versions and change. The interface is not one endpoint. It is a governed contract.

11 minute readSPARQL and SHACLData governance

TL;DR

Query the meaning.
Retrieve the value from its source.

Brick can provide the discovery and context layer of an integration without becoming the transport, historian or control API.

SPARQL discovers entities, relationships and external representations.
External references can locate BACnet or time-series representations, but Brick prescribes no standard data API.
Brick publishes SHACL shapes; tooling can use them alongside owner-defined constraints to validate a model.
Inference can add superclasses, inverse relationships and tags, but is not strictly required for every deployment.
Production use needs explicit versions, provenance, extension policy, acceptance tests and a named owner.

01 · The boundary

A semantic interface is a contract, not a new monolith.

In production, the Brick graph has a specific job: expose shared meaning and navigable context. It can tell an application that SAT-3 is a supply-air temperature sensor belonging to AHU-3, and provide a reference that helps locate the corresponding representation elsewhere.

The graph does not need to ingest every time-series value or become the command path. The building automation system, gateway, historian or data platform can remain authoritative for those payloads.

Semantic contractCanonical entity identifiersBrick classes and relationshipsQueryable graph patternsExternal representations

External runtimeBACnet object accessTime-series readsCommands and workflowsVendor or owner APIs

Brick’s official interfaces guidance describes ways to work with graph data, but Brick does not prescribe a standard API for retrieving every external payload. Calling it an interface is useful only when that boundary remains explicit.

The graph answers “what should I ask for?” The source system answers “what is its value now?”

02 · Discovery

Let SPARQL find the sources and their context.

SPARQL queries graph patterns rather than local tag syntax. An application can ask for air-handling units, their supply-air temperature sensors and any external representations attached to those points.

Illustrative query intentFind instances of brick:Air_Handling_Unit, traverse brick:hasPoint to supply-air temperature sensors, then return the reference nodes or properties that identify external representations.

The query result should return identities and metadata, not silently pretend to return the live temperature. A BACnet reference can identify a device, object type and object instance. A time-series reference can identify a database, stream or collection according to the external representation being used.

SPARQL discovers	External system provides
Which AHUs match the requested class	Current equipment state
Which points belong to each AHU	Current and historical values
How points and equipment are related	Sampling, quality and retention behaviour
Which external representations are declared	Authentication and data-access semantics

The application still needs a connector that understands the referenced platform. Brick standardises useful meaning in the graph; it does not erase the operational differences between BACnet, a historian and a cloud time-series service.

03 · Runtime

Separate discovery from retrieval.

A robust query-to-data flow has visible hand-offs. Each step can fail independently and should produce diagnostics that identify whether the problem is semantic, referential, connective or operational.

Semantic interface pipelineContext leads to data without absorbing the data source

AskApplication submits a competency-backed SPARQL pattern.AHU + SAT sensor

DiscoverGraph returns entities, classes and relationships.AHU-3 → SAT-3

ResolveReference identifies a BACnet or time-series representation.ref:hasExternalReference

RetrievePlatform-specific connector obtains the payload.value + timestamp + quality

UseApplication combines the payload with graph context.analysis / display / rule

This separation protects ownership boundaries. Replacing a historian may require updating references and connectors without rewriting the semantic question. Refining the graph may improve discovery without moving the time-series store.

Runtime design must also define missing-reference behaviour, stale identifiers, access denial, timeout, quality flags and unit handling. Semantics reduce interpretation work; they do not remove operational error handling.

04 · Validation

Use SHACL as a gate, not a slogan.

Brick publishes SHACL shapes, and SHACL-capable tooling can validate graph data against them. A deployment can also add owner-defined shapes for project requirements: required points, allowed extensions, identifier patterns or relationships needed by an application.

Validation does not prove that a relationship is true in the physical building. It tests the supplied graph against declared constraints. An AHU can pass a structural shape and still be linked to the wrong sensor if the source evidence or mapping was wrong.

Contract gatesInspect four dimensions before release

Does the graph meet its declared constraints?

Run Brick-published and owner-approved SHACL shapes.

Required classes are presentRequired relationships are presentConstraint violations are reviewed

Treat the validation profile as a versioned deliverable. Record which shapes ran, which severity levels block release, how exceptions are approved and which graph version produced the report.

05 · Reasoning and versioning

Make implicit behaviour an explicit deployment choice.

Brick inference can add useful statements, including superclass types, inverse relationships and tags. A point typed as a specific supply-air temperature sensor can also be recognised through broader classes; a declared feeds edge can yield its inverse; class definitions can contribute tags.

Inference is not strictly required to use Brick. A deployment may query explicit statements only, perform reasoning at load time, materialise an inferred graph or reason during query execution. The chosen behaviour changes query results and must be part of the contract.

Decision	Production question
Inference profile	Which rules run, and when?
Materialisation	Are inferred triples stored or calculated?
Query assumptions	May applications rely on superclasses or inverse edges being present?
Refresh	When are inferences recomputed after a source change?

The ontology version must also be explicit. Import the intended Brick release through an approved, reproducible mechanism and record the ontology IRI/version information used to build and validate the graph. Avoid silently following an unpinned “latest” dependency in production.

If reasoning changes the answer, reasoning is part of the interface version.

06 · Change control

Extend locally without forking the shared language.

Projects often need concepts that are not represented at the desired specificity in Brick. A local namespace can define additional classes or properties and relate them to Brick where semantically justified. The extension should remain visibly local, documented and testable.

Do not mint a new predicate merely because the team cannot find the official one, and do not redefine an official Brick term to mean something project-specific. Search the current ontology and documentation first. Where a local term is necessary, state its definition, owner, status, expected domain/range and migration plan.

VersionPin Brick, extension and validation-profile versions in the release record.

ProvenanceRecord source, transformation, approver and effective time for governed changes.

CompatibilityTest existing queries and consumers before promoting a changed graph.

Provenance can be managed in a graph, release manifest, data catalogue or controlled repository. The mechanism matters less than the ability to answer: who asserted this, from which evidence, through which transformation, under which approved version?

External references deserve the same discipline. A changed BACnet object instance or time-series key is an interface change even if the semantic entity remains AHU-3.

07 · Operational ownership

Accept the interface with tests and a named owner.

A syntactically valid RDF file is not an accepted semantic interface. Acceptance should exercise the behaviours that consumers depend on, using representative data and expected results.

Minimum acceptance pack

Parse and load the graph with the approved ontology and imports.
Run the agreed Brick and owner SHACL validation profiles.
Execute competency-question SPARQL tests with expected result sets.
Resolve a representative set of BACnet and time-series references.
Retrieve sample values and preserve timestamp, unit and quality context.
Confirm inference-dependent tests under the approved reasoning profile.
Run regression tests for consumers before a version is promoted.

Ownership closes the contract. A named owner approves ontology upgrades, local extensions, exceptions, reference changes and release timing. Producers know what they must supply. Consumers know which version and behaviour they can rely on. Operations knows how a broken reference or stale graph is corrected.

This is the point where data governance becomes concrete: not a policy document beside the graph, but decisions embedded in releases, tests and accountabilities.

A semantic model becomes an interface when someone owns the promises it makes.

The series conclusion

Meaning becomes infrastructure when it is discoverable, testable, versioned and owned.

Brick supplies vocabulary and graph semantics. Production architecture supplies connectors, controls and accountability. Keep those responsibilities connected without confusing them.

The semantic interface is a governed promise between producers and consumers.

Series complete · Return to the foundation

Revisit the move from tags to meaning.

Read part 1 ↺

Sources and further reading

2026-08-06

Brick: One Object, a Graph of Context

Brick · Part 2 of 3 · The useful neighbourhood

One Object, a Graph of Context.

AHU-3 becomes useful to software only when the graph states what it is, what it contains, where it is, what it serves and where its data can be found. The craft is not adding every possible edge. It is declaring the right neighbourhood.

10 minute readKnowledge graphsBuilding context

TL;DR

One object is a node.
Its usefulness lives in the edges.

A useful Brick subgraph answers real questions without pretending to be a complete simulation of the building.

Entities are instances of classes, not interchangeable with the classes themselves.
hasPart, feeds, hasLocation and hasPoint express different kinds of context.
Brick 1.5 introduces hosts and controls for additional deployment and control context.
Relationship direction matters, although inverse relationships may be inferred or stated.
Model boundaries should follow competency questions and distinguish facts, inferences and external references.

01 · The starting point

Separate the thing from the kind of thing.

AHU-3 is an entity in a particular building. brick:Air_Handling_Unit is a class in the Brick ontology. The first is an instance; the second supplies shared meaning.

That distinction is easy to say and easy to blur. A class defines a reusable category. An instance identifies the occurrence that applications, drawings and source systems refer to. More specific classes can add precision without changing the identity of the occurrence.

Brick can describe physical entities such as fans and rooms, logical entities such as HVAC zones, and virtual entities such as points. These categories can meet around the same AHU without being collapsed into one object.

Entity	Role	Illustrative class
`AHU-3`	Physical equipment occurrence	`brick:Air_Handling_Unit`
`Supply-Fan-3`	Physical component	`brick:Supply_Fan`
`Zone-East-2`	Logical served region	`brick:HVAC_Zone`
`SAT-3`	Virtual telemetry point	`brick:Supply_Air_Temperature_Sensor`

Classification tells us what AHU-3 is. Relationships tell us why it matters.

02 · Composition

Open the casing with `hasPart`.

Composition describes an entity as containing or being composed of other entities. For AHU-3, brick:hasPart can connect the unit to its supply fan, heating coil, cooling coil and filter. The inverse relation is brick:isPartOf.

This is not merely a visual nesting device. A maintenance application can ask which components belong to an AHU; an analysis can discover the fan inside the unit; a validation rule can test whether an agreed component is represented.

AHU-3brick:hasPartSupply-Fan-3

AHU-3brick:hasPartHeating-Coil-3

Cooling-Coil-3brick:isPartOfAHU-3

The relation should reflect the intended Brick composition, not be imported mechanically from a bill of materials or an IEC 81346 aspect structure. Those sources can inform the assertion, but their relation semantics are not automatically identical.

Modelling disciplineUse the most specific relationship that answers the intended question. “Related to AHU-3” is not a model. Composition, topology, location and telemetry each say something different.

03 · Topology and place

State what it feeds, and where it is.

brick:feeds represents a directional flow of some medium between entities. It can connect AHU-3 to downstream equipment or a served zone when that assertion is appropriate to the model. It is a semantic topology relation, not a licence to model arbitrary physical air-flow physics, pressure fields or every duct segment.

brick:hasLocation answers a different question: where the entity is located. AHU-3 may have a mechanical room as its location while feeding equipment and zones elsewhere. Location must not be substituted for service topology.

Context graph around AHU-3Static accessible view of distinct relationship families

LocationMechanical-Room-2brick:Mechanical_Room

AHU-3 hasLocation →

Core instanceAHU-3brick:Air_Handling_Unit

→ feeds VAV-3A

PartSupply-Fan-3brick:Supply_Fan

PartHeating-Coil-3brick:Heating_Coil

PointSAT-3brick:Supply_Air_Temperature_Sensor

DownstreamVAV-3A → Zone-East-2Equipment feeds logical zone

The figure is deliberately a subgraph. It says enough to follow composition, place, telemetry and a selected service path. It does not claim that these nodes are a complete engineering model of AHU-3.

04 · Telemetry and operation

Connect the machine to its points and roles.

brick:hasPoint links an entity to a point that measures, commands, sets or otherwise represents a property associated with it. The inverse brick:isPointOf supports the opposite traversal. AHU-3 may have supply-air temperature, fan command and filter alarm points, each classified according to its role.

Brick 1.5 also introduces brick:hosts and brick:controls. Hosting can express that one entity provides the execution or deployment environment for another. Control can state a control relationship between entities. They add useful vocabulary, but should be asserted only where the project can establish the relationship.

Relationship lensesOne AHU, four different questions

What is inside AHU-3?

Use composition to discover declared components.

AHU-3 brick:hasPart Supply-Fan-3

No single lens replaces the others. A fan can be part of an AHU, a point can be associated with the fan, the AHU can be located in a room, and the assembled equipment can participate in a downstream topology.

05 · Traversal

Read every relationship in its declared direction.

Brick relationships are directed. AHU-3 brick:feeds VAV-3A is not the same assertion as the reverse. Brick defines inverse relationships for many common predicates, such as hasPart/isPartOf, hasPoint/isPointOf and feeds/isFedBy. Inference tooling may materialise inverse statements, but a query should not casually reverse an edge.

Systems, loops and other collections provide another way to organise context. Brick’s collection modelling lets entities participate in a named grouping without claiming that the collection is a physical container. A hot-water system, an air loop or an owner-defined analytical collection can become a useful query anchor when modelled with the applicable Brick collection vocabulary.

Question	Traversal	Meaning
What does AHU-3 contain?	`hasPart`	Declared composition
What is downstream?	`feeds`	Declared directional topology
Where is it installed?	`hasLocation`	Declared spatial context
Which points belong to it?	`hasPoint`	Declared point association
Which system groups it?	Collection membership	Declared organisational context

An edge label without direction is only half a statement.

06 · Scope

Let competency questions draw the boundary.

A model expands indefinitely if “complete” is the only requirement. Competency questions provide a sharper contract: concrete questions that the graph must answer for an intended use.

Which supply-air temperature points belong to AHU-3?
Which terminal units are downstream of AHU-3?
Which zones are reached through those units?
Which physical components are part of the AHU?
Where is the AHU located?
Which external identifier locates each point’s data?

These questions define an initial boundary around AHU-3. Add the entities and relationships required to answer them, then test the queries against expected results. A later use case can extend the graph without pretending the first delivery represented every cable, duct, control sequence and operational state.

Boundary acceptance questions

Is every included node needed by a stated use case or governance rule?
Can each relationship be traced to an authoritative source or approved derivation?
Does the graph distinguish building identity from platform identifiers?
Are exclusions and known gaps documented?
Do sample queries return the expected entities and no obvious false positives?

07 · Epistemic control

Say what was observed, inferred or referenced.

A graph statement may look equally certain in RDF while having a very different origin. Owner governance should preserve that distinction outside or alongside the core Brick assertions.

Observed factVerified from commissioning records, inspection or an authoritative source system. Example: AHU-3 is located in Mechanical Room 2.

Derived statementCalculated, mapped or inferred from approved rules. Example: an inverse isFedBy edge materialised from feeds.

External referenceA pointer to another representation or payload. Example: a BACnet object or time-series identifier associated with SAT-3.

External representations do not turn the Brick graph into the source of live values. They help an application locate a representation in another system. Stable graph identity, source-system identity, provenance and effective dates should remain explicit enough for change control.

The result is not the largest possible graph. It is a bounded, testable and explainable subgraph: one in which AHU-3 can be discovered as equipment, traversed through its parts and topology, located in space, connected to points and related to external data without confusing those roles.

A useful graph does not say everything. It says what matters, with accountable edges.

The modelling lesson

Context is not decoration around the object. It is the interface through which the object becomes usable.

Start with the questions. Declare distinct relationship families. Preserve direction and evidence. Stop when the graph answers its contract.

AHU-3 is one node. Its governed neighbourhood is the asset.

Next article · Brick 03

Turn the graph into a semantic interface.

Read part 3 →

Sources and further reading

2026-08-06

Brick: From Tags to Meaning

Brick · Part 1 of 3 · The central idea

From tags to meaning.

Systems can exchange data perfectly and still misunderstand each other. Brick starts where protocols stop: with a shared, machine-readable description of what the data belongs to and how the surrounding objects are related.

8 minute readSemantic modellingBuilding systems

TL;DR

Interfaces move data.
Brick moves understanding.

Brick turns isolated building-system labels into entities with declared types, relationships and context.

Brick provides a shared vocabulary for equipment, points, systems and spaces.
It represents knowledge as a directed, labelled graph using RDF.
Relationships such as hasPoint, feeds and hasLocation make the model queryable.
Brick can help applications find data, but it is not the protocol or API that carries the data.
Brick complements IEC 81346. It does not replace governed aspect structures or reference designations.

01 · The recurring problem

Data arrived. Meaning did not.

A building management system exposes thousands of points. A gateway publishes values. A historian stores them. An API returns them on request.

Technically, the integration works.

Then the questions begin:

Which sensor belongs to the supply-air path?
Which equipment serves this room?
Is this value a measurement, command, setpoint or alarm?
Which upstream system affects this downstream zone?
Where can software find the live value behind this logical point?

The answers often live in point names, drawings, vendor manuals, spreadsheets and the memory of the person who commissioned the system. The data is available, but its context is not.

Data without context is a well-delivered mystery.

This is the gap Brick addresses. It does not focus on moving values between endpoints. It focuses on making the surrounding meaning explicit enough for people and software to use consistently.

02 · The basics

An ontology is a vocabulary with relationships.

Brick is an open ontology and metadata schema for describing physical, logical and virtual entities in buildings, together with the relationships between them.

In plain language, Brick gives us four building blocks:

The Brick modelFour ideas are enough to understand the foundation

EntityThe thingAHU 3, room 410 or a temperature point

ClassWhat kindAir-handling unit, room or supply-air temperature sensor

RelationshipHow relatedHas point, feeds, has part or has location

GraphThe contextEntities connected through directed, labelled relationships

Entities are the things

An entity can represent something physical, such as a pump or room; something virtual, such as a sensor point; or something logical, such as an HVAC zone.

Classes declare what kind of thing

A class is a named category with a definition. An entity can be declared as an instance of brick:Pump, brick:Air_Handling_Unit or a more specific sensor class.

Relationships create the neighbourhood

Relationships make context explicit. An AHU can brick:hasPoint a temperature sensor, brick:feeds a terminal unit and brick:hasLocation a mechanical room.

The graph makes it queryable

Brick represents these statements as a directed, labelled graph using RDF. Entities become nodes. Relationships become edges. Software can ask for a pattern of meaning instead of decoding a local naming pattern.

An ontology is not a bag of better tags. It is a governed way to state what things are and how they relate.

03 · The shift

Stop decoding labels. Start asking the graph.

A conventional integration often begins with a string such as B4_AHU03_SAT. A knowledgeable person may read building 4, air-handling unit 3, supply-air temperature. Software only sees characters until someone writes the decoding rules.

The same point, two information modelsSwitch between compressed local knowledge and declared shared knowledge

Local labelB4_AHU03_SAT

Meaning depends on naming rules, documents or prior knowledge.

In a Brick model, the useful statements are separate and explicit:

AHU-3is abrick:Air_Handling_Unit

SAT-3is abrick:Supply_Air_Temperature_Sensor

AHU-3brick:hasPointSAT-3

AHU-3brick:feedsVAV-4

VAV-4brick:feedsZone-4

Now an application can query for supply-air temperature sensors belonging to air-handling units, or follow the air path toward the zones they affect. The names may differ between buildings. The declared pattern can remain the same.

Question	Label-based approach	Semantic approach
Find supply-air temperature sensors	Search several tag patterns	Query the sensor class
Find points belonging to an AHU	Parse prefixes and folders	Follow `hasPoint`
Find downstream equipment	Inspect drawings or sequences	Traverse `feeds`
Locate the live value	Read integration configuration	Follow an external reference
Check completeness	Review point lists manually	Validate declared constraints

A tag is compressed local knowledge. A graph is declared shared knowledge.

04 · The human layer

Brick makes more sense. It is still not the popular name.

IEC 81346 designations are precise, but precision does not make them good everyday names. =H1.PA1.GPB1 can be an excellent governed reference and a poor heading on an operator screen.

Brick vocabulary feels more natural because classes such as brick:Pump, brick:Room and brick:Temperature_Sensor use recognisable concepts. That helps both people exploring the model and software interpreting it.

But the class is still not what people call the individual machine. A clean model keeps three roles distinct:

Role	Example	Purpose
Preferred name	Process-water pump 1	Screens, search, speech and reports
Semantic class	`brick:Pump`	Shared meaning for people and software
Governed designation	`=H1.PA1.GPB1`	Navigation through an IEC 81346 structure

The preferred name can be multilingual and can change without redefining the entity. The semantic class remains a classification, not a nickname. The designation remains a governed route, not a prose description.

Let people read the name. Let software understand the class. Let the RDS preserve the route.

05 · The owner outcome

Stop re-teaching the building to every application.

Without a common semantic model, every dashboard, analytics package and optimisation application begins with another mapping exercise. The application may be reusable. Its understanding of the building is not.

Brick aims to make that understanding more portable. When different sites describe equivalent concepts through the same classes and relationships, software can discover what it needs instead of requiring every installation to be hard-coded in advance.

Application portabilityThe semantic model becomes a reusable configuration surface

Without shared semanticsApplication A + mapping for building 1Application A + mapping for building 2Application A + mapping for building 3

With governed semanticsOne application patternQueries each building through the same declared concepts

Lower integration effortLess repeated interpretation of vendor-specific labels.
Cross-vendor discoveryApplications can find related entities across several building subsystems.
Reusable analyticsRules can target semantic patterns instead of one site’s tag syntax.
Traceable data accessPoints can refer to BACnet objects, time-series identifiers or other external representations.
Machine validationConstraints can test whether required classes, properties and relationships are present.
ReasoningFormal axioms can make implied classes and inverse relationships explicit.

The goal is not to make the graph clever. It is to make applications less dependent on clairvoyance.

06 · The companions

IEC 81346 gives the route. Brick describes the neighbourhood.

Brick does not complete IEC 81346 as if something were missing from the standard. It adds a semantic capability that IEC 81346 does not attempt to provide.

IEC 81346	Brick
Structures systems through governed aspects	Describes entities through classes and relationships
Provides reference designations for object occurrences	Provides machine-readable semantic context
Supports lifecycle navigation and owner-controlled technical structure	Supports discovery, queries and application configuration
Works across technical domains	Centres on buildings and their subsystems
Answers: which occurrence are we referring to?	Answers: what kind of entity is this, and how is it related?

The models should remain connected, but not collapsed. A Brick hasPart statement is not automatically equivalent to an IEC 81346 constituent relation in a selected aspect. Similar words do not guarantee identical scope.

Where ISA-95 fitsISA-95 remains useful for enterprise and manufacturing-operational context. Site, Area, Work Center and Work Unit answer questions about production belonging. Brick answers different questions about building entities, points and relationships.

A robust owner architecture can connect the IEC 81346 view, the Brick view, ISA-95 operational roles and platform references through stable canonical identities.

Identity tells us which object. Semantics tells us what it means here. A durable interface needs both.

07 · The maturity boundary

A semantic layer is not the entire stack.

Brick can serve as a semantic interfacing layer when the term is used carefully. It can provide shared meaning through which applications find the same concepts. It does not itself move the values or replace every model around it.

Brick isA vocabulary and relationship modelA queryable building graphA source of semantic contextA way to reference external data

Brick is notBACnet, OPC UA or MQTTA time-series databaseA work-order systemA universal manufacturing ontology

Brick documentation deliberately does not prescribe one standard API. Instead, the model can contain references that allow applications to locate live or historical data through external systems. The graph describes context. Other systems remain authoritative for their payloads.

The final warning is organisational. RDF syntax does not create governance. A Brick model can be technically valid and still contain the wrong entities, weak relationships, stale references or uncontrolled local extensions.

A mature owner can answer:

Which entities are canonical, and which are representations?
Who is allowed to classify or relate them?
Which Brick version and extensions are approved?
How is the model validated before use?
How do changes retain provenance and effective dates?
What happens when the semantic model and a source system disagree?

Good semantics do not emerge from syntax alone. They are governed into existence.

Give Brick the job it is good at. Make its connections to identity, operations and live data explicit. Then the semantic layer becomes infrastructure instead of another abandoned model.

The central idea

A label helps us recognise something. A graph helps software understand it.

Brick changes the question from “what does this tag probably mean?” to “which entities match this declared class and relationship pattern?”

That is the move from tags to meaning.

Next article · Brick 02

One object. A graph of context.

Read part 2 →

Sources and further reading

2026-08-06

IEC 81346, ISA-95 and Brick: Give Every Model the Right Job

Information architecture · From reference to meaning

One machine.
Different questions.

IEC 81346, ISA-95 and Brick are often treated as competing ways to describe the same thing. They become more useful when each is given the job it was designed to do.

10 minute readStandardsInformation architecture

TL;DR

Reference.
Belonging.
Meaning.
Execution.

One technical object can be described correctly in several ways because people and systems need different truths about it.

IEC 81346 provides governed technical structures and reference designations.
ISA-95 provides manufacturing-operational context, equipment roles and physical-asset assignments.
Brick provides machine-readable building-domain classes and semantic relationships.
A CMMS/EAM manages maintenance work, condition, cost and asset lifecycle.
Preferred names make objects recognisable. Canonical identity keeps every representation connected.

01 · The recurring mistake

One tag is asked to carry the whole facility.

A process-water pump has a supplier tag. Electrical design gives it another reference. Automation creates a PLC name. Operations calls it by the service it provides. Maintenance assigns an asset number. A building model stores its own object identifier.

Every identifier may be useful locally. The trouble begins when the organisation tries to make one of them authoritative for every purpose.

The chosen tag grows until it contains site, area, line, function, equipment type, sequence number and perhaps a vendor abbreviation. It looks informative, but its meaning is brittle.

Move the equipment and the location becomes wrong. Replace the product and the serialised identity changes. Reorganise the production line and the operational path changes. Translate the interface and the preferred name changes.

The object did not necessarily become a different object each time. One of its representations changed.

One tag can be convenient. It cannot be complete.

The answer is not a longer tag. It is a clear division of responsibility between identity, names, structures, classifications, relationships and lifecycle systems.

02 · One object

One pump. Several valid answers.

Consider a pump that circulates process water in a bakery. The answer changes with the question.

Question switchSelect what you need to know about the pump

Preferred nameProcess-water pump 1

Recognisable language for operators and other people.

Need	Illustrative representation	What can change it?
Human recognition	Process-water pump 1	Language or operating convention
Operational belonging	Enterprise / Site / Area / Work Center / Work Unit	Reorganisation or reassignment
Function aspect	`=H1.PA1.GPB1`	Change to the function-oriented structure
Product aspect	`-GPB1`	Change to the product-oriented structure
Semantic class	`brick:Pump`	Vocabulary or modelling decision
CMMS functional position	`PWP-01`	Maintenance-system convention
Installed asset	`A-18472`	Physical replacement
Canonical identity	`urn:owner:object:7421`	The intended entity ceases or is redefined

The strings are schematic. The important point is that every value has a declared scope and an authority.

A path explains belonging. A graph explains relationships. A designation provides a governed route. None of them is the object itself.

03 · The division of responsibility

Give every model the right job.

No standard has failed because it cannot do everything. Problems begin when we ask one standard to do another standard’s job.

Division of responsibilityFour capabilities connected by governed identity

IEC 81346ReferenceHow is the object structured and referenced?

ISA-95BelongingWhere does the resource belong in production?

Canonical identityWhich intended entity do these records concern?

BrickMeaningWhat is the entity and how is it related?

CMMS / EAMExecutionWhat work, condition and lifecycle history belong to it?

IEC 81346: technical structure and reference

IEC 81346 begins beneath the name. It asks which objects need to be considered, how they occur in selected aspect-oriented structures and how those occurrences can be referenced unambiguously.

The Function aspect asks for what purpose or task an object is considered. The Product aspect asks how a system is constructed or realised. In the manufacturing application, the Host installation aspect and Site installation aspect provide installation-oriented views. The Type aspect and a documented Other aspect provide further governed structures where required.

<> Topnode= Function aspect- Product aspect+ Host installation aspect++ Site installation aspect% Type aspect# Other aspect

The result is not necessarily one definitive tag. One object can have several connected reference designations because it can occur in several structures.

IEC 81346 is an address, not a sentence.

ISA-95: operational belonging

ISA-95, also published internationally as IEC 62264, addresses enterprise-control system integration in manufacturing. Its models cover much more than hierarchy, but its role-based equipment model provides a useful answer to one practical question: where does this resource belong in the organisation of production?

EnterpriseSiteAreaWork CenterWork Unit

Work Centers and Work Units take forms appropriate to the production model, including Production Line, Process Cell, Production Unit, Work Cell, Unit, Storage Zone and Storage Unit. Equipment Modules and Control Modules provide further decomposition where applicable.

An owner may create a readable browse path such as Production / Bakery / North Plant / Building 4 / Baking / Line 2 / Oven 3. That path crosses purpose, portfolio, installation and operational structures. It is a useful owner projection aligned with ISA-95 where applicable, not a universal ISA-95 designation.

Technical structure explains the system. Operational belonging explains the work.

Brick: semantic meaning and relationships

Brick is an open ontology for describing physical, logical and virtual entities in buildings and the relationships between them. It can classify pumps, air-handling units, sensors, commands and spaces, then state how those entities are connected.

Instead of relying on a point name such as B4_AHU03_SAT, a Brick model can state that an entity is a supply-air temperature sensor, that it is a point of AHU 3, and that the air-handling unit feeds a particular air system or zone.

That is closer to how people think: pump, sensor, room, feeds, is part of. But Brick still does not provide the preferred name that operators use. It provides a governed vocabulary from which applications can understand meaning.

Domain boundaryBrick is strongest for buildings and their subsystems. Bakery machines, recipes and specialised process equipment may require an industrial vocabulary, a governed extension or another ontology alongside Brick.

Brick can provide the noun. The owner still has to provide the language.

CMMS/EAM: maintenance execution and lifecycle

A CMMS or EAM platform, such as Maximo, manages the operational consequences of owning technical assets. It records work orders, preventive maintenance, inspections, failures, condition, cost, materials, installed assets and lifecycle history.

It may also provide locations, asset hierarchies, classifications and configurable relationships. That makes it operationally indispensable. It does not make its local tag an enterprise semantic standard.

The CMMS tag tells maintenance where to place the work. Canonical identity tells the enterprise what the work was performed on.

04 · The lifecycle distinction

The role can survive the asset.

The phrase “the pump” often hides two different entities.

The first is a persistent role: process-water pump 1 must circulate water for this part of production. The second is a physical asset: manufacturer X, model Y, serial number 12345 currently fulfils that role.

ISA-95 distinguishes logical equipment from physical assets. The logical equipment can remain while the physical device changes. IEC 81346’s function-oriented and product-oriented structures offer another useful separation between required purpose and realised construction. A CMMS/EAM can represent the functional position and the installed asset as different records.

Replacement without lost historyThe role persists while the assigned product changes

Persistent roleProcess-water pump 1Same operational belongingSame required semantic type

Until replacementAsset A-18472Old serial numberAssignment has an end date

After replacementAsset A-20117New serial numberAssignment has a start date

This distinction preserves the history people actually need. Operations can follow the enduring role. Maintenance can follow each product. Engineering can follow its relevant structural occurrences. The semantic model can classify and relate the entities without pretending they are one record.

The role can survive the asset. The records should explain both.

05 · The connecting layer

Canonical does not mean one master string.

The standards and systems need a way to agree which intended entities their records concern. That is the role of canonical identity.

No standard discussed here mandates this exact mechanism. It is an owner architecture decision: a controlled way to keep several authoritative representations aligned without collapsing them into one record.

Canonical identity is not another human tag and not another attempt to replace every local identifier. It is a stable, system-neutral reference used to connect governed representations.

Information	Purpose
Canonical entity ID	Stable cross-system identity
Entity kind	Role, physical asset, space, system, point or representation
Preferred names	Human-readable and multilingual language
IEC 81346 designations	Technical routes through aspect-oriented structures
ISA-95 representation	Operational role and belonging
Semantic classes	Brick or another controlled vocabulary
CMMS/EAM references	Maintenance locations, assets and records
Source references	PLC, OPC UA, BIM, historian and document identifiers
Assignments and relations	Which asset fulfils which role, where and when
Authority and provenance	Who owns each assertion and where it came from

The information backbone does not need to copy every work order, drawing or time-series value. It needs enough identity, context and provenance to resolve the authoritative source.

Store the meaning centrally. Leave the payload with its authoritative system.

This is why the models should be aligned instead of collapsed. A Brick entity can map to a canonical entity. An ISA-95 role can be represented as another entity. An IEC 81346 object occurrence can provide a governed designation. A CMMS asset can point to the physical product. Equivalence should only be asserted where the scopes genuinely match.

One shared reality does not require one monolithic model.

06 · The maturity test

Boundaries are part of the information model.

An immature architecture chooses one system and calls it the master of everything. A mature architecture states what each model owns, how the representations are linked and what happens when they disagree.

Accidental architecture	Governed architecture
One visible tag becomes the integration key	Stable canonical identity links local designations
Hierarchy levels are generic folders	Every level and relationship has declared meaning
A Brick class is copied into a description	Semantic class and human name remain distinct
ISA-95 becomes a home-made tag syntax	Operational levels are stored as typed structures
IEC 81346 is reduced to punctuation	Designations are generated from governed aspect structures
The CMMS asset number becomes the machine	Role and physical asset remain distinguishable
Replacement overwrites history	Assignments retain effective dates and provenance
Every integration creates another mapping table	Alignments are governed information products

The test is not whether every system displays the same identifier. The test is whether the organisation can resolve each representation to the correct entity, understand its scope and trace who has authority to change it.

Do not ask a designation to become an ontology. Do not ask an ontology to become a work-order system.

The standards do not need a winner. The architecture needs boundaries.

Different truths · One governed reality

The next question is not which standard should win.

IEC 81346 can provide a governed route to the object. ISA-95 can place it in operations. A CMMS/EAM can tell us what happened to it. Preferred names let people recognise it. Canonical identity keeps the representations coherent.

But how does another application understand that the object is a pump, that it feeds a process-water system, that it has a discharge-pressure sensor and that the sensor measures a condition affected by the pump?

That is where Brick begins.

Next article · Brick

From tags to meaning.

Read article →

Sources and further reading

2026-08-06

IEC 81346 Explained: Structure Before Naming

IEC 81346 · Part 1 of 3 · The central idea

Structure before naming.

Complex facilities do not suffer from a lack of names. They suffer when different names describe different realities. IEC 81346 starts beneath the label, with the structure everyone needs to share.

8 minute readOwner perspectiveFoundation

TL;DR

One object.
Several views.
One governed whole.

IEC 81346 is primarily a standard for structuring and referencing objects, not a recipe for inventing readable equipment names.

The designation is the visible output of an underlying system model.
The same object can occur in several aspect-oriented structures.
Stable owner-governed identity reduces mappings, handover friction and reinvention.
Model the objects and structures first. Generate the designations afterwards.

01 · The recurring problem

Five names. One pump. No shared reality.

A machine supplier has one structure. Electrical design has another. Automation introduces PLC and SCADA tags. BIM has model-object identifiers. Maintenance adds an asset number. Every identifier may be useful locally, yet nobody can reliably answer whether the records refer to the same thing.

Integration teams respond with mapping tables. Those tables grow into private spreadsheets, scripts and tribal knowledge. Then a supplier leaves, a platform is replaced or a project moves into operation. The facility remains, but its meaning has to be reconstructed.

Object identity mapOne physical object seen through five systems

SupplierP-204

ElectricalMCC3-F12

The objectProcess-water pump

AutomationPLC7_MTR_04

MaintenanceAsset 18472

The problem is not that any one identifier is badly written. The problem is that the relationships between them are accidental. A new integration starts by rediscovering what the organisation already knew.

Names are cheap. Shared identity is infrastructure.

02 · The shift

The code is only the surface.

IEC 81346 is often introduced as a naming standard. That is a convenient shorthand, but it encourages teams to begin with punctuation and tag templates. The standard asks more fundamental questions first:

Define the systemWhat whole are we considering?

Recognise objectsWhich things need lifecycle identity?

Build structuresHow do those objects belong together?

Reference occurrencesHow can each position be found unambiguously?

The reference designation comes last. It expresses a path through a selected structure to an object occurrence. Starting with a desired string can create something that resembles IEC 81346 while omitting the structural logic that gives it meaning.

Implementation principleModel the objects and structures first. Generate and validate reference designations from that model afterwards.

03 · Three concepts

Object, aspect and object occurrence.

Object

An object is anything that needs to be considered during the lifecycle of a system. It can be physical, functional, spatial, typological or informational. The test is not whether you can touch it. The test is whether the organisation needs to distinguish and reason about it.

Aspect

An aspect is a selected way of viewing and structuring objects. It works like a lens: function asks what purpose is served, product asks how the system is realised, and installation asks where the object sits in its context.

Object occurrence

An object occurrence is the representation of an object within an aspect-oriented structure. The same pump can therefore occur in a functional structure, a product structure and installation structures without becoming several unrelated pumps.

This distinction is the conceptual unlock. The object is not compressed into one overloaded string. It remains one object, connected to several governed views.

04 · The owner outcome

Less detective work across the lifecycle.

The value is not that every code becomes instantly readable to every person. The value is that every designation can be resolved, governed and connected to the right context.

Moment	Without shared structure	With governed RDS
Procurement	Each supplier invents a local hierarchy.	The owner provides the information structure.
Integration	Mappings live in project spreadsheets.	Relationships are governed interfaces.
Handover	Documents and data arrive as separate islands.	Records remain traceable to the same objects.
Replacement	Platform identity is mistaken for facility identity.	Technology changes without erasing context.

Good structure is often quiet. People find what they need. Systems agree. Components can change without losing history. The absence of friction is the result.

05 · The boundary

A backbone, not the whole body.

IEC 81346 supplies aspect-oriented structure, classification hooks and reference designation principles. It does not by itself provide a complete ontology, signal model, asset database, BIM model or data-exchange architecture.

That boundary is a strength. RDS can provide durable identity and navigation while OPC UA models operational interfaces, IFC carries geometry, an EAM system manages work history and controlled vocabularies provide domain semantics.

Punctuation can imitate compliance. Only the model can provide meaning.

The next article follows one object through the available views and explains why a reference designation set is more powerful than one giant tag.

Continue the series · 02

One object. Several views.

Explore the aspects →

Sources and further reading

2026-08-04

IEC 81346 Aspects: One Object, Several Views

IEC 81346 · Part 2 of 3 · The aspect model

One object.
Several views.

A pump is not a function, a product and a location squeezed into one code. It is one object that can be represented through several structures, each answering a different question.

10 minute readInteractive guideIEC 81346-14

TL;DR

Change the lens.
Keep the object.

Aspect-oriented structures let different disciplines navigate the same technical reality without forcing every concern into one brittle tag.

= asks what purpose the object serves.
- asks how the system is realised.
+ and ++ provide host and site installation views in manufacturing.
% links an occurrence to a defined type structure.

01 · Interactive model

Look at the pump again.

Consider one process-water pump in a manufacturing facility. Operations cares what service it supports. Engineering cares how it is constructed. A technician needs to know where it is installed. A specification system may care which reusable type it represents.

Those are not competing truths. They are governed views of the same object. Select a lens:

Aspect lensClass paths based on the 1-, 2- and 3-letter table levels; occurrence numbers are illustrative

GPB

Function aspect

What purpose does this object serve?

=H1.PA1.GPB1

The object remains stable while the selected constituent relationship changes. Each occurrence provides a route through one structure. Together, the views become more useful than a single overloaded identifier.

Do not compress the facility into one clever tag. Let each structure answer its own question.

02 · The identifiers

Seven symbols, six structural roles.

For a manufacturing-oriented implementation aligned with IEC 81346-14, use the following names and distinctions. The values shown here are schematic; applicable class codes and hierarchy rules belong in the owner RDS.

Identifier	Name	Question
`<>`	Topnode	Which independent system provides context?
`=`	Function aspect	For what purpose or task is the object considered?
`-`	Product aspect	How is the system constructed or realised?
`+`	Host installation aspect	In or on which host is the object installed?
`++`	Site installation aspect	Where is it situated in the site or plant structure?
`%`	Type aspect	Which defined set of characteristics is represented?
`#`	Other aspect	Which documented additional structure is required?

Important distinctionIn the generic rules of IEC 81346-1, + represents the location aspect. IEC 81346-14 specialises manufacturing use into host and site installation views.

03 · Connected designations

A set is stronger than a super-tag.

One object can have several reference designations because it can occur in several structures. When designations relate to the same object, they form a reference designation set.

This lets each structure follow its own lifecycle. The pump can move to another room while remaining the same product occurrence. A product can be replaced while the functional occurrence and its operational history remain relevant. A type definition can evolve without pretending that every installed occurrence changed identity overnight.

Reference designation setSeveral navigable routes to one governed object

= Function=H1.PA1.GPB1

– Product-GPB1

ObjectLiquid velocity pump

++ Site++H1.PA1.DAB1

% Type%GPB1

A modern system may also maintain a stable canonical object identifier. Reference designations remain standards-based business identifiers and navigation routes rather than being forced to act as immutable database keys.

04 · Independent context

Topnode is context, not the first level.

The top node represents the considered system at the top of a structure. Its identifier can be shown before a reference designation when independent systems need to be distinguished:

<L1>=H1.PA1.GPB1
Context first. Designation second.

The identifier inside angle brackets qualifies the context. It is not itself a single-level reference designation and does not become part of the multi-level designation inside that system.

This matters when several sites, packaged systems or independently developed models are combined. Topnode prevents local uniqueness from being mistaken for global uniqueness.

05 · Information discipline

A class code is not a description.

Letter codes classify objects according to a stated classification scheme. They should not carry every fact a person may want to read from the tag.

Structural identity	Governed properties beside it
Aspect paths and reference designations	Name, description and operational role
Object class	Manufacturer, model and serial number
Object occurrence	Asset number, status and maintenance criticality
Type relationship	Dimensions, performance and configuration

Readable information remains essential. It simply belongs next to the designation as governed metadata. Encoding volatile properties into identity creates avoidable renaming and duplicated semantics.

06 · Common misreads

International-looking punctuation is not enough.

Product means manufacturerNo. Brand, model and serial number are properties, not the product aspect.

Topnode is hierarchy level zeroNo. It qualifies independent system context.

Type equals installed assetNo. A type is a defined set of characteristics, not a serialised occurrence.

Other means versionNo. The meaning of # must be explicitly documented.

The final article moves from correct interpretation to practical implementation: structured fields, procurement rules, validation and the difference between decorative and canonical RDS.

Continue the series · 03

From notation to infrastructure.

Build the operating model →

Sources and further reading

2026-08-04

Implementing IEC 81346: From Notation to Infrastructure

IEC 81346 · Part 3 of 3 · Owner implementation

From notation to infrastructure.

An RDS becomes valuable when the owner treats it as authoritative information: defined early, stored structurally, validated automatically and governed long after project handover.

12 minute readImplementationOwner governance

TL;DR

Authority is a behaviour,
not a format.

A designation is not canonical because it looks compliant. It is canonical when the organisation trusts it, governs it and rejects information that cannot be traced to it.

Store aspects as separate governed fields, not one concatenated master tag.
Define owner structures before procurement decisions harden.
Validate deliveries at design review, FAT, SAT and handover.
Keep RDS connected to BIM, OPC UA and EAM without forcing one identifier to do every job.

01 · The maturity test

Does the organisation mean it?

IEC 81346 creates lasting value only when the RDS is authoritative. If it is an optional drawing field or something added just before handover, it will lose every conflict against supplier-native tags and platform-specific structures.

Maturity switchThe same notation can support two very different operating models

TimingAdded at handover

AuthorityOptional supplier field

ChangeRebuilt when platforms change

Canonical does not mean replacing every database key, asset number or operational tag. It means the owner-governed structure is authoritative and every local representation can be traced to it.

One decorates the data. The other changes how the facility is owned.

02 · Data architecture

Do not make one string carry the model.

A robust implementation stores aspect values independently. A display designation can be composed when needed, while systems retain access to each governed route and its context.

Field	Purpose
Canonical object ID	Stable internal identity across designation changes.
Topnode	Independent system context.
Function aspect	Canonical function-oriented designation.
Product aspect	Canonical product-oriented designation.
Host installation	Installation relative to a host.
Site installation	Site or plant installation context.
Type aspect	Relationship to a governed type structure.
Other aspect	A documented additional aspect when required.
Associative relations	Governed links between object occurrences.

Projection ruleKeep the canonical full designation. Derive short display values where interfaces need them, with explicit context and collision handling.

This separation prevents a common failure: treating the human-readable tag as both database primary key, integration contract, lifecycle identity and complete semantic model. No string should have to perform all four roles.

03 · Connected systems

Give every platform the right job.

RDS is a stable identity and structure layer. Other standards and platforms remain responsible for their own concerns. The connections must be explicit, but the systems do not all need the RDS string as their primary internal key.

Information ecosystemShared object identity without a monolithic master system

BIM / IFCGeometry and model exchange

OPC UAOperational interfaces

RDSIdentity and structure

EAM / CMMSAssets and work history

DocumentsIEC 81355 containers

For OPC UA

Expose aspect values as structured metadata or properties. Let the operational browse tree remain suited to diagnostics and operation.

For BIM

Associate reference designations with model objects without asking BIM to become the master of operational semantics.

For EAM and CMMS

Keep asset numbers, serial numbers, criticality and maintenance history as attributes linked to the governed object.

04 · Advanced implementation boundaries

Standard syntax. Owner meaning.

IEC 81346-1 provides a construction for designating associative relations between object occurrences:

Object 1|relation code|Object 2
The syntax is standard. The relation vocabulary is governed.

The standard does not define a universal classification of relation kinds. If an owner uses codes for assignment, connection or composition, those meanings must be documented as an owner vocabulary rather than presented as universal IEC definitions.

Short fields are projections

Implementation fields such as Short_Function, Short_Product or Short_Site installation can be useful in constrained interfaces. They are not separate IEC aspects. A last-two-level display convention is an owner rule, not a consequence of Rule 19.

RDS is not an ontology

IEC 81346 does not by itself define signal states, event payloads, all domain properties, geometry, maintenance strategy or the complete relationship model of a digital twin. Use it as durable structural infrastructure, then connect the standards that answer those other questions.

05 · Practical sequence

Start before the first integration.

ScopeDefine considered systems and Topnodes.

ModelBuild required aspect structures.

ContractPublish machine-readable supplier rules.

GovernValidate and maintain through operation.

Choose the applicable parts of the IEC/ISO 81346 series for each domain.
State the source of every class code and project-defined relation code.
Define canonical fields, projection rules and the owning system.
Require supplier mappings to owner objects rather than accepting isolated local tags.
Validate designations at design review, FAT, SAT and handover.
Preserve mappings to legacy identifiers instead of silently rewriting history.
Give every exception an owner, reason, approval and expiry.

The best time to agree on identity is before the first integration. The second best time is before the next one.

06 · The owner mandate

Automation amplifies its foundation.

A half-adopted RDS can be worse than an honest local convention. It creates the appearance of order while the real meaning still lives in supplier tags, mapping files and people’s heads.

Maturity has little to do with how elaborate a designation looks. A mature implementation has clear ownership, controlled rules, machine validation, change governance and consequences for nonconforming deliveries.

With canonical object identity, automation connects and scales. Without it, automation makes ambiguity move faster.

The standard becomes valuable when it is part of how the facility is procured, changed and operated, not merely how a project is documented.

Series complete · Return to 01

Revisit the central idea.

Structure before naming ↺

Sources and further reading

2026-08-04

Why Technical Information Architecture Matters in Complex Technical Environments

TL;DR

The challenge: Complex facilities are not only built from systems and equipment. They are built from information. When objects, signals, requirements, documents and responsibilities drift apart, technical debt is created before the facility is even in operation.

The solution: A coherent technical information architecture, where data mapping, information modelling, master data ownership and data governance define how information is created, owned and moved between systems.

The effect: Traceability across systems, clear ownership, and a facility that can be integrated, maintained and developed throughout its lifecycle.

The Problem Is Not Lack of Data

Modern industrial and facility projects are becoming increasingly digital, connected and supplier-driven. Automation systems, building systems, production equipment, IT/OT networks, BIM models, SCADA platforms, data platforms and maintenance systems all create and consume technical information.

But in many projects, this information is not treated as a system in itself. Each supplier, discipline and platform structures information in its own way. Equipment has one name in the design model, another in the PLC, another in SCADA, another in the documentation, and a separate identity in the maintenance system. Signals are delivered without clear meaning. Requirements are written without traceability. Data is moved between systems without a defined owner.

Most projects already produce large amounts of data. The problem is that the data is often fragmented, inconsistent and difficult to trust. The result is technical debt built into the facility before it is even in operation.

The Same Pump, Eight Identities

Within a single project, one pump may exist as a physical object, a drawing symbol, a BIM object, a PLC tag, an OPC UA node, a SCADA object, a maintenance asset and a line in a supplier document. If these representations are not connected, the owner has no coherent understanding of their own asset.

The same pattern repeats for requirements, signals, alarms, documents, interfaces and handover data. When information is not structured, the facility becomes harder to own.

Data mapping is the work of saying: this is the same real-world object, expressed in different systems and data models.

Data Mapping Is the Activity, Not the Whole Solution

Data mapping is the practical work of connecting information between systems: a supplier tag to an OPC UA node, a BIM object to an asset record, a process signal to a historian tag. It is necessary, but not sufficient.

To create long-term control, the owner also needs information modelling, semantic modelling, master data ownership, data governance and clear integration principles. Together, these disciplines define:

what the information means
how it should be structured
which system owns it
how it moves between systems
who is responsible for maintaining it
how it can be verified and reused over time

This is technical information architecture. Standards such as IEC 81346 provide the structural foundation: stable identities for objects, systems and functions that hold throughout the lifecycle.

Why It Matters for Asset Owners

Without a clear information architecture, the owner becomes dependent on suppliers, individuals and undocumented project logic. Future changes become slower, integrations more expensive and operations harder to manage.

With a clear information architecture, the owner can create traceability between systems, assets, requirements, documents and operational data. This makes it easier to commission the facility, maintain it, integrate new systems, analyse performance and continue developing the facility over time.

Technical information architecture is therefore not an IT issue. It is a lifecycle ownership issue.

HubMind’s Role

HubMind helps asset owners create structure where technical complexity would otherwise grow. We work across automation, IT/OT, BIM, asset management, requirements, supplier data and system integration.

Our role is to connect technical objects, signals, requirements, documents, responsibilities and systems into a coherent information structure that can be used throughout the facility lifecycle. The result is better traceability, clearer ownership, stronger integration and a facility that is easier to understand, operate and develop over time.

Need a structure your facility can actually be owned through?

HubMind helps asset owners align information modelling, master data ownership and governance so systems can integrate and operations can scale.

Contact us

2026-07-13

Multidisciplinary Digitalisation: From Silos to Collaboration

TL;DR

Conclusion

True digitalisation requires that electrical, HVAC, automation, IT and OT disciplines speak the same language and share the same information structures.

The challenge

Disciplines work in silos, each with their own tools, naming conventions and documentation – making integration expensive and data unreliable.

The solution

A cross-disciplinary approach based on shared standards (IEC 81346) and clear interfaces between disciplines.

The effect

Information that flows from sensor to decision support without manual translation – from the first project day to the last day of operation.

The Silo Problem in Complex Projects

Three Perspectives That Must Converge

In modern industrial and building environments, three perspectives must converge for digitalisation to succeed:

The technical perspective – How systems are built, what they do, how they communicate and what their interfaces are
The information perspective – How data is named, structured and made traceable across system boundaries
The organisational perspective – Who owns what, who decides what and how responsibility is allocated when disciplines meet

When only one or two of these perspectives are addressed, the result is a technically connected but informationally fragmented environment.

Getting the Disciplines to Work Together

The most effective tool for creating cross-disciplinary coherence is shared standards – particularly IEC 81346. By requiring that all disciplines use the same reference designation system, the same object appears with the same identity regardless of which system or discipline is looking at it.

Beyond standards, cross-disciplinary work requires:

Early involvement of all disciplines in information structure decisions
Clear requirements on suppliers regarding compliance with shared standards
Explicit ownership of cross-disciplinary information and interfaces
Verification that information requirements are met – not only that systems function

The Role of the Technical Owner’s Representative

In complex multidisciplinary projects, someone must hold the overall information picture on the owner’s side. This is exactly the role of a technical owner’s representative: to ensure that requirements, interfaces and information structures are defined before procurement, maintained during the project and verified at handover.

Without this role, each discipline optimises for its own delivery – and the interfaces between them are left to chance or to whoever ends up managing the integration.

The whole is greater than the sum of its parts. Future automation is not a question of individual products or suppliers. It is a question of architecture, structure and above all collaboration between people and systems. The one who succeeds in building the bridge between IT, OT and the actual business is the one who will extract the real gains from digitalisation.

Need to break silos between IT, OT and operations?

HubMind helps asset owners establish shared information structures, governance and delivery contracts so multidisciplinary teams can scale without rework.

Contact us

2026-07-08

Author: David Nordin

Expertise has a boundary.Authority needs a mandate.

Being involved is not the same as being authoritative.

BIM is exceptionally powerful. That is exactly why its boundary matters.

Lead your domain. Hand off the next decision.

Build the complete-object house.

Give every authority a job and a stop line.

Mandate inflation often looks like helpfulness.

Govern the handoffs, not just the boxes.

Competence builds the bricks.Governance carries the load.

Query the meaning.Retrieve the value from its source.

A semantic interface is a contract, not a new monolith.

Let SPARQL find the sources and their context.

Separate discovery from retrieval.

Use SHACL as a gate, not a slogan.

Make implicit behaviour an explicit deployment choice.

Extend locally without forking the shared language.

Accept the interface with tests and a named owner.

Meaning becomes infrastructure when it is discoverable, testable, versioned and owned.

Revisit the move from tags to meaning.

Sources and further reading

One object is a node.Its usefulness lives in the edges.

Separate the thing from the kind of thing.

Open the casing with hasPart.

State what it feeds, and where it is.

Connect the machine to its points and roles.

Read every relationship in its declared direction.

Let competency questions draw the boundary.

Say what was observed, inferred or referenced.

Context is not decoration around the object. It is the interface through which the object becomes usable.

Turn the graph into a semantic interface.

Sources and further reading

Interfaces move data.Brick moves understanding.

Data arrived. Meaning did not.

An ontology is a vocabulary with relationships.

Entities are the things

Classes declare what kind of thing

Relationships create the neighbourhood

The graph makes it queryable

Stop decoding labels. Start asking the graph.

Brick makes more sense. It is still not the popular name.

Stop re-teaching the building to every application.

IEC 81346 gives the route. Brick describes the neighbourhood.

A semantic layer is not the entire stack.

A label helps us recognise something. A graph helps software understand it.

One object. A graph of context.

Sources and further reading

Reference.Belonging.Meaning.Execution.

One tag is asked to carry the whole facility.

One pump. Several valid answers.

Give every model the right job.

IEC 81346: technical structure and reference

ISA-95: operational belonging

Brick: semantic meaning and relationships

CMMS/EAM: maintenance execution and lifecycle

The role can survive the asset.

Canonical does not mean one master string.

Boundaries are part of the information model.

The next question is not which standard should win.

From tags to meaning.

Sources and further reading

One object.Several views.One governed whole.

Five names. One pump. No shared reality.

The code is only the surface.

Object, aspect and object occurrence.

Object

Aspect

Object occurrence

Less detective work across the lifecycle.

A backbone, not the whole body.

One object. Several views.

Sources and further reading

Change the lens.Keep the object.

Look at the pump again.

Seven symbols, six structural roles.

A set is stronger than a super-tag.

Topnode is context, not the first level.

A class code is not a description.

International-looking punctuation is not enough.

From notation to infrastructure.

Expertise has a boundary.
Authority needs a mandate.

Competence builds the bricks.
Governance carries the load.

Query the meaning.
Retrieve the value from its source.

One object is a node.
Its usefulness lives in the edges.

Open the casing with `hasPart`.

Interfaces move data.
Brick moves understanding.

Reference.
Belonging.
Meaning.
Execution.

One object.
Several views.
One governed whole.

Change the lens.
Keep the object.

Authority is a behaviour,
not a format.