The Data Problem
Every enterprise has the same story. Underwriting keeps the truth in Oracle. Risk keeps a different truth in SQL Server. Finance keeps yet another in SAP. When a question crosses those boundaries, someone has to spend a week reconciling three spreadsheets and hoping the columns line up.
AI Amplifies the Chaos
One person with AI agents can now produce what used to take a team. More output means more data — and more data without structure means more chaos.
The flood of AI-generated artefacts — models, scans, reports, system updates — lands in the same fragmented landscape. Without a consistent way to address, own, and combine that output, agents just add noise to noise.
The Missing Piece: Combinability
Take this contract here, combine it with that portfolio there, overlay this exposure data, and show me the result.
That sentence is easy to say and brutally hard to execute across isolated silos. The missing ingredient is not more storage — it is combinability: a shared addressing scheme, clear ownership, and agreed contracts between producers and consumers.
Data Products: The Building Block
A data product is a self-contained unit of data with clear boundaries. It has a unique address in the mesh, a named owner who is accountable for its quality, a typed schema that acts as a contract with consumers, and explicit service-level commitments about freshness and availability.
Each attribute is non-negotiable. Without an address, the product cannot be referenced. Without an owner, quality erodes. Without a schema, consumers cannot trust the data. Without service levels, pipelines break silently.
From Silos to a Mesh
Data products become nodes in a graph. Arrows show data flowing from producers to consumers, with the agreed freshness commitment labelled on each connection — real-time, T+1, weekly, monthly, quarterly, or annual. The mesh makes those commitments visible and auditable instead of buried in hand-off emails.
How MeshWeaver Implements This
MeshWeaver provides a complete set of building blocks for Data Mesh, each documented in its own guide:
| Capability | What it covers |
|---|---|
| Node Types | Design, compile, NuGet-reference, and test node types end to end |
| Addressable Paths | Every product gets a permanent, unique address in the mesh |
| Addressability of Objects | Why one addressable namespace lets an agent go from a plain-English ask to a precise, typed action |
| Query Language | GitHub-style search syntax to discover and filter across products |
| CRUD Operations | Type-safe create, read, update, and delete for any product |
| Node Operations | Export, import, copy, and move node subtrees |
| Data Modeling | C# records as the schema contract between producers and consumers |
| Data Cubes | Dimensions, FX conversion, and live slice-and-dice pivot tables and charts |
| Satellite Entities | Comments, approvals, access, and audit trails attached to any node |
| Interactive Markdown | Embed live data and charts directly inside documentation |
| NuGet Packages | Reference any NuGet package from interactive markdown with #r "nuget:..." |
| Collaborative Editing | Real-time co-editing with track changes |
| Data Configuration | Wire data sources and hub-to-hub synchronization |
Start Building
Follow this sequence to go from raw data to a governed, combinable data product:
- Model — Define your types and schema: Data Modeling + Node Type Configuration
- Address — Give every product a permanent home and reach every facet by path: Unified Path + Addressability of Objects
- Operate — Wire up reads, writes, and sync: CRUD + Data Configuration
- Govern — Attach ownership, access, and audit trails: Satellite Entities
- Consume — Surface live data in docs and dashboards: Interactive Markdown