In a Data Vault warehouse, what separates the raw vault from the business vault?

## The dividing line: hard rules versus soft rules Data Vault draws its layer boundary at a precise place — whether a transformation can change the **meaning** of the data. A **hard rule** cannot. Casting a text field to a date or a decimal, trimming and upper-casing a business key so it hashes consistently, computing hash keys and hashdiffs, splitting an inbound record into its hub, link and satellite parts, stamping `load_date` and `record_source`. Applying a hard rule and then reversing your view of it costs nothing, because no interpretation was baked in. A **soft rule** does change meaning. Deciding that the customer in the CRM and the customer in billing are the same person, deriving an active flag from three columns and a date, converting currencies at a chosen rate, mapping a dozen source product categories onto a standard taxonomy, filtering out records the business considers test data. Each of these is a judgement, and each can later be judged wrong. ## The raw vault The raw vault contains hubs, links and satellites populated with **hard rules only**. It is insert-only and nothing is ever deleted, so it is a complete, replayable record of what every source system asserted and when. That gives three concrete properties: - **Auditability.** For any date, you can reconstruct exactly what a source said, and prove it, because the rows are still there. - **Rebuildability.** Everything downstream can be regenerated from it without going back to the source systems — which may have overwritten their own history, or may be gone. - **Source fidelity.** Because satellites are split per source, contradictory sources are both preserved rather than one silently winning. A raw vault deliberately contains data that is, from the business's point of view, wrong: duplicated customers, inconsistent categories, records nobody wants in a report. That is the point. The raw vault records; it does not correct. ## The business vault The business vault sits on top and applies the soft rules. Structurally it uses the same table types, and that surprises people: a business vault contains hubs, links and satellites too, plus the query-assist structures. The typical inhabitants are: - **Computed satellites** — derived attributes such as a standardized category, a converted amount, a scored risk band, or a cleansed address, hanging off a raw hub or link. - **Same-as links** — asserting that two business keys from different systems denote the same real-world entity, which is a mastering judgement and therefore never allowed in the raw vault. - **Point-in-time and bridge tables** — derived, disposable structures that exist purely to make queries against the vault affordable. - **Business-rule links and effectivity satellites** — recording which relationship was regarded as in force over which period. Everything here is **derived and therefore expendable**. Dropping the entire business vault loses no information; it loses computed results that can be recomputed. ## Why the split earns its keep Business rules are wrong more often than sources are. A definition of "active customer" changes; a category mapping turns out to have missed a case; a deduplication rule over-merges two genuinely different companies. With this split, the fix is: change the rule, truncate the affected business-vault structures, rebuild from the raw vault. You do not re-ingest from source systems, you do not need the sources to still hold the history, and the audit trail — what actually arrived, and when — is untouched by the correction. Better still, you can rebuild the business vault as of an earlier date and reproduce a report exactly as it was published, because the raw inputs to the rule are all still there. If soft rules were applied on the way into the raw vault, none of this holds. The interpreted value would be all you have, the original would be lost, and correcting a rule would mean asking the source system for history it may no longer have. ## Where marts fit Neither vault layer is meant to be queried by analysts. The consumption layer — dimensional marts, or whatever the BI tools actually read — is built on top of the raw and business vaults together. In practice that makes three layers, and it is the honest cost of the pattern: the vault is optimized for integration, retention and audit, and something else has to be optimized for reading. ## A common misreading The business vault is not "the clean vault" in the sense of replacing the raw one, and it is not a mart. It is an optional, partial layer: you build only the derived structures that several consumers need, so that the same business rule is not re-implemented in five different marts. If exactly one mart needs a rule, implementing it in that mart is often the better call.