For the complete documentation index, see llms.txt. This page is also available as Markdown.

Using the App

This page walks FacilityGuard's five screens in the order a monitoring workflow uses them: connect your facility list and understand its disclosure coverage, work the change watchlist, drill into a facility's disclosed ownership chain, read the portfolio's health at a glance, and export your evidence. Throughout, FacilityGuard keeps one promise: it shows what CMS filings disclose, flags where they stop, and records when each change was detected — never pretending a detection date is a transaction date.

Portfolio setup

FacilityGuard portfolio setup with the connected table, CCN mapping, and coverage panel

Portfolio setup connects your facility list (one row per CCN) and immediately answers the question every new user should ask first: what can the federal filings actually tell me about these facilities? The coverage panel classifies each bound facility — fully disclosed, partially disclosed, dead-end (an upstream owner with zero federal disclosure), or no enrollment data — so you know, before citing anything, which chains are complete and which findings will need an "as disclosed in federal filings" qualifier.

To connect a list: (1) Connect your facility list — Snowflake's grant dialog opens; pick your CCN table and Save (read-only SELECT on that one table). The page then confirms the connection, naming the exact table you picked and its row and column counts. (2) Map the CCN column and Save mapping. (3) Bind portfolio. The coverage panel appears once the bind completes. Binds are capped by plan; over-cap counts are reported, never silently truncated. See Quickstart for the full walkthrough.

Change watchlist

FacilityGuard change watchlist with event tags, confirmation chips, and the review ledger

The watchlist is the alert feed: every ownership change for your facilities, tagged by type (owner appears, owner gone, percentage change, enrollment appears/gone) and graded so the validated signal leads. The feed defaults to the strong-signal and watchlist grades, with lower-stakes disclosure churn one filter away — kept and available, never deleted, never mixed into the signal by default. Each event carries its receipt (the pair of CMS publications it was detected between) and a confirmation chip that flips when the official CMS change-of-ownership file later publishes the matching event; the track record at the top shows how often early detections have been officially confirmed. Both review actions — mark reviewed and dismiss — write to the same append-only ledger: who looked, when, and what they concluded. A dismissal is a recorded determination, not a deletion — which is what makes the watchlist citable rather than just interesting.

Ownership chains

FacilityGuard ownership chain tree with dead-end terminal node and entity side panel

Ownership chains render a facility's disclosed structure as a tree: direct and indirect owners, roles, and disclosed percentages — with undisclosed percentages shown explicitly as "% not disclosed" rather than blank or zero — and a side panel for each owner showing its name, kind, CMS self-reported type flags (private equity, REIT, holding company), first- and last-seen dates, and how many facilities it's confirmed to own across the whole universe. Where disclosure stops, the chain ends in a labeled dead-end node; facilities with zero disclosed ownership show their receipts (the disclosure status and the date checked) instead of an empty chart. For an analyst building an ownership picture of a target, this is the difference between "here is the structure" and "here is the structure CMS has been told about, ending here."

Portfolio health

FacilityGuard portfolio health overview with disclosure coverage, a color legend, and recent activity

Portfolio health is the standing one-page answer to "anything moving in the book?": disclosure coverage across your facilities, recent activity as tiles (unreviewed and confirmed counts), dead-end and no-data counts shown against the ~30% national base rate (so you know whether your book is unusually opaque or just normal), and the source dates everything was last checked against. Each facility carries a completeness code, and a color legend spells out what each code means — full, partial, dead-end, no data — alongside the amber row-wash that marks facilities with unreviewed changes needing attention. It's built for a recurring monthly read, so a quiet month reads visibly as a quiet month with current data, not a stale page.

Settings & export

FacilityGuard settings and export page

Settings & export holds portfolio administration and your evidence artifacts: export the watchlist with its review ledger and per-event receipts for a data room, memo appendix, or downstream system. The page also shows your license panel — your current plan and a bound-facilities meter (the same limit the bind enforces), so the label always matches the plan you're on — a freshness card per source with its current date (including the note that the official CMS change-of-ownership file publishes roughly five months behind filings by design, so its amber state means expected lag, not an error), and the run log: every bind and refresh with its date, counts, and the exact source dates used — the no-SQL answer to "what did we check, and against what." Your list, reviews, and run history live inside your Snowflake account and survive app upgrades — your work product is yours.

Troubleshooting

An event I expected isn't on the watchlist

Cause: the change may not have reached federal filings yet — only filed changes can be detected, and CMS publishes monthly.

Fix:

  1. Check the latest source date on Portfolio health — detection can only be as current as the newest publication.

  2. Check the facility's disclosure status: changes behind a dead-end owner are invisible to federal filings by definition.

A confirmation chip never flipped

Cause: the official CMS change-of-ownership file lags filings by roughly five months, and not every detected event has an official counterpart — the official file covers formal changes of ownership only.

Fix:

  1. Give confirmations time; chips flip when the official feed publishes the matching event.

  2. Read the basis note under each event — it states the reason for the detection independent of official confirmation.

Two owners look like the same company under different names

Cause: FacilityGuard identifies owners by their stable CMS-assigned ID, not by name — and CMS name strings vary heavily across filings. Unresolved name collisions are labeled rather than guessed at.

Fix:

  1. Use the owner side panel — the ID-based name and facility footprint are authoritative.

  2. See Methodology for why name-based merging is deliberately avoided.

An owner shows "(name not disclosed by CMS)"

Cause: a small share of owner links carry no name in any CMS filing to date.

Fix: the owner still has a stable identity, role, and footprint — the missing name is CMS's, and FacilityGuard says so rather than inventing one.


FacilityGuard docs: Overview · Quickstart · Methodology · What FacilityGuard Checks · Security & Plans

Last updated