Can a platform-wide freshness gate prevent expired intelligence from surfacing?

Does an independent close-time check reliably separate actionable contracts from historical observations before public ranking?

Filtering normalized records against a server timestamp, in addition to provider status flags, will exclude passed contracts without deleting their observations.

Provider status fields can lag or differ. A platform-owned freshness gate creates a consistent final safeguard.

• Normalize provider records without synthetic fallbacks.
• Parse each available close timestamp against the server retrieval time.
• Partition passed contracts before ranking and preserve the historical partition for database archiving.
• Test past, future, missing, and invalid provider timestamps.

• Passed close timestamps are excluded before public ranking.
• Future close timestamps remain eligible.
• Invalid provider dates remain visible with provider-quality limitations rather than being silently destroyed.
• The historical schema preserves expired observations for later calibration and backtesting.

• Provider open/closed flags alone may be adequate for providers with strong status guarantees.
• A grace period could be appropriate for some delayed-resolution contracts, but would weaken the live-feed rule.

• Persistent archiving requires the proposed Supabase migration and Preview configuration.
• Contracts without a parseable close time depend on provider open status.
• Resolution outcome ingestion is a later Atlas task.

• An expired contract appears in the public API after the gate.
• Clock skew causes a future contract to be excluded.
• Historical persistence overwrites or deletes prior observations.