Deep dive: FIG v2 data freshness and release pinning

If you've been following our FIG v2 series, you've already read about the overhauled data catalog and the historical data upgrade that makes your models dramatically more accurate. Today I want to close out the series with something that might sound like a backend plumbing detail—but has real consequences for anyone running production pipelines on Faraday data: how we handle data freshness, and the new release pinning controls that come with it.

How most identity graphs handle updates (and why that's a problem)

To understand why this matters, it helps to know how data updates typically work in the identity data industry.

Most identity graphs operate on a monolithic release model. Providers work with many data vendors, each of whom delivers updated data snapshots on their own schedule. The standard approach is to either wait for all vendors to deliver their latest data, or simply release on a fixed schedule—monthly, quarterly—regardless of when the underlying data actually arrived. Either way, the result is the same: a gap between when data is collected in the real world and when it's available to you.

The obvious problem: every day you spend waiting is another day the data sits there getting older. The release cycle itself introduces latency that has nothing to do with how fresh the underlying data actually was. FIG v2 eliminates that bottleneck entirely.

Rolling releases: freshness without the wait

Now with FIG v2, instead of waiting for a full vendor sweep before publishing an update, we ingest each vendor's data the moment it arrives. Each new observation is processed, normalized, and added to the appropriate attribute's history vector—timestamped, sourced, and immediately available—without waiting for anything else.

The result is rolling releases. Every time even a single vendor delivers updated data, that data flows into FIG v2 right away. There's no more monolithic "release event" to wait for. The gap between when data is collected in the real world and when it's available to you in Faraday shrinks dramatically.

For most attributes, this is just a nice quality-of-life improvement—fresher data, more often. But for certain attributes, it's much more significant. Pre-mover signals, for example, are almost entirely time-sensitive. A pre-mover flag that's six weeks stale is considerably less valuable than one that arrived yesterday. With rolling releases, those high-velocity attributes stay sharp.

Release pinning: you control when freshness flows in

Fresher data is almost always better — but there's a legitimate exception. If you're running a mission-critical pipeline and you've carefully validated the data distributions it depends on, constant rolling updates can feel like a liability. Think an automated risk scoring model at an insurance company, or a lead prioritization pipeline that's deeply integrated into a sales team's daily workflow — cases where an unexpected shift in data distributions could quietly change outputs in ways that are hard to detect and costly to diagnose. If you're in one of those situations (or something similar), you don't want things shifting under your feet without warning.

That's what release pinning is for.

In FIG v2, you can pin any individual pipeline to a specific date. What that means concretely: any new consumer data incorporated into FIG after that date is simply ignored for that pipeline. The pipeline keeps running—against exactly the data it was validated against—until you decide you're ready to move it forward.

The workflow this enables is deliberate and controlled. Say you're running a critical pipeline and a new round of vendor data has just been ingested into FIG. Rather than letting it flow in automatically, you:

1. Make a copy of the pipeline. The copy runs against the newer data.
2. Do your validation. Check distributions, spot-check outputs, confirm that everything downstream still behaves as expected.
3. When you're satisfied, advance the pin date on your production pipeline. The new data flows in. The copy gets retired.

You can do this on whatever cadence makes sense for your team—monthly, quarterly, or whenever a new vendor refresh comes in that you want to evaluate. You get the benefit of fresher data without ever being surprised by it.

For teams that don't need this level of control, the default behavior is simple: data stays fresh automatically, with no manual steps required.

Freshness and stability, on your terms

The two ideas here—rolling releases and release pinning—are designed to work together. Rolling releases make FIG v2 the freshest consumer data platform we've ever built. Release pinning makes sure that freshness doesn't come at the cost of predictability for the teams who need it most.

Together, they represent something we think is genuinely new in the market: a consumer data system that treats data freshness not as a fixed property you accept or reject wholesale, but as a dial you can tune per-pipeline based on your actual operational needs.

If you want to learn more or start testing these capabilities in your account, reach out to your account management team. And if you missed the earlier posts in this series, you can catch up on the data catalog deep dive, the historical data deep dive, or the freshness and release pinning deep dive on our blog.

And if you're new to the platform, reach out to talk to a context consultant to see what FIG v2 can do for your data.