Methodology.

A tool is added when it meets all three of the following: (a) it is in active commercial or open-source use as of the current year, (b) its primary purpose falls within an indexed vertical and cluster, and (c) enough of the schema can be filled from public documentation to produce a complete profile. Acquired tools and archived OSS projects remain in the index, marked with the appropriate status flag, because teams still encounter them in evaluations.

Tools are not added because the vendor requested it. There is no submission process. The selection question — "is this tool relevant to the people using this catalog?" — is answered by the maintainer, not by inbound vendor outreach.

Each vertical is divided into capability clusters that describe distinct buyer problems. The data observability vertical has three: quality & testing (correctness checks), catalog & discovery (asset inventory and search), and lineage & metadata (data flow tracking). The clusters are not strict containers — most real tools span more than one — so each tool has a single primary cluster and a strength score against every cluster in the vertical.

Scores reflect documented capability surface, not vendor positioning. A tool that markets itself as "all-in-one" but only ships incidental features in two of its three clusters scores accordingly.

Each field on a tool profile is sourced from one of: vendor documentation, the vendor's pricing page, the project's public repository, or — where applicable — hands-on use. Capability claims derived from vendor marketing copy alone are not used; if a feature is claimed but not documented, it does not appear as a populated field.

Every tool profile carries a last_verified date, visible on the page. A profile is considered verified when each populated field has been re-checked against its source on or after that date. Profiles are re-verified at least every 180 days, and sooner when triggered by a vendor announcement (acquisition, pricing change, major release) or a reader correction.

The catalog has no fixed editorial calendar. New tool entries land when they're complete. Re-verification of existing entries runs as a rolling background process. Significant changes to a tool's schema position (status flag flip, primary cluster reassignment) are noted in the corrections log.

The schema includes four optional editorial fields: notable_strengths, notable_weaknesses, ideal_for, and avoid_if. These are populated only where the maintainer has direct hands-on experience with the tool. Their absence does not indicate a problem with the tool — it indicates the catalog hasn't earned the right to render an editorial verdict on it. The structured fields are the catalog's primary output.

This is a one-person project. Coverage is built breadth-first within a vertical before moving to the next. Re-verification cadence depends on a single maintainer's available time. Where the catalog falls behind, the last_verified date will say so plainly.