Skip to main content

Ingestion and the lifecycle: what every downstream layer inherits

Ingestion is the front of the Data 360 lifecycle, and every later layer inherits whatever you landed. The DLO-to-DMO handoff, and how ingestion freshness and correctness feed identity resolution, query, segmentation, and agent-readiness — a stale or wrongly-keyed ingest surfaces as a downstream bug three layers away.

Reference·Last updated 2026-06-01·Drafted by Lira · Edited by German Medina

Ingestion is the front of the Data 360 (formerly Data Cloud) lifecycle, and the lifecycle is a one-way inheritance: ingest → model → resolve identity → query → segment and activate, with the agent reading across all of it at the end. Each layer is built on the one before it, which means each layer inherits the layer before it — including its mistakes. A Data Stream lands a source as a Data Lake Object (DLO) — API names end in __dll — and everything that happens after that is downstream of a decision you made at the very front.

This page is the through-thread of the Ingestion subcategory: not how to configure a stream — that is data streams and refresh modes — but why ingestion is the layer that sets the ceiling on every other one. The argument is simple and it is the reason this subcategory exists: get ingestion wrong and the symptom shows up three layers away, wearing someone else's costume.

The lifecycle is an inheritance chain

Think of the five layers as a chain, where each link can only be as strong as the one feeding it.

INGEST          MODEL              RESOLVE          QUERY / SEGMENT      AGENT
(this           (Data              IDENTITY         & ACTIVATE          (reads
 subcategory)    Architecture)                                          everything)
   │                │                  │                   │               │
 DLO (__dll) ──map──▶ DMO (__dlm) ──unify──▶ resolved ──ask / target──▶ grounded
 raw landing      harmonized        individual    decisions           answers

Nothing in this chain repairs what came before it. Identity resolution unifies the records you ingested; it does not invent the ones you forgot to stream. A query counts what the model holds; it does not recover a field that never landed. An activation ships the segment you built; it does not notice that the profile behind it is a day stale. The lifecycle moves in one direction, and ingestion is its source.

That is the whole reason "the data model is the product" (principle 1) starts at the stream. The model is a contract, but the contract is only as good as what you pour into it — and what you pour in is ingestion's job.

The DLO-to-DMO handoff

The first thing ingestion hands off is the DLO, and the handoff is to Data Architecture, not to a downstream consumer. A Data Stream's responsibility stops at landing the raw object; turning that DLO into a Data Model Object (DMO) — API names end in __dlm, standard ones in the ssot__ namespace — is the modeling step, and it is documented in mapping. This page does not redefine it.

What matters for the lifecycle is the seam. The DLO is what you ingested, in the source's shape. The DMO is what it means, in your business's shape. Mapping is the deliberate translation between the two — which field carries which meaning, what the key is, how objects relate — and it is the first place a downstream consumer ever sees your data. So two things have to be true at the handoff:

  • The DLO has to actually carry what the DMO needs. Mapping can rename, retype, and reshape a field, but it cannot conjure one you never streamed. If the resolved individual needs an email and the ingest never landed an email field, no amount of modeling produces it.
  • The grain and category have to match the modeling intent. Land event data as a Profile stream instead of Engagement (see data streams) and the modeling layer inherits a time series with no timeline — a defect that did not exist at ingestion and cannot be fully repaired after it.

Freshness and correctness flow downstream

Two properties of an ingest propagate through the entire chain: how fresh the data is and whether it is correct. Both are set at the front, and both surface far from where they were set.

Freshness is a feature (principle 6), and it is inherited. A DLO is exactly as fresh as its refresh schedule, and so is everything built on it. A profile is as fresh as its slowest contributing stream; a segment is as fresh as that profile; an activation is as fresh as that segment. A stream that refreshes daily behind a real-time activation is not a stream bug you will find in the stream — it is a latency bug that surfaces as a customer getting yesterday's message, three layers downstream, where nobody is looking at ingestion. The cadence has to match the freshest decision the data feeds, and you have to write it down so the next person doesn't assume real-time where there's a 24-hour lag.

Correctness is inherited too, and silently. The defining correctness decision at ingestion is full refresh versus upsert (see refresh modes). The trap is that a wrong or non-unique primary key on an upsert does not error — it duplicates or overwrites records quietly, and the duplication flows forward. Identity resolution then tries to unify a profile that already has phantom records in it; the query counts them; the segment targets them. The numbers stop meaning what you think, and the root cause is a key decision made at the front that no downstream layer can see.

Trace the symptoms back to the source and the pattern is consistent:

  • Identity resolution produces too many or too few unified profiles. Often the match rule is fine and the ingest is the problem: duplicate records from a bad upsert key, or a contact-point field that never landed, so two real people can't be linked. The resolution layer can only work with what arrived — see the unified individual.
  • A segment counts wrong or runs on stale data. The segment logic is correct; the profile under it inherited a stale or duplicated ingest. The fix is at the stream, not in the segment builder — see building segments.
  • An agent gives a confidently wrong answer about a customer. Agent-ready is a property of the model (principle 10), and the model is a property of the ingest. If a human analyst can't trust the unified profile, neither can Agentforce or an external LLM — and the distrust traces back to whatever the front of the lifecycle let through. The agent is just the most demanding reader of everything ingestion decided.

Everything starts here

The practical consequence is a debugging instinct: when a number is wrong three layers down, suspect the front of the lifecycle before you suspect the layer you're standing in. A surprising share of "identity resolution is broken," "the segment count is off," and "the agent is hallucinating" issues are ingestion issues wearing a downstream costume — a stale refresh, a mis-keyed upsert, a missing field, a mis-categorized stream.

That is the thread this whole subcategory hangs on. Ingestion is not a setup step you complete and forget; it is the layer every other layer quietly depends on for the rest of the org's life. Land it deliberately, match the cadence to the decision, name the key, and hand off a DLO the model can actually use — because everything downstream inherits it, whether you designed it to or not.

Related

  • Mapping — the DLO-to-DMO handoff in detail: where ingestion ends and the model begins
  • The unified individual — what identity resolution can and cannot recover from what you ingested
  • Building segments — why a segment is only as fresh and correct as the ingest beneath it
  • Data 360 principles — freshness as a feature (principle 6) and agent-ready as a property of the model (principle 10)

Reference: