activity

What it observes

When a person last changed something on one site, and whether the site is in a state where nobody could.

m365-governance collect activity \
  --client-id <id> \
  --site-url https://<tenant>.sharepoint.com/sites/<site> \
  --tenant-url https://<tenant>-admin.sharepoint.com \
  --output ./evidence/activity.json

The one decision this collector exists for

It reads LastItemUserModifiedDate, not LastItemModifiedDate.

On a real tenant every site had been touched that same day by a system process, and two of three had gone over a year without a person. The naive property makes every site look alive. That difference is the whole reason the module exists, and it is why an inactivity finding from this engine is worth reading.

Why the lock state travels with the date

A site nobody has touched because it is locked is not the same as a site nobody wants. Collecting whether the site is in a state where nobody could change it keeps a rule from reporting enforced read only as abandonment.

Two observations of activity, and both can be right

This collector reads LastItemUserModifiedDate from the web itself. Microsoft also publishes activity through the usage reporting endpoints, and that is a different pipeline, not a second copy of this one.

When those two disagree, neither is necessarily wrong. They are answers to different questions asked of different systems at different moments, and a product that picks one and calls it the activity has thrown away the more useful fact: that the two are measuring differently.

The comparison is worth making for exactly that reason: it establishes what each value means, rather than which one wins.

What it does not establish

That the content is unwanted. A last human write date is a fact about writes. Whether anybody is reading, and whether the site still matters, is not observable from here.