Weaver, a linked-data Common Data Environment for complex, long-lived assets
Why CDEs matter
ISO 19650 defines a Common Data Environment as the agreed source of information for any given project or asset, for collecting, managing and disseminating each information container through a managed process. That definition is at the heart of why CDEs exist: when information lives in many places and many tools, the cost of keeping it consistent grows faster than the project does.
For complex, long-lived assets the consequences of getting this wrong are severe. A research reactor operates for 70 years. A bridge for 100. A submarine programme for 50. Across those spans, every software vendor in existence today will have changed, been acquired, or disappeared. The information about the asset must survive those changes.
The CDE is not a filing cabinet. It is a discipline, and the right tool for that discipline is one that treats information containers as first-class objects in a queryable, traceable, audit-by-default knowledge graph.
The three silos problem
1. Documents, drawings, specifications, reports, contracts. Managed in a document management system or one of the document-first CDEs (Aconex, Asite). Strong revision control, weak semantic relationships.
2. Geometric models, 3D BIM models, P&IDs, plant layouts. Managed in BIM authoring tools and model-first CDEs (Autodesk Construction Cloud, Bentley iTwin). Strong on geometry, weak on structured data.
3. Structured data, requirements, asset registers, breakdown structures, V&V plans. Managed in Excel, Relatics, or specialised systems-engineering tools. Often a second-class citizen even where it's most critical.
Walk into any complex asset programme and you'll find information divided into three categories, each managed by a different category of tool:
Nothing connects them. Excel quietly becomes the glue. Impact analysis is manual. Inspection prep takes weeks. The integration cost grows with the project, then doubles at handover.
Weaver's design starts from the position that these three silos cannot be tolerated for assets that have to remain auditable for fifty years. The platform treats documents, models and structured data with equal first-class status, in one knowledge graph, governed by one metamodel.
Sensor and streaming data is treated as a fourth category, handled differently. High-volume time-series belongs in the historian where it scales; Weaver links to it through SPARQL federation and ingests only the contextual metadata (sensor identity, calibration record, asset placement) that belongs in the graph. The three-silo discipline applies to the artefacts that need versioning, governance and cross-silo links; the stream stays where streams belong.
A linked-data foundation
Weaver is built on RDF (Resource Description Framework), the W3C standard for knowledge graphs. Every information container (a drawing, an IFC element, a requirement, a change order, an inspection record) is a node in the graph. Every relationship between containers is a triple in the graph. Every query is a SPARQL query.
This is not exotic technology. RDF has been a W3C recommendation since 1999. SPARQL since 2008. The ecosystem of mature stores, query engines, validation tools (SHACL) and ontology languages (OWL) is twenty years deep.
What linked data buys you in this domain is that relationships are first-class. A requirement is satisfied by a system; a system contains components; components are described by drawings; drawings are derived from specifications. The relationships ARE the information. A graph stores them natively; a relational database stores them as awkward foreign keys.
Once the data is a graph, the question changes from 'where do I look this up?' to 'what do I want to know?'
ISO 19650, information container discipline
ISO 19650 is the international standard for information management using BIM. It defines, among many other things, the information container concept (a named, persistent, versioned unit of information) and the suitability status workflow (Work in Progress → Shared → Published → Archived).
Most CDEs implement this for documents. Few extend it to structured data or model elements. Weaver applies the same discipline to all three: every container has a known type, a known status, a known owner. Approval is workflow-driven; the audit trail is queryable; nothing slips through informal channels.
The practical effect is that ISO 19650 compliance becomes a structural property of the platform, not a process people have to remember to follow.
ISO 15926-11, the reference metamodel
Weaver ships with the ISO 15926-11 reference data library pre-configured as the default metamodel. ISO 15926 has been under development across the process and energy industries since the 1990s. It is the most mature semantic data standard for industrial asset information, with established roots in oil & gas, power generation, and increasingly in nuclear.
The metamodel defines core classes (Physical Object, Functional Object, Activity, Property) and the relationships between them. Customers inherit the core and add domain-specific subclasses. 'NuclearReactorVessel' is a subclass of 'Physical Object' with its own properties. Extensions are RDF, queryable, machine-readable, version-controlled.
Adopting an open standard for the metamodel avoids the 'every vendor has its own data model' problem that has plagued asset management for two decades. It also makes cross-organisation interoperability possible: external auditors, regulators or partners can read your data without a translation step.
Federation through pre-built data modules
A common failure mode for CDE deployments is the assumption that the CDE must own all the information. Revit must be replaced. Relatics must be migrated. SharePoint must be retired. None of this is necessary, and most of it is counter-productive. Authoring tools are where engineers do their best work, and asking them to abandon those tools is asking for friction.
Weaver federates. Existing tools stay in place. What changes is how their output reaches the knowledge graph: through pre-built data modules that customers configure, not through integration code customers have to write and then maintain.
A unified knowledge graph is worthless if it's hard to get data in and out. Most asset programmes lose budget on custom integration code: how to ingest an IFC file at object level, how to keep a Relatics requirements register in sync, how to transform a vendor's inspection CSV into a typed asset record. That code breaks. It rots. It outlives its author. Weaver ships modules for the common shapes (IFC, BCF, openCDE, Relatics, SharePoint, Autodesk Construction Cloud, OData, generic CSV) and a configurable pipeline engine for the rest. Both customer and Weaver-built modules are versioned and reusable across projects.
What the CDE owns is the semantic layer: the information container lifecycle, the version history, the cross-silo relationships. The authoring tools own the authoring. The integration layer owns nothing but configuration. The split is clean and stable across decades.
Git-style versioning
Most CDEs offer revision control. Weaver offers something stronger: the history model that distributed version-control systems like Git brought to source code, applied to asset data. Every change to every information container is a commit, attributed and immutable. The history is a directed acyclic graph, not a flat log. There is no 'delete' operation that removes history; there is only 'supersede'. Earlier versions remain queryable forever.
This unlocks four capabilities that ordinary revision control cannot reach. First, branching: engineers can fork the data to explore alternatives (a candidate cooling-system spec, a proposed safety-case revision) without disturbing the main line of development. Second, diffs: any two commits or branches can be compared, exactly, by query. Third, merging with conflict resolution: when two teams have changed the same container in parallel, the conflict is surfaced explicitly and resolved deliberately, not lost. Fourth, tags and baselines: any commit can be marked as a formal baseline (an as-built record, a regulatory submission, a design freeze) and referenced for the rest of the asset's life.
Time-travel queries are first-class. 'Show me the configuration of System X as it existed on 14 March 2031' is a single SPARQL query. So is 'Show me every requirement that has changed since the last regulatory inspection.' So is 'Trace the lineage of this design decision back to the originating requirement.'
The audit trail isn't a separate system writing to a log file. It is a consequence of the data model: the same graph that holds the data holds its full version history. For complex assets where regulatory accountability can be demanded decades after the fact, this is non-negotiable architecture.
The standard model
Weaver ships with a pre-configured deployment called the standard model. It implements the ISO 15926-11 reference data library, the ISO 19650 information container workflow, the master information delivery plan template, and a set of default applications for common tasks. Most customers can use it as-is for the pilot phase and extend it during rollout.
Configuration of the standard model is itself RDF. There is no 'customisation' in the traditional software sense, extending the metamodel is editing RDF triples through a configuration UI. This is the difference between a configurable platform and a customisable product, and it has significant consequences for who can do the work (a trained customer-side operator) and how long it takes (hours, not weeks).
Customers who already have a domain ontology can replace the standard model entirely. The platform doesn't mandate ISO 15926-11; it merely defaults to it.
Limitations
Weaver isn't a 3D authoring tool. It doesn't replace Revit, AVEVA, Tekla or AutoCAD. It ingests their output and federates them, but engineers do their authoring in their existing tools.
Weaver isn't a project management tool. Programme scheduling, resource allocation and earned-value tracking live in their dedicated systems (Primavera, MS Project). Weaver integrates with them, but doesn't try to replicate them.
Weaver isn't a full BIM viewer. Navisworks, Solibri and BIMcollab remain the right tools for clash detection and federated model visualisation. Weaver integrates via the buildingSMART BCF API.
Weaver is opinionated about open standards. It is a poor fit if you want a proprietary, closed-stack vendor relationship, the architecture deliberately makes Weaver itself replaceable, and that's a feature, not an oversight.
Finally, Weaver is a platform, not a turnkey product. An implementation is an engagement, not a software installation. Customers who expect to buy a finished solution and operate it without training will be disappointed.