30-second answer
The engine's capacity profile declares set_aside_classes: [system],
and the word is chosen against the obvious alternative. A set-aside
resource is still collected, still evaluated, still counted and still
printed, under its own heading at the end of the report. Excluding it
would mean not looking, and the profile's own comment states the danger:
a document library holding 60,000 unique permission scopes is over a
hard product limit whoever created it, and SharePoint calling it a
catalog is not a reason for a governance report to stay silent about
it.
What this proves
- That the report covers what exists, not what somebody chose to care about. Coverage claims stay true because nothing left the evaluation; it only left the top of the page.
- That classification is a reading decision, not a collection one. The class comes from evidence flags with a fixed precedence, catalog over application over system, an order corrected after 23 real lists showed the naive one misfiled the App Catalog.
What it does not prove
- That system lists are fine. Below the fold is still on the page. A set-aside section with a hard-limit fail in it is a finding with a different heading, not a finding that went away.
- That the class is always known. When all three flags are absent the classification is unknown, never silently "content". Absence of a flag is a fact about collection, not about the list.
PowerShell
# Evaluate with the capacity profile: system lists move below the fold,
# they do not leave the evaluation
m365-governance evaluate .\evidence\ --profile capacityExample output
Findings ............ 4 rules over 61 lists
Set aside (system) .. 9 lists, evaluated and printed belowExplanation
Profiles answer "what am I asking today", and the engine keeps that question separate from "what exists". The capacity profile pairs two documented limits, one documented recommendation and one threshold that is the project's own, and it reads every list the evidence carries. The set-aside mechanism exists because the alternative that was tried first, dropping the class, is dangerous in a specific, checkable way: hard limits do not care who created the list. The report's shape carries the decision: the classes a reader asked about lead, and the set-aside class closes the report with its own count, so the totals always reconcile.
Production considerations
- If your tooling filters "system" or "hidden" lists before evaluation, your coverage number is quietly wrong, and it is wrong in the direction that flatters you.
- Keep precedence rules for classification in one place and test them against real tenants. The engine's order survived contact with 23 actual lists; the first draft did not.
Related governance rules
SPO-LIST-002: the hard scope limit that makes exclusion dangerous; a catalog over it is over it
References
- Capacity profile, with the set-aside rationale (m365-governance-as-code)
- Evidence schema, section 14: list classification (m365-governance-as-code)
Found something wrong? Suggest a correction. The article source is not public; the engine it cites is.