Check the user's running component versions against known facts. 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 facts from releases NEWER than the running version (the upgrade path). Default is a briefing: summary counts, then critical/high facts split by whether the caller still has to check something — 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 — fixed_in is the minimum version to be on before enabling that feature). One line each for the rest, and the same advisory fixed on several release branches collapsed into one entry (shown at the advisory's group-maximum severity). 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 fact verbatim (capped at 50 per component with relevant_facts_omitted — narrow with severity_min or target_version), target_version to limit to one upgrade hop, severity_min to filter. Components with zero facts carry tracked:true|false — tracked:false means the project is NOT covered by ratatosk, so the absence of facts is no-coverage, not safety. In brief mode, facts sharing one quoted sentence are merged with their ids listed together. Drill down with get_release or facts_by_entity.

Reverse index: every fact 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.

One reviewed release: envelope (coverage, assessment, source URL) plus all its facts. facts=[] with coverage=full_reviewed means the release was read and is routine — auditable silence. 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); when the review is not the full story (coverage insufficient, or zero facts) raw_notes is included automatically.

Incremental SYNC feed of release facts (typed, entity-level changes: security fixes, removals, deprecations, renames, defaults) for CNCF/cloud-native projects. Ordered by fact_id 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 get_release (omit version for the newest) instead. Optionally filter by project/type/severity. Facts citing an upstream security advisory carry advisory_group_key (the official notice id, e.g. GHSA-… on GitHub; facts citing only CVE ids get a cve:… key) and group_severity — the maximum severity across all releases sharing that key — the group-maximum reading, with per-release severity as the per-release evidence.

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, date, coverage, fact counts by severity, max advisory-group severity). THE tool for 'recent releases of X' / 'what changed in X lately' — newest first, unlike the list_facts sync feed which returns oldest-analyzed first. facts_total=0 with coverage=full_reviewed means the release was read and is routine (auditable silence). Drill into a row with get_release(project, version) for the full facts.