Security Marking Auditability

I wanted to clarify that this isn’t entirely accurate. Monocle is limited to 500 items, and beyond that, users need to manually unfold individual datasets in the data lineage. This can become quite cumbersome, especially in large projects with numerous central data assets across the organization.

I agree with this perspective. That said, the issue you’re raising is somewhat similar to how we display all of a user’s projects in the access graph. Personally, I’d intuitively look for this kind of information there, as the access graph feels more interactive and user-friendly. However, it’s also clear that this view needs to be complemented by the details available in the project catalog or portfolio tabs.

Broaden scope of curated resources in the Project Catalog - Propose an Improvement - Palantir Developer Community

All of the requirements outlined above are particularly relevant in situations where: 1) markings need to be decommissioned, and 2) application owners are unaware of where a marking was removed and have forgotten to set the “re-approval” flag in the code repositories, 3) the lifecycle of sensitive information - and its derivatives - needs to be audited and monitored for legal/compliance reasons. Unfortunately, in the absence of native support, people often resort to tracking this information manually in Excel sheets just to monitor their markings. In some cases, members of the removal marking group were unaware that certain data assets had been unmarked because they did not communicate among themselves. This lack of visibility leads to confusion, and a urge to build and automate this information outside of the Foundry platform.