Understanding the data

Every Ratatosk surface (web, alerts, API, MCP) is a view of the same data. Knowing the structure lets you read all of them the same way.

Release reviews

Each collected release gets one review:

coverage: how much of the source could be read. full_reviewed means the full text was read and judged. When a note is too thin or unreachable, it is honestly marked insufficient and the original text is attached.
assessment: a one-line characterization of the release.
facts: see below. Zero facts with coverage full_reviewed means "read it, nothing notable". That is verified silence, not a gap.

A fact is one verifiable change extracted from the release notes.

fact_type (9 kinds): security_fix, dependency_bump, capability_removed, capability_deprecated, api_version_changed, identifier_renamed, validation_tightened, default_changed, behavior_changed
severity (5 grades): info, low, medium, high, critical
entities: the identifiers a fact touches. CVE ids, CRDs, feature gates, flags, metrics, config fields, dependencies. Made for matching against your own manifests.
applies_if: the condition, when there is one ("only if you use X"). Absent means it applies unconditionally.
references: the verbatim quote and source. Every fact can be traced back to the original text.

The web home and the email alerts use the same criteria:

Security fixes are always shown, regardless of severity.
Beyond that, the focus is on compatibility-breaking changes (removals, default changes, and the like).
The "action needed" window on the web home is a rolling 7 days.

All timestamps in storage, display, and aggregation are UTC. Release dates are the GitHub published time (published_at).

Tracked projects come from the CNCF landscape. The current list and each project's analysis history are at /projects.