List Requirements
The library, filterable, sortable, capped, and — when asked — ranked by its own record.
collateral_type and marketing_team_id match a requirement whose scope is unset too, because an unset scope means "applies to everything" — filtering it out would hide the requirements that most certainly do apply. preset_id does not; see below. file_id names the standards documents to read from — strict membership for the same reason preset_id is, and narrower: it answers "which of this document's rules are misbehaving", which is how a librarian who knows the standard they are tuning reaches its rules without paging through the library.
order is a parameter here rather than a route of its own. Ranking a library by how often reviewers dismiss what a rule produced is the same selection as this list, ordered differently, and the tuning surfaces need it with every filter above still applying. A parallel route had five things silently wrong for the same rows: max_requirements_per_state_change absent so the bulk cap read zero against a server that refuses at fifty, three of the five filters dropped while their chips stayed lit, a thinner row that blanked seven fields RequirementCard renders, truncation copy telling the reader to narrow filters when narrowing is not the remedy, and two query keys keepPreviousData cannot span. One route keeps all five right by construction.
With order set, each row carries a signal block and rows with no checks in the window are absent — a requirement nothing has been judged against has no track record to rank. With it unset the query, the plan and the row are exactly what they were before: the aggregates are not joined, so the ordinary library list pays nothing for this.
The ranking is applied here rather than in the browser because the response is one capped page of whatever matched, not a window onto an ordered list — so a client re-ordering what it was sent would answer "which rules produce the most false positives" with the worst of an arbitrary page, silently, on exactly the libraries where the question is worth asking.
Query parameters
What a ranking of a company's requirements is ranked by.
Five orders because the two surfaces ask different questions and each wants a rate and a volume. A rate finds the rule that is usually wrong; a volume finds the rule that is wrong most often. Neither subsumes the other, and offering only one is how a screen ends up either dominated by rules with three data points or blind to a rule that is wrong 40% of the time on hundreds of assets.
FIRE_RATE applies MIN_CHECKED_FOR_RATE; the two verdict rates are held down by FALSE_POSITIVE_PRIOR_REVIEWS instead, so a genuinely bad two-of-two stays visible without topping the list. The two volumes need neither: a count is already its own evidence.
Which way a sortable list is sorted.
Here rather than beside any one feature because a direction is not a property of what is being sorted. backend/api/vendors.py, reviews.py and vendor_services.py each spell it as Query("asc", pattern="^(asc|desc)$"); the wire values match, so those can adopt this without a client change, and nothing new should add a fourth spelling (naming-semantics N-1).
Response
Successful Response
Changes
No recorded changes to this endpoint across all 1 revision of this API.