Business Modeling

What it is

Most teams keep their business model in a slide deck and their physical data model in code, and the two drift apart within a quarter. DeltaVault puts the business model on a live diagram inside the catalog itself. Entities, attributes, and relationships are real metadata, not boxes in a drawing tool. You add an entity by double-clicking the canvas, draw a relationship by dragging between nodes, and every change lands in the same versioned metadata that drives the rest of the platform.

The modeling surface goes both directions. Going down from the business: an AI-led discovery interview uses the organization’s own event and concept categories (the category methodology the organization defined) to find the events and the concepts and relationships between them, proposing the result directly onto your diagram as pending nodes you accept or dismiss one at a time. Going up from the source: right-click a source table and a deterministic engine decomposes it into a Data Vault 2.0 model of hubs, links, and satellites, which you refine on a dedicated canvas before anything physical is created. And when you would rather start from business stories than from a blank diagram, a guided modeling workshop interviews you in plain language and builds the model for you to review.

The AI reasons in the organization’s own category lanes (event versus concept, with an Other lane for everything that does not fit) rather than in a fixed, hardcoded methodology, so discovery proposals reflect the language and classification choices the organization has made. The model is not a drawing you keep beside the warehouse: it binds to the source tables and columns that realize it and reports live coverage, covered under governance and ontology.

In the free edition

Included, and this is the free edition’s centre of gravity. Diagram-first business modeling is what the free edition is for: entities, attributes, relationships, the canvas, the discovery interview, the category methodology, and branches with git sync to version it. None of that is held back. It all lives at organization level, under Business in the global rail.

Not included: projects and workspaces. A workspace is a selection of catalog tables, so a free organization has nothing for one to hold. Its models, entities and glossary live at organization level rather than inside a project, and the scoped Models and Entities pages that a project or a workspace carries on a paying tier are not there. A paying core organization has both.

Not included: the Data Vault Accelerator and the Data Mart Accelerator. Accelerating a source table into hubs, links and satellites, and seeding a dimensional model from a staged table, both belong to the physical half of the product. They read and write real tables and columns, so they need a populated catalog, which the free edition does not have. Both sit outside every paying tier today as well.

How it works

Model directly on the diagram

The relationship diagram is the working surface for business modeling, not a read-only export. Double-click empty canvas to create an entity where you clicked. Drag from a node’s connect handle onto another entity to create a relationship: name the role it plays, add a definition if you want one, and confirm the foreign-key attribute name DeltaVault derives from the target’s business key. Click a node to open its detail sheet and edit attributes (business and technical names, descriptions, identifier flags, data types), synonyms, parent concepts, and tags. Node positions persist, so the arrangement you made for last week’s review is still there this week.

Entities that decompose into parts fold up on the canvas. Mark Order Header and Order Lines as part of Order and the diagram draws them inside one collapsible container: expand it to work on the members, collapse it to a single node with a “contains N” badge that re-routes and counts the relationships passing through. Grouping is real metadata on the entity, not diagram decoration, so every model that shows the family shows the same structure, and it works for hub-and-satellite shapes like Customer with its address, detail, and PII satellites just as well as for header-and-lines transactions.

Entities carry both a business face and a technical face throughout. A relationship between two entities is an attribute reference from the moment you draw it, rather than a concept-level link you pin to an attribute pair later: the referencing entity receives a foreign-key attribute derived from the referenced entity’s business key (role-nameable, reusable), and every entity is born with a convention-named business key attribute to anchor it. Duplicate names are allowed on purpose, because real businesses have synonyms; the model records which name is canonical instead of forcing a fight.

Relationships are not limited to pairs. A business action that involves three or more entities is a first-class multi-entity natural business relationship: it renders as a junction pill with a spoke to each participant, selecting the pill labels each spoke with that participant’s verb, and a detail sheet edits the participants, their verbs, and the relationship’s definition in one place. Existing multi-entity relationships are read and edited that way; the canvas carries no gesture for drawing a new one.

Organize by domain and model

Business opens directly on a models grid. Domains group the grid as rows you expand or collapse (“Fares”), with models nested beneath (“Fare Management”) and submodels nested beneath those. A domain is a first-class, openable row, not just grid chrome: click its name, or choose Open from its row menu, to reach the domain’s own detail page. Rename, archive, and add a model to it stay on the same row menu. A domain no longer exists only as a side effect of creating a model in it: a New domain control at the top of the grid creates one directly, on its own, and takes you straight to the new domain’s detail page, empty and ready for its first model. Clicking a model or submodel instead opens that model’s own detail page.

A model’s detail page carries five tabs: Details (name, domain, kind, status, comment, AI context, and the projects and workspaces the model is used in), Canvas (the relationship diagram, or the star-schema canvas for a dimensional model), Entities (the model’s own member entities, with search, filter, sort, and bulk-edit), Glossary, and Map & Match. Glossary and Map & Match both scope to the model: the glossary lists only the attributes that belong to the model’s member entities, and a Map & Match run launched from the model offers only its member entities as match candidates and marks each already-mapped table as inside or outside the model.

A domain’s detail page carries three tabs: Details (name, status, comment, AI context, an entity count rolled up across every model and submodel in the domain, the list of models in the domain, and a read-only rollup of the projects and workspaces those models are used in), Entities, and Glossary. The domain’s Entities and Glossary tabs are read-only aggregates across every model and submodel it contains, the same information each model’s own tabs show, gathered one level up. Canvas and Map & Match stay per-model: a domain mixes relational and dimensional models, so one aggregate canvas is out of scope, and a Map & Match run needs a single target model.

For a view across every model at once, Business also has an organization-wide Entities view: a catalog-style tree of domains, models, submodels, and entities on the left, plus an Unassigned bucket for entities that belong to no model yet, with the selected entity open in a detail pane on the right. Bulk editing stays on a model’s own Entities tab; the organization-wide view is for finding and inspecting, not for bulk changes.

Business modeling is one model library for the whole organization, not a separate copy per project: one models grid, one set of model detail pages. Projects and workspaces get their own scoped versions of that models grid and that organization-wide Entities view: a Models tab and an Entities tab, inside a project or a workspace, show only the models that hold membership there and the entities that belong to those models. Membership works from either end: add or remove a model directly from the scoped Models tab, or open the model itself and manage the same membership from its “Used in projects & workspaces” section on the Details tab. Click into a model or a domain from a scoped tab, and DeltaVault keeps you in that project or workspace, breadcrumb included, rather than dropping you back into the organization-wide view; what you land on is the exact same model, because scoping narrows which rows you find, not what a model contains. Glossary, Map & Match, and the modeling workshop stay organization-level no matter where you’re working. The dimensional build pipeline still resolves a project’s generated artifacts through these same memberships, so keeping them current is more than a navigation convenience.

If you’re starting from nothing, Ask AI can propose a full two-level domain-and-model structure for your organization; you review it as a checkbox tree, keep the parts you want, and apply. Re-running it updates what exists instead of duplicating it.

Delete with a cascade preview, not a guess

Deleting shows you exactly what else it will remove before you confirm, a guarantee that spans the business model, the catalog structure beneath it, and the operations and toolkit surfaces built on top of it: an entity’s delete lists its attributes and the source columns and tables that were mapped to them; a domain’s or model’s delete lists its submodels and its project and workspace assignments; a connection’s delete lists every catalog, schema, table, and column discovered under it; a project’s or workspace’s delete lists the model and table links it would clear, with the project’s own default workspace going along with it; a workflow’s delete lists its tasks and its generated artifacts, and is refused while another workflow that is not itself being deleted still uses it as a sub-workflow (select a whole workflow tree in the grid and it is deleted parent-first, with one checkbox confirming the sub-workflows underneath); a schedule’s delete is refused while any workflow or table ingestion still uses it; a macro’s delete previews how many existing references will stop expanding; and a custom attribute’s delete lists the table and column values it will strip. The preview is computed from the same cascade logic that performs the delete, so what you are shown cannot drift from what actually happens. Deletes that would strand a reference, such as an attribute that is an entity’s business key, a relationship still pointing at it, a project still holding other live workspaces, a workspace that is its project’s default, a workflow still used as a sub-workflow by a workflow that stays, or a schedule still in use elsewhere, are refused outright, with the reason named, rather than left to corrupt the model or catalog silently. Cascade-aware delete with impact preview now spans every creatable metadata kind across the catalog, business modeling, structural, operations, and toolkit surfaces; the branchless administrative surfaces (teams, knowledge, discovery, platform library) get a confirmation guard rather than an impact preview.

Discover with AI

Discovery runs through the Ask AI pane as a structured conversation driven by the organization’s own category lanes. The AI separates candidate findings into event lanes (the units of work the business performs) and concept lanes (the core things the business keeps track of), following the category definitions the organization chose, and proposes the result directly onto your diagram as dashed “ghost” nodes wired into the real model. Accept a node and it becomes a real entity; dismiss it and it’s gone; accept all when the proposal is right. Proposals survive a page refresh and never pollute your entity list until you accept them.

For a stakeholder session, a presentation mode strips the page down to the canvas plus the AI conversation, sized for a projector. Because discovery reasons from the organization’s own category context rather than a generic fixed framework, what the AI proposes reflects the language and priorities the organization already defined.

Run a guided modeling workshop

Discovery answers “what concepts are in play.” A modeling workshop goes further: it turns business stories into a model end to end, through a category-aware multi-step AI session, and applies the result to a target model you choose at launch. You pick a target model, describe how the business works in plain language, and the workshop starts with the nouns: it proposes the concepts the business names, judges for each one whether it belongs in the model you chose, and collects the verbs your stories use to connect them as hints for later. Only once you have settled that list does it work out what actually happens between the concepts you kept. Everything lands in the organization’s own category lanes. A depth setting (Quick pass, Balanced, Thorough) trades thoroughness against time and cost per run. The workshop scopes its discovery to the target model’s own AI context, so proposals stay grounded in what that model already means to the organization, and shows a live, step-by-step progress feed while it works. Every depth tier produces concepts and relationships.

The result lands directly on the target model’s own canvas, not a separate checklist. There is one node per concept the user kept, and everything the workshop worked out about that concept hangs off it: the review groups the proposals under the concept they act on, each unit of work titled by its verb phrase rather than by a bare event name, so a two-concept connection reads as a sentence (“Customer places Sales Order”) and one joining three or more reads as the verb and the concept it acts on (“places: Customer”). A unit of work with three or more participants renders as a junction node labeled with the verb, with a spoke to each participant; a participant that belongs at a finer grain, a product on the order line rather than the order header, attaches to its own anchor instead, rendering as a direct concept-to-concept connection. Every proposed node carries the AI’s reasoning behind it: a note icon marks a node with a reason recorded, and clicking a node, or its note icon, opens its full editors in the right rail, renaming, moving it between category lanes, switching a group between one combined connection and separate connections, editing a participant’s role, and removing a suggestion. A concept the deeper analysis added on its own, a participant that genuinely takes part but never reached the gate, is badged as added during analysis, so the reviewer can always tell their own choices from the workshop’s. Dismissing a node dims it rather than removing it, dashed and still clickable, so bringing it back is one Accept away; dismissing a concept cascades, dropping every relationship that names it as a participant or an anchor along with it. Apply, available throughout review, writes the accepted concepts and relationships to the target model through the same review-and-diff path as every other metadata change, reporting any item it could not apply rather than failing silently.

Attribute and key discovery is an opt-in pass on the same run: turn it on at launch and the workshop also reads the stories for the facts recorded about each concept it kept, proposing them as business attributes you accept or drop one by one, while apply gives every entity it materializes the organization’s derived business key and carries that key across each connection it creates. Keys are never chosen by the AI: they follow the organization’s own key pattern, an entity that already has a key keeps it, and the review panel previews both the key name and where each connection’s key will land using the very same functions apply runs.

The workshop’s own explanation is always one click away, in the right rail: whenever no node is selected, the rail shows a review summary with a plain-language overview of the proposed model as a whole, the recommended connection shape for anything more than a simple pairwise relationship and why, the open assumptions worth double checking before you decide, how many concepts the gate left out, and the discovery steps that produced the run. Reasoning about a particular unit of work lives with that unit: a node that carries one shows the note icon described above, and opening it shows the reasoning beside its editors. This explanation runs at every depth tier and in every workshop mode, and refreshes on request if you keep editing after it was generated.

A chat pane sits in the same rail throughout review, not just during discovery. Ask it why a concept takes part in this unit of work, or why a relationship was proposed as one combined multi-entity connection instead of separate pairwise ones, and it answers from its own explanation and reasoning without changing anything. Ask it to change something instead, editing a relationship’s verb or direction, adding or removing a participant from a multi-entity group, flipping a group between its combined and pairwise shapes, or reversing an accept or reject decision, and it makes the edit, staged like every other proposal change until you apply.

Discovery is scoped, not indiscriminate, and the scoping decision is a single one. After the concepts are gathered, the workshop pauses at a concept gate: every concept is listed under its category lane, the ones that fit the target model come pre-checked, and the ones the AI judged to belong to another model come unchecked with a note that usually names where they likely belong and why. Each row can be renamed, moved to a different lane, or dismissed, anything the workshop missed can be added by hand, and each row carries the verbs the stories used to connect it, as context rather than a second decision to make. Deep analysis runs only on the concepts you keep, and a multi-model run shows how many AI calls that will take before you commit. Three launch-time context switches (the model’s own context, the things already on it, and a digest of your other models) keep proposals anchored to the estate instead of duplicating it.

A unit of work with three or more participants saves as a named relationship group, a junction with a spoke to each participant; a unit of work with exactly two participants saves as a plain verb relationship instead. Each unit of work carries its own switch choosing the saved shape: the named group, or its equivalent set of separate pairwise connections, previewed before you decide. Accepted groups land on the model canvas as a junction pill with a spoke to each participant, each participant’s verb visible when you select the pill, editable in a dedicated detail sheet.

The workshop also meets you where your material already lives. You can dictate the business stories by voice instead of typing them, attach a document the workshop reads for that one run without ever storing it, and point the session at already-curated knowledge-base documents: the launch form offers your organization’s documents plus those of every project the chosen model belongs to, and picking documents means the workshop reads those and only those, replacing its automatic knowledge search for that run. A document too long to read in full is named on the finished run rather than silently skimmed.

Discovery can also run as a lineup rather than as a single model. Where an organization enables multi-model mode, several models discover independently, a judging pass merges their results into one proposal set and states a reason wherever they disagreed, and an agreement signal on each proposed item shows how many of the lineup’s models put it forward. Single-model mode stays the default everywhere else.

Classify across methodologies at once

The category set the organization defines is what the AI uses across every modeling surface, in the organization’s own terms rather than a fixed methodology. DeltaVault ships a curated library of categories and supports two modeling approaches that group them into archetype families: Ensemble Logical Modeling, a coarse set of five (Event, Party, Place, Thing, Other), and Nine-Pillar, a finer set of ten (Party, Party Role, Product or Service, Agreement, Event or Transaction, Place or Geography, Resource or Asset, Classification or Reference, Document or Communication, Other). An organization shapes its own active set through one guided wizard: start from one of the two approaches, then optionally pick an industry, then tune the result. When starting from an approach, an organization can also pick one of five industry sector variants (Regulated Finance and Insurance; Retail, Consumer Goods and E-commerce; Manufacturing, Supply Chain and Logistics; Healthcare, Life Sciences and Human Services; Energy, Utilities and Telecommunications) that re-skin the archetype labels and AI guidance with industry terminology, without changing the archetype structure or the category mapping. Whether a model renders as a relational diagram or a dimensional star schema is an explicit per-model choice, not a fixed methodology. Each category is more than a label. The organization classifies it as an Event or a Concept, assigns the interrogative it answers (who, what, where, when, why, or how), and writes an AI context in its own words. That AI context is read by the modeling and workshop skills when they analyze user input, so the AI reasons in the organization’s own terms rather than generic ones.

A single entity can belong to more than one classification simultaneously, because classifications are independent tags: the same Customer entity can carry classifications from different modeling traditions at once. Teams name categories however they like (a healthcare team can classify by Patient, Encounter, and Provider) and are never locked to any one external framework.

The dimensional paradigm gets its own canvas with the two concepts diagramming tools usually fumble: role-playing (drop the Date entity twice and name the instances OrderDate and ShipDate) and attribute absorption (a Customer dimension absorbs City, State, and Country from a related Address entity). A dimensional materialiser turns those models into star-schema definitions for Databricks, with conformed dimensions emitting identical column definitions wherever they appear.

Draft any field with AI

Wherever DeltaVault asks for prose, the field can draft it. Descriptions, comments, definitions, and the per-category AI context share one AI-assisted field: double-click it, or select its sparkle control, to open a larger editor, then have the AI draft from scratch, improve, or shorten the text, or give it a free-form instruction in plain language. Every suggestion is shown for review and applied only on confirmation, so the AI never overwrites what a user wrote. The same field is used for single-line inputs and multi-line notes across modeling, the catalog, connections, operations, and administration, so AI help reads and behaves identically everywhere it appears.

Govern modeling conventions in one place

The decisions that shape a model live together in one org-governed place: a Conventions section in Settings, under Business, holds the category catalogs, the business-to-technical naming convention, and the methodology, instead of scattering them through global settings. The naming convention derives every technical name from its business name with per-object casing, optional prefixes and suffixes, a length limit, and abbreviation rules, so a business “Customer Order” becomes a technical “CustomerOrder” or “customer_order” without anyone typing it twice. While a modeler works, the technical name follows the business name and only stops once they set one deliberately, and the same convention drives the “generate technical name” action and the create-time fill, so names stay consistent across the model rather than being policed by hand. A single administrator lock covers all three areas: locked, only administrators change the conventions and everyone else works against them read-only; unlocked, the default, any editor can adjust them. The lock is independent of branch read-only, so locking governs the conventions without freezing day-to-day modeling.

Accelerate a Data Vault from your sources

When a project has a Data Vault catalog assigned, right-clicking a staging-layer table (a Stage or Persistent Stage table) on the workspace canvas offers a Data Vault action that opens the modeling canvas in the canvas area, with an AI assistant a click away. The chosen source seeds the model: a deterministic engine reads the metadata the catalog already holds (business keys, reference columns, change tracking) and seeds the decomposition: business keys become hubs, references become links, descriptive columns become satellites, with hash keys and audit columns generated to your configurable naming conventions. From a hub you can include related tables in one click, following the source’s reference columns to pull in and accelerate the tables it points at. Before it decomposes, the accelerator makes sure each source carries a business name (a linked business entity or a typed-in name) and offers to apply that name across the related ingest chain; the generated hubs, links, and satellites are then named from the business name through those same configurable naming conventions, so the model reads in business terms rather than physical table names. Re-running it reconciles instead of duplicating, so the model accretes as you accelerate more sources.

A staging table carries at most one designated business key: a single column the Data Vault hub keys on, either an existing column that already identifies the row on its own or a derived column DeltaVault builds at the Staging layer by composing several columns together. You set the designation from a dialog on the table’s Details tab, in one of two modes: pick an existing column, or build a derived key from several columns, each with its own transform (a cast, a trim, a macro call) and an explicit order, joined by a separator that seeds from your organization default and is then stored on the designation itself. The dialog previews the exact concatenation and hash expression before you save, so what you see is what gets built, not an approximation. Because a hub cannot key on nothing, the accelerator enforces the designation rather than assuming one: right after the business-name prompts and before the model is generated, it walks every hub-shaping staging table through the same dialog, one at a time, with no skip, and canceling aborts the whole acceleration run rather than leaving a hub keyed on a missing value. External callers, such as an import or an API-driven acceleration, are held to the same rule.

A table’s primary key works independently of its business key designation and keeps its own long-standing mechanics: DeltaVault tracks the explicit order its columns combine in, editable from a key editor dialog on the table’s Details tab, where you pick membership and order in one step, reorder by drag or by button, and see a live preview of the exact concatenation and hash expression before you save. Both dialogs, the primary key editor and the business key designation dialog, carry the same safeguard: if the key already feeds an accelerated Data Vault model, an explicit warning appears before you save a change that would change its hash values, because DeltaVault does not reload materialized tables for you.

Multi-hub links resolve their hash keys deterministically. For every source table feeding a link, DeltaVault stages one hash key column per hub the link connects, named after that hub (customer_hk, order_hk under the default naming pattern), plus the link’s own hash key column named after the link itself. Each per-hub column has to carry the value the hub itself was keyed on, so rather than re-key by hand, DeltaVault re-instantiates the parent hub’s designated key definition on the link’s own columns: it rebuilds the composed expression, in the hub’s order and with its separator and transforms, over the link table’s aligned foreign-key columns, so the link’s hash matches the hub’s exactly. The link table then selects those staged columns directly, so a link with more than one hub renders correct, runnable SQL end to end rather than merely being modeled, and hub and satellite tables keep the hash key column name they have always used. If a link’s foreign-key columns cannot be aligned to the parent’s key, the build fails loudly instead of emitting a mismatched key. Two validation checks watch key integrity as the model evolves: a warning when a column’s flags disagree with the table’s stored keys, covering both a primary-key column out of step with its stored order and a business-key designation that is unflagged, multiply flagged, or dangling, repaired by rebuilding the primary key order from the flags and re-syncing the business-key flag to the designation; and a check naming any foreign-key column DeltaVault could not align to a referenced table’s key order, surfaced without blocking the commit. A missing business key designation is reported only once the table actually feeds a Data Vault hub, so a source, landing, staging, or persistent staging table that never reaches a vault carries no key advisory at all.

Seeding is the boring part, so the machine does it; the judgment calls are yours. Unify two links into one unit of work, or split one back out. Reclassify a link as hierarchical or same-as. Convert a hub into a link or a link back into a hub, a change DeltaVault blocks and explains when it would orphan an inbound link or leave a link with only one hub. Split a satellite’s columns apart by subject, merge satellites, exclude columns, or re-parent a satellite from a hub to a link. Set a satellite’s variant, choosing among effectivity, multi active, status, and record tracking. Mark which hub references drive a link, so the driving key lives on the link rather than on a satellite. Edit a hub’s business key after acceleration, adding, removing, or reordering its parts. Carry a link’s degenerate and transactional columns directly on the link as its dependent child columns. Delete is a suppression rather than a destruction: a suppressed object drops off the canvas behind a Show suppressed toggle and restores in one click, and DeltaVault refuses to suppress anything a live point in time, bridge, or business object still references. Hubs implied by a reference to a not-yet-accelerated source appear as dashed stubs behind a toggle, and unify with the real hub once that source arrives.

Every one of these edits is recorded as a remodeling override, so the next time you accelerate that source to pick up a new column DeltaVault re-derives the rote shape but honors your overrides, and your remodeling choices carry forward instead of being clobbered. Each of these operations is available two ways, by direct manipulation on the canvas and by asking the canvas AI assistant in plain language (“combine the customer links into one unit-of-work link”); both paths run the same underlying operations. Your manual arrangement of the canvas is saved and restored between visits, and clicking around never reshuffles your layout.

Nothing physical exists until you materialize. Materialization turns the accepted logical model into real tables, columns, and source-to-target mappings through the same review-and-diff step every other metadata change goes through, promoting any remaining stub hubs to real key-only hubs on the way.

The load code for these objects is now generated for Databricks Lakeflow: hubs and links as insert-only streaming tables, and satellites as insert-only loads that compare each arriving row against the current one and write a new version rather than updating in place, so the full history is kept.

The data mart layer has its own entry point. In a methodology that models a data mart layer, right-clicking a Stage table, a Persistent Stage table, or a vault hub, link, or satellite on the workspace canvas offers a Data Mart action: it opens a New data mart dialog, prefilling the name from the selected object and asking which domain to place it in, then creates a dimensional business model that records the selected object or objects as its source scope and takes you straight to that model’s own canvas. A mart does not require the vault as its source: on a staging-layer table the menu offers Data Vault and Data Mart side by side, so you can seed a mart straight from staging without building the vault first. Seeding here is source-reference only: DeltaVault records what the mart derives from for lineage rather than generating the mart’s dimensions or facts for you, which you design on the model’s own dimensional canvas the same way you would for any dimensional model. That dimensional canvas carries Ask AI as well: Suggest dimensions and facts proposes fact and dimension roles with the grain each fact measures, the links between them, and missing numeric measures, all as reviewable actions you apply individually, and Validate the data mart model reviews grain declarations, dimension conformance, and dimension shape.

Add a business vault, point in time tables, and bridges

Acceleration builds the raw vault, the layer that captures source data faithfully. The business vault sits above it, holding the conformed and computed structures, and DeltaVault derives it straight from the raw layer instead of making you rebuild by hand. Select one or more raw hubs, links, or satellites on the canvas, right-click, and choose Derive Business Hub, Link, or Satellite. The new object records exactly which raw objects it came from, renders as a distinct node with dashed derivation edges back to its sources, and shows that lineage on the diagram rather than burying it in code. Its detail pane edits the derived object’s columns and captures notes on how it was derived. Every business vault object is anchored to raw vault lineage this way; there is no free-standing business object without provenance.

A point in time table reconstructs the state of a hub and its satellites as it stood at any past date, so a query never has to hand-write point in time joins across every satellite. Right-click a raw hub or link, choose Create Point in Time, pick which of the anchor’s satellites to include, and set a snapshot cadence of hourly, daily, weekly, or monthly. DeltaVault generates a date spine across the vault’s history and resolves each satellite’s load-date pointer at every snapshot date; reopen the node to change its membership or cadence. Point in time tables anchor on raw hubs and links.

A bridge table flattens a multi-hop path through the vault into one queryable table, so a report can traverse from an anchor hub out across several links and hubs without stitching the joins together by hand. Create Bridge from a hub walks the link graph outward: it offers the links attached to the anchor (filtered by default to the ones the anchor drives), the hubs on the far side of each, and further hops behind a multi-level control, up to two link hops out. When a path visits the same hub twice, DeltaVault aliases the repeats automatically so the traversal stays unambiguous. The join chain is derived from the model at render time rather than stored as SQL, so renaming a hub or link can never leave a bridge pointing at a stale join. Bridges anchor on raw hubs.

Point in time and bridge tables lean on ghost records to keep their joins clean, and ghost records are gated by a governance setting. Turn it on and the generated load code seeds a zero-key ghost row into each hub, link, and satellite, so a missing match resolves to that sentinel row instead of a null and the point in time and bridge joins stay inner joins rather than degrading to outer joins. Leave it off and behavior is unchanged: the point in time render falls back to outer joins and DeltaVault raises a warning recommending you turn the setting on.

Every operation on this canvas, from deriving a business object to creating a point in time or bridge table, is available both as a direct canvas gesture and as a chat tool the AI assistant runs on request, so you can build the whole vault by pointing and clicking, by asking in plain language, or by mixing the two.

Review a model with AI

Once a business model is built, keeping it honest against changing requirements and governance expectations is ongoing work. Model Review is a dedicated AI operation that runs a structured, multi-pass review of one business model against user-selected Knowledge Base requirement documents plus a standing governance and methodology baseline. It is heavyweight by design: before it runs, the surface shows projected tokens, projected cost, and a rough time estimate, and you must explicitly confirm before the first call fires. The intent is deliberate, not convenient.

The pipeline fans out across seven focused dimensions: requirement coverage (are the selected requirements represented in the model, and where are the gaps?), structural completeness (missing entities, attributes, identifiers, and implied relationships), naming and conventions (adherence to configuration profiles, abbreviation policy, and methodology-layer naming), governance and stewardship (owner and steward presence, classifications on sensitive attributes, definition status), and relationship and methodology integrity (cardinality, orphan entities, methodology-specific shape for Ensemble Logical Modeling / Data Vault / Business Event Analysis and Modelling structures), category conformance (entities left in the Other lane, or whose lane contradicts their name, attributes, or description), and industry coverage (concepts the industry reference expects an organization in your industry to model that this one does not carry, cited to the reference and never presented as required). Each dimension produces candidate findings. Those candidates are then cross-verified by at least two independent model passes: a second model judges each candidate adversarially, defaulting to reject unless the finding is grounded in the model and requirements. Only candidates upheld by a majority of verifiers are eligible for the final report; scoring combines the verifiers’ stated confidence and impact with a boost for findings tied to a selected requirement. The breadth setting (Minimal, Balanced, Comprehensive) controls the score threshold, and a hard ceiling backstops against a noisy run. Code does the scoring, not a model.

The result is a persisted, re-openable report grouped by severity tier (Critical, Recommended, Optional). Each card shows the finding title, the affected entities, the requirement it maps to, and a three-part explanation: what is wrong or missing, why it matters, and what the recommended change accomplishes. The report stays attached to the model, so you can work through it across multiple sessions without losing progress.

Recommendations follow one of two tracks based on their nature. Actionable recommendations carry a concrete proposed change (a field update, a new relationship, or a classification tag), and the Apply path opens the same reviewable, editable preview panel every other AI write in the product uses: you can modify the proposed values before they are applied, and the write goes through the same role checks and audit trail as a human edit. Advisory recommendations are acknowledged or dismissed, with an optional reason; no mutation occurs. Either decision is persisted to the report immediately, so re-opening the report later shows the open versus resolved split exactly as you left it.

Re-running a review on the same model does not resurface findings you already dismissed. The new run computes a stable fingerprint per finding (dimension, affected entities, normalized intent) and suppresses any candidate that matches a dismissed recommendation from a prior run on that model. The report header shows the suppressed count and offers a reveal toggle, so you are never blind to what was hidden.

Why it matters

The traditional path from “the business sells fares” to “here are the hub, link, and satellite tables” is a relay race of handoffs: workshop notes into a slide, slide into a diagramming tool, diagram into a spreadsheet of mappings, spreadsheet into configuration, configuration into tables. Every handoff loses information and every artifact starts rotting the moment it’s exported. DeltaVault collapses the relay into one surface. The diagram is the metadata. The discovery interview writes onto it, the acceleration engine writes onto it, and materialization reads from it.

What you stop doing by hand: re-categorizing source columns into hubs and satellites one spreadsheet row at a time, policing naming conventions across a team, re-drawing the model after every source change, and explaining to each new hire what a unit-of-work link is. What you manage instead: the decisions. Which concepts are core, which links describe one unit of work, where a satellite splits, what gets materialized this sprint. The deterministic engine handles the rote decomposition, the AI proposes within a published methodology, and the review gate means nothing reaches physical metadata without a human reading the diff.

Category contrast

Catalog-first tools that added a chat panel treat the business model as documentation: a glossary you fill in after the warehouse is built, with AI summarizing what already exists. The model never drives anything. DeltaVault’s model is upstream of the physical layer; it’s where new structures get designed and accelerated from.

Code-first transformation frameworks keep the model implicit in code. The Data Vault is real, but it lives as templated SQL spread across files, and the “diagram” is whatever lineage view can be reverse-engineered from it. There’s no surface where a modeler reasons about hubs and units of work before code exists.

Deterministic data-warehouse automation suites are rule engines you decorate: tag the source metadata correctly and the right structures fall out. Powerful, but the inner loop is configuration, and AI, where present, is bolted onto the side. DeltaVault inverts that loop: the deterministic engine seeds, the AI collaborates on the judgment calls in plain language, and both operate on the same visible model.

General-purpose diagramming tools draw pictures. The pictures are disconnected from metadata, carry no methodology, and can’t materialize anything. A DeltaVault diagram is the system of record it depicts.