Is this the same as a late-arriving fact?

No. A late fact is delayed relative to its business event; an early fact lacks context when it arrives. Both issues can coexist.

Must every early fact be loaded immediately?

No. Waiting is reasonable when reporting requirements permit it.

Does a surrogate key solve missing information by itself?

No. It maintains a reference; the attributes still need resolution and validation.

AI Glossary / Data engineering and architecture / Intermediate

Early-arriving fact

Definition

An early-arriving fact is a measured business event that reaches a data warehouse before its full descriptive context is available. For example, a sale can arrive before the warehouse receives the corresponding new customer's details.

What it means

In dimensional modeling, a fact records activity at a defined level of detail, such as one order line. Dimensions describe that activity through attributes such as customer region, product group and calendar date. These records often come from different systems on different schedules.

“Early” describes the relationship between arriving data, not necessarily an incorrect event timestamp. A valid sale might arrive promptly while its customer context arrives hours later. The problem matters when reports cannot wait.

A report can therefore have complete sales amounts but incomplete regional classification. Hiding the sale would make the total wrong; assigning an invented region would make the breakdown misleading. The loading design must represent the uncertainty honestly.

How it works

First establish the fact's grain and retain its event identifier, source business keys and relevant times. Check whether each required dimension record is available. If the report can wait, holding the fact until its context arrives may be sufficient.

When a new entity has a known business key, another approach creates an inferred dimension member with a warehouse surrogate key and explicitly unknown descriptive attributes. The fact references that member. When the real details arrive, the provisional record can be completed under the chosen dimension policy.

An existing entity presents a different problem: its latest known version might not be the version effective when the event occurred. Later information can require correcting the fact's dimension reference. Filling a new member's missing details must not be confused with overwriting genuine historical changes.

Track unresolved records and reconcile them. A successful load should not make missing context invisible, and receiving a dimension update should not insert the original fact again.

Three practical examples

A retailer receives an order immediately but the new customer registration arrives in a later feed; sales appear with a provisional customer description.
A maintenance warehouse receives a completed job before its new equipment record is loaded; the job remains identifiable while equipment attributes are resolved.
An AI reporting assistant states that part of today's revenue is not yet assigned to a region, instead of treating “unknown” as a real geographical area.

Think of it this way

Think of receiving a parcel before its complete filing card. You can record that the parcel exists and reserve a labeled place for its paperwork. Completing the card later should not create a second parcel.

The analogy stops at record identity. A warehouse also needs rules about historical versions and event time; a simple filing card does not explain which description was valid at a particular earlier date.

Worked example

Keeping a total while resolving its breakdown

In an invented morning load, sales total 1,000 currency units. Of this, 700 belongs to customers already classified by region, while 300 belongs to a new customer with business key C42 whose details have not arrived.

The loader creates one provisional member for C42 and attaches the 300-unit fact to it. The report shows 700 classified and 300 awaiting context: 300 ÷ 1,000 = 30% of sales value is provisionally classified. This percentage measures value, not the percentage of customers or rows.

Later, the source confirms that C42 belongs to the North region for this sale. Completing the provisional member moves 300 from the unknown breakdown into North. Total sales remain 1,000. Inserting the sale again would incorrectly raise the total to 1,300. If later information instead describes a subsequent move to another region, historical version rules must determine the correct assignment.

Illustrative case study

A fictional training provider combines course bookings with organization profiles. New employers can book places before their industry classifications arrive. Initially, a dashboard removes bookings whose profile lookup fails, causing different teams to see different daily totals.

The provider introduces identifiable provisional organization members, displays an unresolved classification count and gives the data team an aging report. A reconciliation job completes missing attributes without duplicating bookings. Records lacking a usable organization identifier go through a separate exception process rather than being confidently matched by a similar name.

The AI assistant describing the dashboard is given the provisional status alongside the totals. It can explain that a sector breakdown may change as context arrives. Reporting revisions remain possible.

Common misconceptions and mistakes

Early means the transaction happened in the future. Usually it means context arrived later than the fact.
One generic unknown record always preserves identity. It may support a total, but entity-specific reconciliation needs retained identifying information.
Filling missing attributes is always a historical change. An incomplete new member differs from a known member whose real attributes changed.
A loaded row is necessarily fully resolved. Provisional context can remain after loading succeeds.

Business use

This pattern matters when operational reporting must be timely despite independently arriving feeds. Define which measures can be shown provisionally and which decisions require resolved classifications. Give reports an explicit meaning for unknown or pending values.

Monitor the number, value and age of unresolved facts; each reveals a different concern. A few large transactions can materially affect breakdowns. Agree who resolves missing keys and how revised classifications flow into dashboards, extracts and AI summaries.

For model training, record the intended time semantics. Information received later may legitimately repair historical descriptions, but using it as though it was known at prediction time can distort an evaluation.

Check your understanding

A new customer's sale is loaded with a provisional dimension member. The customer details arrive tomorrow. Should tomorrow's process add the sale again?

Answer: No. It should resolve the context through the agreed dimension and reconciliation rules while preserving the identity of the already loaded sale.

Related terms

Fact table
Surrogate key
Referential integrity
dimension table
slowly changing dimension
late-arriving data
data lineage

Learn next

Read slowly changing dimensions and fact-table grain. Sketch how your pipeline distinguishes a new entity awaiting details, an existing entity with a historical change, and a fact whose business key is missing.

Fact table

Sources

Ralph Kimball, Design Tip 57: Early Arriving Facts: https://www.kimballgroup.com/wp-content/uploads/2012/05/DT57EarlyArriving.pdf. Primary explanation of provisional dimensional context and subsequent reconciliation.

Kimball Group, Slowly Changing Dimensions: https://www.kimballgroup.com/2008/08/slowly-changing-dimensions/ and Fact Tables and Dimension Tables: https://www.kimballgroup.com/2003/01/fact-tables-and-dimension-tables/. Supporting dimensional-modelling references. Examples and arithmetic are original illustrations.

Previous: Eager learning Next: Early exit