Context
Most products labelled 'CDE' are document-first (Aconex, Asite) or model-first (Autodesk Construction Cloud, Bentley iTwin). They handle their primary information type well and treat the other two as second-class citizens. Structured data (requirements, asset registers, breakdown structures, verification plans) usually ends up in Excel.
This is why Excel quietly remains the de facto integration tool of every large project.
Explanation
There are three failure modes, often combined:
No first-class container type for structured data
Document management systems see a CSV the same as a PDF. Model-first CDEs see structured data as attached metadata on geometry, not as an independent information container with its own lifecycle. As a result, structured data inherits the workflow of whatever it's attached to.
No semantic relationships across information types
You can attach a requirements PDF to a model, but you cannot ask 'which requirements does this turbine fail to meet?' The relationship isn't expressed in a queryable form. The link is human-readable, not machine-readable.
No metamodel discipline
Structured-data tools that do exist (Relatics, Levvr) often don't enforce a metamodel. You can store anything however you like, which means cross-project consistency is impossible and integration with BIM data is purely conventional.
Weaver treats structured data, documents and models with equal first-class status. All three are containers in the same RDF knowledge graph, related by the ISO 15926-11 metamodel and managed under the same ISO 19650 lifecycle. Structured data isn't bolted on; it's a peer of everything else.