One project. One set of operations.
Weaver reads declarations in Python, SQL and TMDL, then uses them to build and operate Fabric items.
Source files describe the project; installed state records what has been deployed.
Native declarations
T-SQL
A comment above an ordinary query. Identity, keys and schema sit in native SQL metadata; the SELECT stays ordinary T-SQL.
/*
Table ID: Parcel.Event
Description: Parcel events.
Lineage: Example input.
Primary key: parcel_id
Schema:
parcel_id: varchar(20)
*/
select 'P-1001' as parcel_id;Python
A class with a read() method. Declare the Table in a module docstring, then return a Spark DataFrame using ordinary Python.
"""Table ID: Parcel.Event
Description: Parcel events.
Lineage: Example input.
Schema:
parcel_id: string
"""
from weaver import Table
class Parcel__Event(Table):
def read(self):
return self.spark.createDataFrame(
[("P-1001",)], "parcel_id string"
)TMDL
A native annotation. Weaver applies modelling conventions through overlays, leaving your authored model files unchanged.
model Model
annotation 'Weaver.AutoHideForeignKeys' = trueDeclarations identify each object and specify its keys, schema or modelling rules.
File paths and naming conventions supply the rest of the structure.
The Catalogue brings everything together
The Catalogue records definitions, dependencies and run outcomes for registered managed items.
Semantic Models · Reports
and installed bindings
installed estate
Catalogue
Fabric Warehouse
Installed definitions
- Definitions
- Signatures
- Dependencies
- Metadata & bindings
Operational evidence
- Bookmarks
- Logs
- Statistics
- Test results
results
The Catalogue is an ordinary Fabric Warehouse. Its tables hold the shared state used by Build, Load, Test and Health.
The diagram shows a Catalogue-managed estate. Standalone Power BI deployment can also work without a Catalogue.
From declarations to execution
- Dependencies
- Coordinate related work across Fabric items.
- Incremental processing
- Bookmarks, row changes and deletes.
- Concurrency
- Run independent work together.
- Fault tolerance
- Record failures without losing completed work.
- Tests & Assumptions
- Check the data, not just the execution.
- Modelling conventions
- Apply standards across Semantic Models.
Weaver generates loading machinery, resolves supported dependencies and applies declared validation and modelling rules.
Python imports and supported T-SQL references establish dependencies; Spark SQL needs explicit declarations. Incremental policies use bookmarks and authored change/delete logic, not automatic detection of every source change.
One operating model
- BUILDInstall the definitions.
- LOADProcess data and refresh models.
- TESTVerify the results.
- HEALTHSee what needs attention.
MIRROR — Develop against existing data without copying everything.
WIPE — Destructively reset selected physical destinations.
Reports are Build-only, with no independent Load or Test. Mirror borrows Lakehouse/Warehouse data. Wipe includes unmanaged contents within selected Lakehouses/Warehouses and normally the resolved Catalogue; named Semantic Model resets retain it. Reports cannot be wiped.
One project. Different environments.
Development
Warehouse/CuratedCurated_DevProduction
Warehouse/CuratedCuratedSame source. Different physical destinations.
Workspace configuration selects destinations; Build records the installed bindings. Changing configuration alone doesn't move installed objects or rewrite arbitrary external connections.
Run Weaver from desktop Python, inside a Fabric Notebook, or both.
Source files and installed work
This separation distinguishes what the project declares from what Fabric has installed.
Recorded outcomes show what has actually happened since.