A timestamp snapshot stores successive observations of a mutable record.
The source key stays the same while its plan, status, or amount changes. When updated_at advances, dbt closes the previous version and inserts a new open version. The validity fields let you ask which state was recorded for a particular period.
The update clock is a contract with the source. If a value changes without a newer timestamp, the snapshot can miss it. It also can't reconstruct a state that appeared and disappeared between runs.
Keep one current source row per key before recording history, and exclude records without a usable clock.
In these tasks, the warehouse records a baseline before applying a source update. Your command runs against that existing history, then runs again to check that an unchanged observation adds no extra versions.
{% snapshot subscription_history %}
{{ config(unique_key='subscription_id', strategy='timestamp', updated_at='updated_at') }}
select subscription_id, user_id, lower(trim(plan)) as plan,
lower(trim(status)) as status, monthly_amount, updated_at
from {{ source('pulse', 'subscriptions') }}
where subscription_id is not null and updated_at is not null
qualify row_number() over (partition by subscription_id order by updated_at desc, monthly_amount desc nulls last) = 1
{% endsnapshot %}
The snapshot keeps earlier subscription versions and uses updated_at to close each observed interval.