Engineered to outlast vendors

An open and durable graph-based Common Data Environment engineered for long-lived complex assets

Open by design

Built on open standards;

RDF, SPARQL, ISO 19650, ISO 15926, NEN 2660

, so your data outlives any single tool or vendor, including us.


Durable by design

A nuclear plant, an offshore wind farm, a tunnel is engineered over years and operated for decades. Their information must remain connected, traceable and trustworthy long after individual tools, vendors and file formats have changed.

One single point of truth

With Weaver, you connect your existing data and tools into one open and durable graph database, versioned like source code so it stays auditable for the asset's entire 50-to-70-year life.


What you get

  • Change impact, fully traced
  • Data your AI can act on
  • Faster work, fewer errors
WHO IT'S FOR

Built for complex assets

A complex asset is any physical system that takes years to build, decades to operate, and demands rigorous traceability for its entire life; a research reactor, a submarine, an offshore wind park, a tunnel, a large industrial transformer. The kind of asset whose configuration must be defensible to a regulator forty years from now.

One single point of truth

Your existing tools connect through APIs into one consistent structure, so the relationships between requirements, risks, documents, 3D models and decisions stay visible and traceable for the entire life of the asset.

Data your AI can act on
Change impact, fully traced
Faster work, fewer errors
Nuclear & research reactors
Offshore wind & energy
Aerospace & defence
Major infrastructure
Industrial installations

Across these industries the operational requirement is the same: every information container (design model, requirement, change order, inspection record) must remain connected to the asset for its full lifetime, and remain readable independent of any single vendor's survival.

THE PROBLEM

Three disconnected silos

Asset organisations manage their information in three categories that never properly talk to each other.

DOCUMENTS

Drawings, specifications, reports

SharePoint · Aconex · DMS
Without connectionYou can't:
  • Link a decision to the requirement it satisfied
  • Track revision history as data, only as folder structure
  • Query across documents (references are clickable text, not links)
3D MODELS

Geometry, BIM, P&IDs

Revit · AVEVA · Tekla · IFC
Without connectionYou can't:
  • Ask which element implements which requirement
  • Trigger document review when a model changes
  • Connect geometry to the asset's structured data
STRUCTURED DATA

Requirements, registers, breakdowns

Excel · Relatics · ERP
Without connectionYou can't:
  • Keep requirements alongside the model they govern
  • Run cross-silo queries without manual reconciliation
  • Prepare for inspection without weeks of cross-tool gymnastics
SENSOR & STREAMING DATA

Telemetry, time-series, IoT streams

Historian · OPC UA · MQTT · InfluxDB · TimescaleDB
Handled differently · linked, not ingested
  • Lives in the historian or time-series store, where it belongs.
  • Weaver points to it: graph nodes (asset, system, sensor) link out via SPARQL federation.
  • Only the contextual metadata, sensor identity, calibration record, placement, sits in the graph.

Without connection, decisions are made on incomplete information, and the cost compounds across forty years of operations.

OVERVIEW

What Weaver is

01

A Common Data Environment, properly

Weaver is a Common Data Environment (CDE) for complex assets. In the language of ISO 19650, a CDE is the agreed source of information for a project or asset: the place where every information container is managed, versioned and made discoverable.

02

One knowledge graph, every information type

Most CDEs handle documents well, geometric models reasonably and structured data poorly. Weaver is built around a single principle: every type of information lives in one linked-data knowledge graph, queryable across silos and versioned like Git so you can branch alternatives, time-travel and merge across the asset's entire life.

CONFIGURE DATAFLOWSXMLRDLRevit, IFCRelatics, ERPAconex, DMSACC, BIMPowerBIExcel / PDFAI agent / RAGCustom AppWEAVERWEAVER APPS
Platform principles

Configure data flows. Don't code them.

All structure, all integration logic, all reference data lives as RDF configuration. Weaver ships pre-built modules for the common data shapes (IFC, BCF, Relatics, SharePoint, OData, CSV) and configurable pipelines for the rest. Adding a new asset class or hooking up a new source is a configuration change, typically a few hours by a trained operator, not a multi-week engineering cycle.

Configure, don't develop

WHY WEAVER

Same three categories. Now connected.

The three silos are still there as concepts. The boundaries between them are gone. Every constraint becomes a normal operation.

DOCUMENTS

Drawings, specifications, reports

Now first-class graph citizens
Now you can
  • Link any decision to the requirement that drove it
  • Query revision history as data, not folder structure
  • Walk typed links across documents and into models
3D MODELS

Geometry, BIM, P&IDs

Ingested at object level
Now you can
  • Trace any element back to the requirements it implements
  • Trigger document review automatically when geometry changes
  • Connect geometry directly to the asset's structured data
STRUCTURED DATA

Requirements, registers, breakdowns

Native, not exiled to Excel
Now you can
  • Keep requirements as nodes alongside the model they govern
  • Run cross-silo queries in a single SPARQL statement
  • Generate inspection packs from the graph, in minutes
SENSOR & STREAMING DATA

Telemetry, time-series, IoT streams

Federated, not duplicated
Handled differently · linked, not ingested
  • Query across the graph and into the historian in one SPARQL statement.
  • Sensor identity and calibration record stay first-class in the graph; the stream stays where it scales.
  • No streaming pipeline to maintain. No double source of truth.

Impact analysis is a SPARQL query. Inspection prep is a report. Decisions are made with the full picture, and every step is preserved for the next forty years of operations.

HOW IT WORKS

Linked, versioned, governed

The principles, made concrete. Three load-bearing mechanics of Weaver explained from the inside: a data model that travels with the asset, a history that never forgets, and a workflow that enforces ISO 19650 without ceremony.

01DATA MODEL

A linked-data foundation

Every information container becomes a typed node in one RDF knowledge graph, governed by an ISO 15926-11 reference data library. Relationships are first-class citizens, not joins to reconstruct after the fact.

Inside the block
  • RDF triplessubject, predicate, object
  • ISO 15926-11 metamodelextensible per domain
  • SHACL shapesschema validation at write time
  • SPARQL endpointfederated query across the graph
IN PRACTICE

One SPARQL query answers cross-silo questions in milliseconds: every approved requirement allocated to System X, its verification status, and the IFC elements that implement it.

02HISTORY

Versioned like Git, for asset data

Every edit to every node is an immutable, attributed commit. The history is a directed graph, queryable like the data itself. The audit trail is the data model, not a separate log to maintain.

Inside the block
  • Commitsattributed, signed, immutable
  • Branchesexplore design alternatives in isolation
  • Diffs and mergesexplicit conflict resolution
  • Time-travel readsany past state, on demand
IN PRACTICE

Branch the asset record to scope a design change, review the diff, merge it back when approved. Inspectors can read the asset exactly as it stood on any chosen date.

03LIFECYCLE

ISO 19650, enforced by workflow

Every container moves through a defined state machine under role-based approval. The Master Information Delivery Plan is live data, not a spreadsheet that drifts.

Inside the block
  • Four statesWIP, Shared, Published, Archived
  • Approval workflowsrole-based, queryable
  • Live MIDPevery container, throughout life
  • Audit trailpart of the graph, by default
IN PRACTICE

Inspection prep becomes a query against Published containers. Regulators receive the information already structured for them, with the audit trail attached.

EST. 2013

Weaver is built by a team with more than a decade of experience in graph technology for industrial assets. We started in oil and gas, where the data was complex and the standards were leading. We're now where the rest of the industry has caught up.

WHY NOW

The moment has arrived

Three independent currents are converging on the same point — and asset programmes starting today can finally treat information as a first-class engineering artefact.

  1. 01Standards

    Open standards have caught up.

    ISO 19650 adoption is accelerating across the UK, the Netherlands and the EU. Regulators are demanding digital evidence, not document piles. The procedural backbone for asset information is finally there.

  2. 02Tooling

    Linked-data tooling is mature.

    Twenty years of W3C work behind RDF and SPARQL. Decades of production use in oil and gas, increasingly in nuclear. The exotic-research-project label is gone; the stores, query engines and validation tools are battle-tested.

  3. 03Demand

    AI needs typed knowledge graphs.

    Retrieval-augmented generation and agentic workflows perform best on semantic, ISO-15926-11-shaped data. The information substrate is suddenly load-bearing for the next generation of operational tools.

Convergence2026
DEEP DIVE

The whitepaper

A detailed treatment of the architecture, the standards and the reasoning, written for the technical readers on your team.

Download the whitepaper
ARCHITECTURE

What's actually inside the platform

Six layers, every one an open standard, every one independently replaceable. The unique part is at the bottom: an RDF abstraction over a battle-tested PostgreSQL store.

L1

FabricGraph app suite

Our base UI component, tailored per client with short lead time. The web UI, customer-built apps, and bespoke views all sit on FabricGraph.

L2

Open APIs

Language-neutral, programmatically accessible. Use the language your team already knows.

L3

Standard model

Pre-configured reference data and information container workflow.

L4

Pipelines & workflows

RDF-configured data transformations and approval workflows. No integration code.

L5

RDF knowledge graph

Linked-data abstraction. Every information container, every change, every relationship.

L6

PostgreSQL storage

Battle-tested SQL storage underpinning the RDF graph. The operational maturity of SQL with the expressiveness of linked data.

STANDARDS

Built on the standards that shape the field.

Weaver implements, and actively contributes to, the open standards that govern information management for complex assets. Vendor-neutral by design, the platform stays compatible as the standards evolve.

  • ISO 19650

    BIM information management

    Container lifecycle, approval workflows, the Master Information Delivery Plan.

  • ISO 15926-11

    Asset reference data

    Domain-extensible metamodel for industrial assets, mature in process and energy.

  • buildingSMART

    openBIM suite

    Native object-level support for IFC, BCF and openCDE.

  • W3C

    Semantic web stack

    RDF for the data, SPARQL for queries, SHACL for shape validation.

A field of green grass with wind turbines on the horizon
PLATFORM

What the architecture makes practical

01

Integration is configured, not coded

Pre-built modules cover the common sources (IFC, BCF, Relatics, SharePoint, OData, CSV) and a pipeline engine handles the rest. New sources and reference-data extensions are configuration changes, owned by your own Certified Weavers, not multi-week engineering projects that outlive their budget.

02

Connects the tools you already run

Object-level IFC, BCF and openCDE keep your design and clash tools in the loop; REST, GraphQL, OData and SPARQL endpoints expose the graph to everything else. Weaver becomes the semantic backbone between your systems, not a replacement for them.

03

An AI-ready knowledge graph

A typed, ISO 15926-11-grounded graph is the right substrate for retrieval-augmented and agentic AI: enough structure for downstream models to answer real questions about the asset rather than hallucinate plausible ones.

SECURITY & DEPLOYMENT

Designed for regulated environments

Nuclear, defence and aerospace customers screen on the deployment shape. Here are the commitments.

  • On-premise, air-gapped or cloud — your operational choice
  • No telemetry, no phone-home, no required outbound connections
  • Customer-owned data, exportable as RDF at any moment
  • Signed container images for air-gapped delivery
  • EU data residency available
  • Audit-by-default — the trail is part of the data model
More on deployment in the knowledge base
Blue-lit network cables running through a row of server racks
WEAVER IN CONTEXT

How Weaver compares

The platforms a serious procurement team would shortlist for a complex, long-lived asset programme, and the layer Weaver provides underneath them.

Linked-data foundation (RDF / SPARQL)
Weaver
Oracle Aconex
Autodesk Forma
Bentley iTwin
AVEVA AIM
Palantir Foundry
Open-standards metamodel (ISO 15926-11)
Weaver
Oracle Aconex
Autodesk Forma
Bentley iTwin
AVEVA AIM
Palantir Foundry
Git-style versioning across the whole graph
Weaver
Oracle Aconex
Autodesk Forma
Bentley iTwin
AVEVA AIM
Palantir Foundry
Documents, 3D models and structured data in one graph
Weaver
Oracle Aconex
Autodesk Forma
Bentley iTwin
AVEVA AIM
Palantir Foundry
Full graph export, vendor-neutral portability
Weaver
Oracle Aconex
Autodesk Forma
Bentley iTwin
AVEVA AIM
Palantir Foundry
On-premise / air-gapped deployment
Weaver
Oracle Aconex
Autodesk Forma
Bentley iTwin
AVEVA AIM
Palantir Foundry
Out-of-the-box construction / contracts workflows
Weaver
Oracle Aconex
Autodesk Forma
Bentley iTwin
AVEVA AIM
Palantir Foundry

NOT A REPLACEMENT

Weaver doesn't replace these platforms; it connects them. Each is best-in-class at its core domain. What none of them does is link documents, models and structured data into one queryable, versioned graph. That's the layer Weaver provides, and the layer this table is measuring.

Native, first-class capability Partial or peripheral support Not supported

Comparison based on public documentation as of May 2026. Autodesk Construction Cloud is being rebranded as Autodesk Forma. AVEVA AIM is the Asset Information Management product within the Schneider Electric portfolio. Vendor capabilities may have evolved since.

CASE STUDY · NUCLEAR

A research reactor with a 70-year operational mandate

Concrete cooling towers of a nuclear power plant under a daytime sky
−80%
Inspection prep

Time to assemble regulatory inspection packs, reduced from 4–6 weeks to under one week.

100%
Change traceability

Every design change linked to its originating requirement and approval record.

70+ yrs
Versioned audit trail

Every change preserved, branchable, diffable, time-travellable across the asset's full life.

A nuclear research-reactor programme procured Weaver as the Common Data Environment across design, construction and operations. Ten-year build, 70-year operational design life, multi-vendor consortium, ISO 19650 and ISO 15926-11 disciplined throughout. No information-loss event at handover, because handover is no longer an event.

Names and figures anonymised. The programme shape reflects a representative Weaver deployment in nuclear.

ON OPEN STANDARDS

Clients aren't paying us for a guarantee that our company will exist for seventy years. They pay for software intentionally built on open, global standards, so the data format remains understandable in ten, thirty or seventy years, by any competent vendor in the world.

That is the value of building on open standards: the asset isn't tied to a single company's survival. Even if Weaver disappeared tomorrow, the data remains valid, portable, and continuable.

HONESTLY

What Weaver isn't

Knowing the boundaries up front is faster than discovering them in a demo.

  • Not a 3D authoring tool

    Revit, Tekla and AVEVA stay in place. Weaver ingests their output at object level.

  • Not a project-management tool

    Primavera and MS Project stay in place. Weaver federates with them rather than replicating them.

  • Not a full BIM viewer

    Navisworks, Solibri and BIMcollab remain the right tools for federated visualisation and clash detection.

  • Opinionated about open standards

    A bad fit for buyers who want a closed-stack, single-vendor data model. We won't pretend otherwise.

  • A platform, not a turnkey product

    An implementation is an engagement, not a software installation. Expect the first eight to twelve weeks.

WHAT YOU GET

What an engagement actually delivers

At the end of a typical 8–12-week pilot, the customer has:

A working pilot

A single asset live on Weaver, with real users, real data, real workflows.

ISO 19650 workflow in production

Information containers moving through WIP → Shared → Published → Archived, queryable.

Object-level IFC ingestion

Revit / AVEVA exports flowing in as graph nodes with full property and relationship data.

Two source integrations

Typically Relatics for requirements and SharePoint (or the existing DMS) for documents.

3–6 Certified Weavers

Customer-side operators trained on configuration. Your team owns the platform after handover.

Audit-by-default in production

Every change preserved with who, when and what, queryable by SPARQL on day one.

PRICING

Annual subscription, programme-scoped

~80–150k EUR / year

Single-asset programmes. Scales with scope, integration footprint and deployment mode.

No per-seat, no per-feature gates

Full platform, every release. No premium tiers within the product itself.

Implementation priced separately

Roughly aligned to a typical 8–12-week consulting engagement. Quoted up front.

Full pricing detail in the knowledge base
Engagement

How a Weaver implementation begins

We default to a pilot-first, evidence-led engagement, typically eight to twelve weeks before going operational on a single asset programme.

Step 01
01

Scope & reference data review

A two-week alignment workshop: define the pilot asset, review your existing tooling landscape, and agree which parts of the ISO 15926-11 reference data library you'll inherit versus extend.

01 / 05