Starter recipes for the package file — every query is tested against a real collected file and runs as-is. They are deliberately starting points: each answers a first-pass question and usually raises the next, more interesting one.
Setup
Any DuckDB client will do (see Troubleshooting if the file is encrypted):
ATTACH 'your-site.duckdb' AS audit (ENCRYPTION_KEY 'passphrase', READ_ONLY);
USE audit;All recipes use the v_*_current views (the current snapshot) and the clear.*
views where real names help — remember those resolve identities only on your
local file, never on an export.
The recipes
| Question | Theme |
|---|---|
| Who hasn’t signed in for 90+ days? | Licence waste |
| What is granted to “All Users”? | Permission exposure |
| Which content shows no access events? | Zombie content |
| Who owns content but isn’t in the user listing? | Ownerless assets |
| Where do embedded credentials live? | Security debt |
| How much content is certified? | Governance pulse |
| What does activity look like over time? | Event history |
Where to go from here
The full table-by-table guide is in Package file schema.
These seven are the map’s edge, not the territory. Questions like “who can actually see this workbook, through every group and inheritance path?” or “which content is safe to archive?” need resolution logic that goes well beyond single queries — the collector deliberately does not compute them (why).