Chapter 8: Building Your Library
A reusable schema catalog and institutional knowledge store across all your projects.
Every workbook contains a Library — a central catalog of source and target tables that exists independently of any individual project. Where a project holds the mappings you're actively working on, the library holds the full schema inventory that those projects draw from. A table lives once in the library and can be pulled into as many projects as needed. Schema annotations, historical notes, and indicator values set at the library level travel with the table into every project that references it.
On a single small engagement the library feels like background infrastructure. On a multi-project engagement — or when you're reusing schemas across clients or engagements — it can save considerable time.
The Library Tab
The Library tab is always visible in the tab bar alongside your project tabs. Click it to open the library workspace. It uses a tabbed interface with a Source tab and a Target tab — click whichever side you need to work with. Each tab shows its tables in a tree with a search box at the top that filters the list as you type, useful when the library grows to dozens or hundreds of tables.
Tables in the library are sorted alphabetically by database, schema, and name. Unlike project tables, they cannot be reordered by dragging — position ordering is a project-level concept for controlling report output, not a library concept.
Populating the Library
Right-click anywhere in the library source or target tab and choose Add/Update Tables. The process is identical to importing tables into a project: select a CSV, DDL, or JSON schema file, review the sync manifest, and apply. The library is where DDL and JSON schema files are most naturally imported — they go into the library first, then get pulled into projects from there.
Library-Level Notations and Indicators
Tables and columns in the library support the same Notations and Indicators cards as their project counterparts. Annotations set at the library level travel with the table when it's pulled into a project — a Table Note or Column Note written in the library appears in every project that references that table.
This makes the library a natural home for institutional knowledge. If a particular legacy table has known data quality issues, a cryptic column naming convention, or a business rule that applies regardless of which project is mapping it, that context belongs in the library where it propagates automatically rather than being re-documented in each project separately.
Historical Pattern notations are especially well-suited to the library level. Notes like "In the Meridian Healthcare conversion this table was mapped with the address columns split across two target tables" give future analysts — or your future self — context that a schema definition alone cannot provide. They also feed into the AI modelfile generation covered in Chapter 11.
Bulk Editing Library Items
To update notations or indicators across multiple library tables or columns at once, select them in the library workspace and right-click. Choose Bulk Edit Notations/Indicators…. The dialog works the same way as bulk indicator updates in a project: changes you specify are applied to all selected items; anything you leave blank is not overwritten.
How the Library Works with Projects
The library is most useful when projects draw from it directly. Another way to populate the library is to pull tables up from existing projects — useful if you imported tables directly in early work and want to formalize them in the library now.
In the library workspace, right-click in the source or target tab and choose Pull from Project. A submenu lists available projects. Select one and a dialog shows the project's tables. New tables — ones not yet in the library — can be added immediately. Tables that exist in both places but have diverged are shown separately; a diff dialog lets you review the differences and choose whether to sync them.
Pulling Tables into a Project
The standard way to add a schema table to a project is to pull it from the library rather than import directly. This keeps the table linked to its library counterpart, which enables schema sync later when the source or target schema changes.
From a project's source or target panel, right-click and choose Add from Library…. The dialog shows the library tables available for that side. Select one or more and click Add. The tables appear in the project panel linked to their library originals — Bridger records the library table ID so it knows where to look when syncing column changes later.
Pushing Tables from the Library
You can also push tables from the library into a project directly. In the library workspace, select one or more tables, right-click, and choose Push to Project. A submenu lists your available projects — select the destination and Bridger adds the selected tables. Tables that already exist in the target project are skipped.
Pulling from the project side and pushing from the library side produce the same result. Pull is the more common workflow since you're usually working in a project context when you realize you need another table.
Syncing Project Tables from the Library
When the library copy of a table is updated — because the vendor sent a revised schema and you imported it into the library — the linked project tables need to be brought current. Select the project tables you want to sync using standard multi-select, right-click, and choose Sync Selected Tables…. The sync manifest shows what changed: new columns, modified columns, removed columns. Review the changes, select which ones to apply, and confirm. Column changes are applied to the project table in place; existing mappings on affected columns are preserved.
If you select tables that were imported directly into the project and have no library link, Bridger handles those too. Rather than skipping them, it presents a list of library tables to link against. Select the matching library table, the link is established, and the table proceeds through the normal sync analysis. This means you can import tables directly in early project work and formalize the library link later without losing anything.
Tables that have no library link and are not linked through this process cannot be synced. This is the practical reason to prefer the library-based import path from the start.
What's Next
With the library in place as a stable schema foundation, the next challenge is what happens when that foundation changes. Chapter 9: Dealing with Change covers the full sync toolkit — updating schemas when vendors release new versions, comparing table structures, and keeping projects current with library changes.