SOURCE TRANSPARENCY

Data Sources

Public source families monitored by PulseGate and the types of signals they contribute.

Example surfaces are illustrative only and do not imply affiliation, endorsement, or official integration with PulseGate.

Source family	Example surfaces	Signal types	Typical cadence / latency	Caveats
Official product surfaces	Canonical sites, docs, changelogs, release pages	Identity anchoring, update recency, product presence	Frequent checks, cadence varies by surface	Canonical URLs can shift; sparse pages reduce confidence
App stores and marketplaces	App Store, Google Play, browser stores, plugins	Public listing evidence, category hints, freshness proxies	Periodic refresh with store-specific latency	Store metadata can be stale or generic; categories vary. When a listing exposes the developer's own website, that website becomes the canonical anchor and the store URL is kept as an external identifier.
Registries and package ecosystems	NPM, PyPI, package directories, extension registries	Version/update flow, public release evidence, developer tooling identity	Registry polling and scheduled refresh	Not every registry package qualifies as a listed product
Code hosts	GitHub repositories, GitLab projects	Product anchor when the repo declares a homepage; otherwise the repo URL itself serves as the anchor	Source polling and event-driven refresh	Non-repo URLs (gists, issues, wikis, blob/tree views) are not indexed as products
Topic/event signals	Hacker News, Reddit, RSS/news, official announcements	Momentum, event strength, coverage breadth, confidence	Topic snapshots on rolling windows	Noisy by nature; confidence gates reduce one-source overreaction. Used for momentum scoring, never as the sole canonical signal.
Manual submissions	User submissions via the public submit form	High-priority intake with user-asserted identity	Realtime — picked up on the next indexer tick	Same gates as automated discovery — denylist, dedup, and LLM gate still apply