What a Satellite Really Is

Ask five Data Vault practitioners how many kinds of satellite there are and you will get five answers. Some count two: hub satellites and link satellites. Some count five and fold in Multi-Active, effectivity, and a Business Satellite. The reason the count never settles is that people are mixing two different questions. One is "what object am I building." The other is "how does this object track change." Those are not the same axis, and conflating them is how teams end up maintaining four nearly identical satellite definitions that differ only in one behavior.

‍

BimlFlex draws the line cleanly, and you can see exactly where in the Object Editor. There are three satellite object types. Everything else people call a "satellite variant" is a column-level setting you toggle on the attributes inside one of those three. That single design decision is why one model can carry a standard satellite, a Multi-Active satellite, and an effectivity-tracked satellite all at once, without ever cloning an object to get a different behavior.

‍

The object axis

‍

When you create a Data Vault object in BimlFlex, the type you pick determines what the object is structurally. For satellites, there are exactly three choices:

‍

• Hub Satellite (in the editor, just "Satellite"): attributes hanging off a hub's business key.
• Link Satellite: attributes hanging off a link, describing the relationship rather than either endpoint.
• Reference Satellite: descriptive attributes for a reference table, the lookup-style data that does not need its own hub.

‍

That is the whole list. A hub satellite and a link satellite are genuinely different objects because they attach to different parents and generate different keys. A reference satellite is different again because it serves a reference table. Three structural shapes, three object types. This is the same set the broader BimlFlex object model exposes alongside hubs, links, point-in-time tables, and bridges, which we walk through in the complete guide to modern Data Vault development.

‍

What is not on that list is telling. There is no "Multi-Active Satellite" object type. There is no "Effectivity Satellite" object type. There is no "Business Satellite" object type. If those were structural shapes, you would expect to pick them when you create the object. You do not, because they are not. They live on the other axis.

‍

The change axis

‍

Open the columns of a satellite and each attribute has a Change Type. That dropdown is the second axis, and it controls how BimlFlex treats the column when it generates load logic. Most columns are ordinary tracked attributes. But a handful of change types turn a plain satellite into what the methodology books call a different "variant," purely by how the generated SQL behaves.

‍

The Multi-Active behaviors are change types, not object types. A satellite becomes Multi-Active because one or more of its columns carry a Multi-Active change type, and BimlFlex supports both flavors:

‍

• Multi-Active Row: each active record is its own row, the row-based intra-day pattern where a customer can have several concurrent phone numbers, each a separate satellite row keyed by a subsequence.
• Multi-Active Set: the whole set of active values is loaded and compared as a unit, so a change to any member re-versions the set together.

‍

Both are columns settings. You do not build a "Multi-Active Satellite"; you mark the columns that make it multi-active. That is why a single satellite can be Multi-Active on the attributes that need it and conventional on the rest, with no second object to keep in sync.

‍

Effectivity works the same way. Link effectivity, the pattern that tracks when a relationship was true rather than just when you loaded it, is not an object type either. It is assembled from change types you place on the relevant columns:

‍

• A Driving Key change type marks the column (or columns) that define the grain the effectivity tracks, so end-dating closes out the right prior record when a relationship changes.
• Effective Date change types, including the low- and high-marker variants, carry the business-effective timeline that the generated logic uses to open and close records.

‍

Set those, and BimlFlex generates an effectivity-tracked link satellite. Leave them off, and the same structural object is a plain link satellite. The structure did not change. The change types did.

‍

Why the split matters

‍

This is not a vocabulary nicety. The object-type-versus-change-type split is what makes the model composable.

‍

Picture a customer hub with a satellite that holds name and address (ordinary tracked attributes), phone numbers (Multi-Active, because a customer has several at once), and a marketing-consent flag whose history you care about to the day. In a tool that models each behavior as its own satellite object type, that is three satellites to define, name, relate, and maintain, and three places to make a mistake. In BimlFlex it is one satellite object with three columns set to three change types. The behaviors compose on the columns; the object stays singular.

‍

It also means changing your mind is cheap. Decide that phone numbers should be Multi-Active Set instead of Multi-Active Row, and you change a column setting and regenerate. You are not migrating data between two differently-shaped satellite objects. The same property holds when you push the model at a new platform: the change types are part of the metadata, so the regenerated load logic carries the behavior to Snowflake, Databricks, or Fabric without a remodel, the same way the keys hold up in the fastest Snowflake Data Vault and across the Databricks generation path in metadata-driven Data Vault acceleration.

‍

And it clarifies a long-running source of confusion. A "Business Satellite" is a methodology idea: a satellite carrying soft-rule or computed attributes that live in the Business Vault. It is not a fourth object type, and you will not find it in the type picker. It is a regular satellite whose columns happen to hold derived values. Same axis lesson: the object is a satellite; what makes it "business" is what is in it, not a different shape.

‍

How to count satellites

‍

So the honest count is three satellite object types, plus Multi-Active and effectivity expressed as column-level modes. Not five types. The "five variants" framing is convenient marketing shorthand, but it does not survive contact with the actual model, because it counts two behaviors as if they were structures.

‍

If you have only ever worked in a Data Vault 1.0 tool, this distinction can feel academic, but it is exactly where 1.0 and 2.0 part ways. Multi-Active satellites and driving-key effectivity are canonical DV 2.0 patterns, and a tool that treats them as toggles on a satellite rather than as separate objects is a tool that actually implements the semantics rather than approximating them. Once your satellites are modeled this way, the downstream delivery follows the same composable logic, which is the through-line in delivering data from a Data Vault.

‍

The next time someone asks how many satellite types there are, you can give the answer that holds up: three objects, and a set of column modes that do the rest.