Catalogs age in public. A card can still look current—logo, value, green status—after the provider has changed the tier, closed the form, or moved the program behind a partner. The failure is not that snapshots exist. The failure is treating the snapshot as a live ledger.
Startup Perk List stores a capture date, a last-checked date, and a review window on the catalog as a whole. Individual cards inherit that freshness. This note explains how to read those dates and what to do when they are old.
Quick answer: A catalog date tells you when Startup Perk List last observed the listing, not whether the provider will still honour it. If the last-checked date is older than your decision horizon, re-open the source before you apply, share company data, or put the amount in a plan.
This pairs with the source-kind checklist and the evaluation workflow. The label definitions live in the methodology.
1. Know which date you are reading
Section titled “1. Know which date you are reading”Startup Perk List uses more than one clock. They answer different questions.
| Date | Question it answers | Question it does not answer |
|---|---|---|
| Captured | When the snapshot was taken from the catalog source | Whether the provider still offers that amount |
| Last checked | When someone last opened or reviewed the catalog pointer | Whether your account is approved |
| Review recommended | When the local snapshot should be treated as due for a pass | A promise that a newer check has already happened |
| Provider page date | What the vendor’s own page or terms show today | Nothing about Startup Perk List’s capture |
If a card shows a listed value and only a last-checked date from last month, you have an observation. You still need a provider-page date from this session before the offer can change a budget.
The About this journal page uses the same rule for editorial notes: “last reviewed” is a freshness signal, not a guarantee that a provider page is still available.
2. Decide a review window from the decision, not the badge
Section titled “2. Decide a review window from the decision, not the badge”A 30-day catalog window is a publishing convention, not a physical law. Choose a tighter window when the decision is expensive:
- This week: you will submit an application or add a payment method.
- This month: you are comparing two cloud programs for a prototype.
- This quarter: you are only building a watch-list.
If the last-checked date is older than that window, the status is Historical until re-opened, even if the UI still says “Listed.” Do not wait for the catalog to refresh before you do your own check. The methodology already says readers should open the source, check the visible date or terms, and record the result in their own ledger.
3. Re-open the source in a fixed order
Section titled “3. Re-open the source in a fixed order”When a snapshot is due for review, do not start by editing the headline value. Re-open the destination:
- Confirm the host still matches the listing.
- Confirm the page still describes the named program.
- Copy current eligibility, expiry, and route language.
- Compare that language to the snapshot fields (value, duration, condition, source kind).
- Write one of: unchanged, changed, or gone.
If the host changed from a provider page to a partner form, the source kind changed even if the value string looks similar. Use the source-kind article to re-label the record.
If the page is gone, keep the old row as Historical and add a close-out note. Deleting the evidence makes the next person repeat a dead search.
4. What “stale” should change in your ledger
Section titled “4. What “stale” should change in your ledger”Stale does not automatically mean “reject.” It means the catalog is no longer sufficient evidence.
| Snapshot state | Ledger status | Next action |
|---|---|---|
| Last checked inside your window and source still matches | Verifying or applied | Continue the normal handoff |
| Last checked older than your window | Verify | Re-open the provider route before any submission |
| Source kind or host changed | Verify | Re-classify the destination |
| Program page gone or replaced | Closed / historical | Keep the URL and date; do not recycle the value |
Never “refresh” a stale card by copying a newer number from social media. The new number needs its own URL and date.
5. Catalog maintenance is not your approval
Section titled “5. Catalog maintenance is not your approval”Startup Perk List’s review window exists so the index does not pretend to be a live provider API. A future catalog update may change last-checked dates without changing your account. Conversely, your account can be approved while the public snapshot is still old.
Keep those clocks separate in the tracking ledger:
- catalog last-checked date;
- date you opened the provider page; and
- date the provider confirmed your account, if they did.
Only the third date can support a spend plan.
Evidence, boundary, and last verified
Section titled “Evidence, boundary, and last verified”Evidence. This article describes how Startup Perk List’s capture and last-checked dates should be read. It does not assert that any named provider program is currently open. See the methodology and source policy.
Boundary. Dates in the catalog are editorial observations. They do not extend, renew, or revoke a provider benefit. Only the provider’s current page and account confirmation decide availability. See About this journal.
Last verified. This freshness workflow was checked against the current Startup Perk List catalog pointer on 2026-08-30 (Asia/Shanghai). Re-open the source on the day you apply.
Final check
Section titled “Final check”Look at the last-checked date on the card. If it is older than the decision you are about to make, open the source now and write today’s date in your own ledger. If you cannot reach a page that still describes the program, treat the catalog value as historical and do not put it in a budget.