Reverse index: every change touching one exact identifier — a CVE id, CRD, feature gate, flag, metric, config field, or dependency. Case-insensitive. Call this when you have a specific identifier (e.g. from a manifest or advisory) and want to know what changed around it.

Check the user's running component versions against known changes. Versions are compared INSIDE THIS SERVER PROCESS — only project slugs are sent upstream, and this tool never calls the server-side /v1/upgrade endpoint. Run the server yourself and running versions never leave your infrastructure; on the hosted endpoint they transit server memory only and are not logged. Returns, per component, the changes from releases NEWER than the running version (the upgrade path). Default is a briefing: summary (new_changes, distinct_matters, by_severity, by_family, by_bucket), then the items split by what the caller must do — action_required applies to everyone, check_config applies only if its applies_if holds against the running configuration (resolve it before recommending; an unmet condition is not a reason to upgrade, it is a precondition for later — the entry's version is the minimum to be on before enabling that feature). The split comes from the server's bucket field, the SAME rule the website and the weekly email use. Repeat appearances of one matter_key (the same issue fixed on several release branches) collapse into one entry, and same_matter_also_addressed_in names every other release on record that carried it. Branch-aware: a matter already fixed at or below the running version ON THE RUNNING BRANCH is excluded (the install has it), counted in note — so a backport visible on a newer branch is not reported as outstanding work. Line-aware: a repository can publish separate products or channels (containerd api/, Flatcar lts vs stable, openfeature flagd vs core) and there is NO version order between lines, so only the line your version belongs to is compared — pass the tag as published, prefix included ("flagd/v0.16.1", "lts-4081.3.9"), or the wrong line is compared. Pass version_source per component (where you read the version — e.g. a daemonset image tag, or that the user stated it): it is echoed back as an audit trail. This server cannot see your environment, so it cannot verify a version or its source; a running version older than every release on record is flagged in note, which is the only cross-check available here. Use detail:"full" for every change verbatim in relevant_changes (capped at 50 per component with relevant_changes_omitted — narrow with severity_min or target_version), target_version to limit to one upgrade hop, severity_min to filter. Components with zero changes carry tracked:true|false — tracked:false means the project is NOT covered by ratatosk, so the absence of changes is no-coverage, not safety. Drill down with get_release or changes_by_entity.

Every release in which one matter appeared, oldest first. Take matter_key verbatim from a change (case-sensitive, contains '/' and ':'). Use it to answer 'which version fixes this for MY branch' and 'have I already handled this'. Why every occurrence and not just the newest: the same containerd security roll-up landed on five branches carrying 2, 4 and 10 advisories respectively — told only the newest, someone on the 2-advisory branch would assume they were fully covered. Set include_all for the routine record too (mostly bot dependency bumps).

One reviewed release: envelope (summary, source URL, release URL) plus all its changes. changes=[] means the release was read and nothing operator-facing was recorded — auditable silence, not a gap. Each change carries family (security|breaking|deprecated), actionability, bucket (act now / check first / plan ahead), a machine-evaluable applies_if, cited advisories with CURRENT severity, and the verbatim quote it came from. by_bucket/by_family/max_severity summarize the same set; notes_total counts routine entries not shown individually. Omit version for the latest reviewed release of the project. version is accepted with or without the leading 'v' (projects disagree on the spelling); a wrong tag returns an error listing the project's recent reviewed tags — retry with one of those. Set include_raw for the original release note body (raw_notes).

Incremental SYNC feed of release changes for CNCF/cloud-native projects. Ordered by seq ascending — OLDEST analyzed first, so a single page is NOT the newest data; page through with since= until next_since comes back null. Built for keeping a local copy up to date. For 'what is the latest release of X' or 'recent releases of X', use list_releases or get_release (omit version for the newest) instead. Filter by project, by family (security|breaking|deprecated — what kind of thing it is) and by bucket (action|check|plan — how to act now). The routine record (bot dependency bumps and the like) is excluded by default. Two fields matter most: applies_if tells you whether an entry is yours to act on — when its targets are present, look them up in the running configuration instead of parsing the sentence; matter_key is the identity of the underlying matter across releases, which get_matter expands.

Every project ratatosk tracks: slug (the canonical id all other tools take), name, tier (graduated|incubating), category, analyzed_releases; image_aliases where a project runs under other names in clusters (an image or workload matching an alias belongs to that project at the version its tag says), and cluster_core:true on the cluster substrate (control plane, datastore, DNS, runtime, CNI/dataplane) — every cluster_core project present in a cluster belongs in its check_stack call. Some cluster_core entries carry a visibility hint (how the component is observed and where it can legitimately be unreadable — e.g. etcd may live outside the k8s API): an unreadable one is reported as unchecked, never guessed. Small response, no arguments — call this FIRST when you are unsure of a slug instead of guessing (a wrong slug shows up as tracked:false in check_stack).

The newest N reviewed releases of one project, as light summaries (version, released/reviewed dates, changes_total, counts by bucket and by family, max advisory severity, notes_total). THE tool for 'recent releases of X' / 'what changed in X lately' — newest first, unlike the list_changes sync feed which walks oldest-first by seq. changes_total=0 means the release was read and is routine (auditable silence). Drill into a row with get_release(project, version) for the full changes.