Reports flagged for removal from sale

Under EDITORIAL.md rule 7, a sold report never takes responsibility for a defect. Fix the defect, cut the section that depends on it, or pull the report until it can be fixed properly.

Every report below currently discloses an open, unfixed defect in the API Evangelist scoring pipeline. Each one is therefore flagged. Nothing here has been unpublished yet — that is a storefront action (Stripe product, Worker PAPERS map, _papers/ teaser) and needs Kin’s word.

Status legend: FIX = repair the defect and re-score, then the disclosure is unnecessary · CUT = remove the section, the rest of the report stands · PULL = withhold from sale.

1. checklist-telstra — rate-limit sync defect, 1,039 providers

Lines 39, 44, 151–162. “Two of your gaps are my bugs, not yours” · “Both are mine to fix” · “This affects 1,039 of the 7,621 providers with a rate-limit block, so it is a pipeline defect.”

The report tells a paying customer that two of the gaps it charges them to fix are API Evangelist’s own bug — and that the same bug misprices 1,039 other providers.

✅ FIXED 2026-08-03 in api-search/network/scripts/build.py (_derive_ratelimits_meta).

Root cause: limit_count counted the limits container only. Real published limits also arrive under policies, rate_limits, rateLimits and tiers depending on which harvest wrote the artifact. Telstra’s four policies live under policies, so it scored limit_count: 0 and failed both rate_limits_documented (8 pts) and rate_limits_rich (4 pts).

The fix is strictly additive — when limits is populated the behaviour is unchanged, so no existing score can move down and the ~5,500 artifacts carrying both containers are not double-counted. Fallback entries only count when they state an actual limit: DoorLoop’s entry says the vendor “has not publicly disclosed specific rate limit values”, and crediting that would have been a new defect in the other direction.

Measured across 7,779 rate-limit artifacts:

Still needs a re-score to propagate — ruby signals/score.rb --write, which build.py runs at the end of a build. Until then the corrected numbers exist only in the extractor.

2. the-asyncapi-standard — §9 is built on the defect

Lines 37, 39, 81, 227–254. An entire section titled “The scoring caveat, and a defect in the instrument”, containing “The defect is separate, larger, and mine”, “One more defect this exposed, still open — the refinement pipeline drops the top-level webhooks object”, “the honest count of what was wrong” (naming three other reports corrected to v1.1), and “Better to publish this than have a reader find it.”

The “still open” defect is ALREADY FIXED — the disclosure is stale. refine-openapis/scripts/split_openapis.py now walks webhooks alongside paths (an OAS 3.1 webhook entry is a Path Item Object), filters it by tag, and emits it. Verified functionally on a scratch provider: a top-level webhooks: {thingCreated} survived the tag split intact, with its $ref schema correctly carried into components. So the report tells buyers a bug is open that is not.

Recommended: CUT the confession, keep the methodology. §9 mixes two things. The argument that a composite is the wrong instrument for a standards body is real methodology and stays. The defect narrative, the correction ledger, the “still open” line, and the v1.1 notices are confession and go. Related: refine-openapis-skill.

3. state-of-us-insurance-apis — provenance does not gate contract quality

Line 121. “This is a defect in the rubric, not in these companies, and it is being fixed: provenance will gate the contract-quality facet in the next rev.”

Recommended: FIX. Until provenance gates that facet, the report knowingly publishes inflated contract-quality numbers for providers whose specs API Evangelist reconstructed. That is a scoring correctness problem, not a copy problem. Related: kin-score-provenance-gap.

4. the-mcp-standard — uncontrolled status vocabulary

Line 80. “One honest data-quality note about the pipeline itself. The status field has accumulated 40 distinct values … a controlled vocabulary that was never controlled, and it is being fixed.”

Recommended: FIX, then CUT. The report already routes around it by using the concrete server URL as the hard line, so the finding survives without the note. Normalize the vocabulary and delete the paragraph.

5. checklist-cisco — confesses a defect that is already fixed

Line 162. “A correction I owe you on my own side. Chasing your number surfaced three defects in my scoring pipeline … The embedded copy of each spec that the scorer read was capped at 32KB, and JSON specs were not read at all … That affected 2,131 providers, not just you. It is fixed, the fix is in the public scoring engine, and your numbers above are computed with it.”

Recommended: CUT. The defect is already repaired and the customer’s numbers are computed with the fix — so there is nothing outstanding, and nothing to own. The paragraph is pure confession: it tells a customer that the vendor grading them was, until recently, structurally advantaging stub specifications over their real 957-operation contract. The corrected score speaks for itself.

Note this is an engagement deliverable — see cisco-fabricated-contracts.

(the-oauth-2-standard was a scan false positive: line 253 reads “the standard … with the least to apologise for”, which is praise for OAuth, not a defect disclosure. No action.)

Correction notices — separate, lower-severity

These are not open defects. They are v1.1 correction notes narrating that an earlier release was wrong. Under rule 7 they belong in a changelog, not in the product; the corrected numbers stand on their own.

Recommended: CUT all, and record the corrections in a CHANGELOG.md in each report folder so the version history survives without the product apologising for itself.