The Ultimate Member Private Content add-on lets editors restrict posts, pages and custom post types to specific roles, logged-in users or named member groups. Restrictions are stored as post meta on each protected post (commonly _um_content_restriction with rule type and target roles), and the default surface is a per-post visibility panel in the editor. That is right for editing one piece of content and unhelpful for understanding the protection footprint across the catalogue.

SleekView reads wp_posts joined with the Ultimate Member content-restriction post meta and renders each protected post as a row in an audit table. Filter to last-30-days new protections for editorial-sprint review, sort by restriction_type to confirm policy shape, group by post_type to see which types carry the member-only catalogue. The same dataset the chart view aggregates becomes a row-level surface for editors, compliance and community managers.

The add-on keeps owning visibility enforcement at the front-end. The table view owns the audit surface, so the restrictions the add-on already writes stop hiding inside per-post tabs and become something content ops can actually query.

Ultimate Member Private Content captures the data editors and compliance need: which posts are protected, by which rule, for which roles or groups. The default surface places that data inside per-post visibility panels, which is right for one-post-at-a-time editing and unhelpful for almost everything operators do across the catalogue. A queryable protection table answers the questions teams actually ask: which post types carry the member-only catalogue, did the new policy land, are there orphaned rules on stale drafts.

Same post meta, same timestamps, completely different decision posture. The table renders the protection footprint the add-on already maintains as an auditable cohort, which is the difference between knowing some content is private and knowing exactly what is member-only this quarter.