Provider roster check — high-level pointers (local fallback)

stoutland tells you who the site publishes versus who should be there. The detailed, current roster-compliance standards — how fast a departed provider must come down, who owns the roster CSV, and how to handle a name the site lists that nobody can confirm — live in the team wiki (set OUTLINE + OUTLINE_API_URL and the report links them directly). This file is the minimal high-level fallback for when the wiki isn’t configured: direction only, deliberately not step-by-step, so there’s no detailed content to drift out of sync with the wiki.

• Departed but still listed — the liability case; treat as urgent, not routine content cleanup.
• On the site, not in the roster — resolve which is wrong before acting: either the roster is stale or the page should not be published.
• Active in the roster, no page — a content gap, not a liability; queue it as normal work.
• No fuzzy matching — a name match that can’t be confirmed first+last should be verified by a human, never auto-resolved by similarity.
• Discovery mode — treat its output as the starting draft of a roster CSV, not a finished audit; confirm names against the practice before trusting the list.
• Ownership — the roster CSV needs a named owner so “who removes a departed provider” has an answer before the next departure, not after.

Full playbook → the team wiki’s provider-roster compliance standards.