Trust the evidence, not the assertion
This engine separates what Microsoft 365 exposed, what the evidence establishes, and what a governance rule concludes from it, including what remains unknown. Every part of that separation is visible in the output, and every part of it is checkable by somebody who did not run it.
Read-only by design
Assessment paths observe Microsoft 365. They do not remediate it. There is no
--fix, and no mode in which a run changes a tenant. The engine's one write
happens outside every run: the application registration
setup makes, once, when an
administrator agrees to it.
Evidence before conclusion
A finding keeps the evidence it was decided from and the provenance of that evidence: which collector read it, when, as which kind of identity, and what it could not reach.
Microsoft and this product are not interchangeable
Documented Microsoft guidance, documented Microsoft limits and our own operational conventions stay visibly distinct, in the output and in the rule catalogue. A convention presented as a requirement is the one misreading this product exists to prevent.
Unknown stays unknown
Partial acquisition, missing evidence or a question the evidence cannot answer
produce unknown. None of them can quietly become a pass.
The chain, and what each step establishes
Each step answers for itself. Reading one as if it answered for the next is how a report ends up more certain than the run that produced it.
| Step | What it establishes | What it does not |
|---|---|---|
| Microsoft 365 | the state of a tenant at a moment | nothing on its own: it has to be read |
| Acquisition | that a surface was read, by which identity, and what it refused | that what came back means what somebody assumed |
| Evidence | the facts as the vendor returned them, with provenance and named gaps | that the facts are complete: a gap is recorded, not filled |
| Assessment | what the rules decided from those facts, and on what basis | anything the evidence did not carry |
| Bundle | a canonical artefact carrying findings, evidence, versions and digests | that anybody has opened it |
| Independent consumer | that a named consumer read the artefact and interpreted it correctly | that the acquisition beneath it was live |
Two different questions, and they are not degrees of each other
A capability is described by two states. Reading one as the other is how something gets called proved when half of what the word could mean was never attempted, so they are named separately and neither is derived from the other.
Live validation. Have we established that this capability reads and represents the Microsoft 365 state correctly? It has its own progression: whether a real acquisition ran, whether the representation was checked against what the fields are claimed to mean, whether a second authoritative surface was compared where one exists, and whether any divergence was explained rather than silently resolved.
Product path assurance. Has evidence from this capability travelled the whole product path without gaining certainty along the way?
Acquisition → Evidence → Assessment → Bundle → ConsumerA capability can sit high on one and low on the other in both directions. Both states are published per capability on what we can establish, derived from the record of what actually ran.
Consumer compatibility is a third question and belongs to neither ladder: can an identified consumer open and semantically interpret a canonical engine artefact? That one is established today. It is not end-to-end capability assurance and is never presented as it.
How a PASS is earned
Most of this page is about how a problem is found. This is the harder half: what has to be true before the product will say it did not find one.
evidence available
+
acquisition sufficient for the question
+
rule decidable from that evidence
↓
PASS
anything missing
↓
UNKNOWNA worked example from the published catalogue.
SPO-LIST-002 reads
whether a list holds more than 50,000 unique permission scopes: a limit
Microsoft documents, with a number in it. It requires one fact:
permissions.unique_scope_count.
If that count was collected, the rule decides and the result is a pass or a
finding. If counting was refused, or stopped early, or was never attempted, the
result is unknown and the report says which of those happened. It does not
become a pass because nothing was found: nothing was looked at.
That distinction is the product. A tool whose request failed, received an empty list, reported zero findings and rendered green has told you the opposite of what happened.
And the rule publishes its own boundary: a list at 49,000 scopes passes and is one sharing operation from the ceiling. A pass here means the limit is not exceeded, and nothing more.
Authentication, and what a run can see
Every assessment names the identity that produced its evidence, because the same report means different things behind different ones.
| Identity | How it authenticates | What a run can read |
|---|---|---|
| Delegated | a person signs in, interactively or with a device code | what that one person can see. Nothing produced this way is a tenant-wide statement |
| Application | a registered application authenticates with a certificate | whatever the tenant granted the application. It is bounded by no person's view |
| Not established | the evidence does not record it | unknown, and this is the case where what a report could reach cannot be bounded at all |
Read-only by design is not least privilege.
No run has a write path, whatever the identity; the one write is the application registration
setupmakes when an administrator agrees. How much a run can read is decided by the permissions somebody granted the identity they configured. An application with broad read permissions produces a report with broad reach, and it is still read-only. The two are different promises and this product only makes the first one.
Verify us
Nothing above asks to be taken on trust.
- The rule catalogue: every question, its basis, its severity and what a pass does not settle
- What we can establish: which questions are answerable today, and the criteria a question must satisfy to appear there
- The published contracts: the versioned schemas a consumer builds against
- The engine, in the open: the rules, the collectors, the gates and their history
First principle
Every governance conclusion must declare what kind of truth it is.
Governance reports often present requirements, recommendations, conventions and opinions with identical visual weight. A reader cannot tell which statements they are free to disagree with.
This project does not do that. Every rule declares the nature of its claim in
basis, and the report
prints it beside the finding.
Second principle
Automation may verify a claim. It may never strengthen it.
Automation may verify that evidence exists, that required sources are present, that schemas are valid, that documentation links resolve, and that conclusions are reproducible.
Automation must never infer that a recommendation is a requirement, that a convention becomes documented guidance because somebody attached a link, or that missing evidence means compliance.
The third of those is the one that shows up in the output every day. It is why
unknown is a result and never a pass.
Where it runs, and what leaves your machine
The principles above are about what a conclusion means. This is about where the software is and what it touches, which is the other half of the same question and was written down separately from it until now.
Where does it run? On your machine. It is a command-line program you install and start; there is no hosted service, no account with pH7x Systems and no sign-in to us. Nothing about running it involves a system we operate.
What network destinations does it use? Microsoft's, and the ones you point
it at. The Graph reader talks to https://graph.microsoft.com. The PowerShell
collectors talk to the SharePoint endpoints of the tenant URL you supply. There
is no third destination: the schemas it validates against are files inside the
package, read from disk, not fetched.
Where is evidence written? Where you tell it. collect, migration-read
and the report commands all take an explicit output path and write there.
Evidence, findings and reports are files on your filesystem.
What reaches pH7x Systems? Nothing that the software sends. It carries no telemetry, no usage reporting and no licence check. Tenant evidence processed by the software is not transmitted to pH7x Systems by the software. If you choose to send us a report, attached to a question or in a review we do with you, that is you sending it, and it is the only path by which we would see it.
What credentials does pH7x Systems receive? None. Authentication happens between you and Microsoft: the Graph reader never acquires a token, it spends one you supply, and the PowerShell path uses the connection you established with an identity you registered. If anything ever asks you to hand tenant credentials to pH7x Systems in order to run this, it did not come from us.
These are properties of the current version, established by reading what it does rather than by describing what it is for. The open source and security statement says the same thing for the site as a whole.
What every gate proves, and what it does not
Every check in CI is narrower than the sentence people will summarise it as, and the project writes both halves down. Both were learned by watching a gate pass while the thing it guarded failed anyway.
The read-only gate is the clearest case. It parses every file in the collector tree and fails on any mutating verb. What that establishes and what it leaves open is set out in what a read only gate proves.
What an assessment lets a recipient establish
An assessment carries the findings, the evidence they were decided from, the versions that decided them, and digests over all of it.
A recipient runs verify
and establishes that nothing moved, without having this engine and without
trusting whoever sent it. That is why verify is a separate command: a check
that needed the producer would only ever be telling the recipient what the
producer already believes.
Reproducibility is what makes it possible. The clock is read at exactly one boundary and passed as a value, so the same inputs rebuild the same bytes.
Responsibility
The engine does not decide what an organisation should do. It establishes what is observable, what the vendor documents, and where the two differ. The decision, and the risk in it, stay with the people who own the tenant.