35 · 123
Collectors run · distinct findings they can produce. Public records only.
METHODOLOGY
Every conclusion carries its evidence state and assessment boundary.
SCOUTz records what it checked, when it checked it, which source supported the result, and whether missing coverage limits the conclusion.
EVIDENCE · INSIGHT · PROOF
What you can know before they let you in, and after.
01
Before consent
Published domain, DNS, email authentication, certificates and external evidence.
02
With read-only consent
Supported Microsoft 365 identity, app, permission, licensing and configuration evidence.
03
Never inferred
No message bodies, private files, chats or prompts. Unread is not clean.
How scans become supported conclusions.
PUBLISH THE UNIT
Breadth without inflated math.
Domain and cloud are different access layers. The platform total also includes fusion and correlation passes that run on top of collector output.
92 · 370
Collectors run · distinct findings they can produce, including the public-domain roster.
601
Distinct finding types across 91 emitting modules and correlation passes.
Every finding is explained in business terms.
All 601 finding types carry an authored explanation, consequence, recommendation, and the evidence they were drawn from. The build fails if one is missing.
538 registered check IDs keep every finding defensible. The ledger separates 440 scored findings, 107 context observations, and 22 declared non-reads. A non-read is never a clean result.
INDEPENDENT DISCOVERY
Compare what was recorded with what can be independently supported.
PSA, RMM, and specialist tools remain valuable. SCOUTz discovers, observes, normalizes, correlates, and asks what the combined evidence actually supports.
ASSESSMENT BOUNDARY
A focused vendor review and a client assessment answer different questions.
Specialist reviews are not dishonest; they were designed for a narrower job. SCOUTz begins with the company and leaves the implementation choice with the MSP.
SPECIALIZED VENDOR ASSESSMENT
CATEGORY
The vendor's specialty
SCANNER
Evidence in that boundary
FINDINGS
Needs related to that capability
SOLUTION
The vendor's implementation
SCOUTz CLIENT ASSESSMENT
COMPANY
Start with the organization
DISCOVERY
Gather supported evidence
CONDITION
Name what needs attention
OUTCOME
Define what better means
MSP CHOOSES
Product, service, process, project—or nothing
FINDINGWeak authentication coverage
→SCOUTz ANSWERSWho is affected? Why does it matter? What supports it? What should change? How can it be verified?
→MSP DECIDESExisting product · configuration · new product · process · project · nothing
EVIDENCE STATES
Unknown is not clean—and confidence is not theater.
These are distinct evidence states, not a mathematically linear score ladder.
VERIFIED
Directly supported or completed validation
OBSERVED
Seen in the named source at the recorded time
INFERRED
Supported, but not directly proven
POSSIBLE
Plausible and still needs investigation
UNKNOWN
The source cannot establish the state
UNREADABLE
The source could not be read
PROVIDER RETURNS 403→NOT ASSESSED≠NO RISK FOUND
REAL APP CAPTURE · CLIENT DETAILS REMOVED
Vendor neutrality is part of finding truth.
A finding describes the condition, evidence, affected object, unknowns, and recommended outcome—not an automatic instruction to buy Vendor X. Any future vendor recommendation must be explicit, transparent, clearly separate from the underlying finding, and unable to change what the evidence says.
Vendor assessment or client assessment? →VERIFIED
Directly supported by a named authoritative source or completed validation.
OBSERVED
Seen by SCOUTz from the disclosed source at the recorded time.
INFERRED
Supported by evidence, but not directly proven by the available source.
POSSIBLE
A plausible condition or opportunity that still requires investigation.
UNKNOWN
The available evidence cannot establish the state. Unknown is not clean.
UNREADABLE
The source could not be read because of availability, format, access, or permission.
Assessment coverage is separate from the finding result.
ASSESSED · PARTIAL · NOT_ASSESSED · PERMISSION_LIMITED · LICENSE_LIMITED. A permission- or license-limited source never becomes a clean score by omission.
DOMAIN BOUNDARY
Public signals only.
DNS, email authentication, HTTPS, certificates, headers, subdomains, exposed services, and related external evidence. No proof of internal controls, recovery, people, or process.
MICROSOFT 365 BOUNDARY
Customer-approved configuration and metadata.
Supported identity, application, security, and managed-device context. No mail, files, chats, documents, prompts, or automatic changes.
The access method is part of the evidence context.
A public observation and an authorized tenant record can support different kinds of claims. Customer authorization can strengthen the available source, but it never removes coverage, permission, license, provider, or readability limits.
Why permission follows the question →Define the answer needed.
Start with the business or technical question instead of the broadest API permission available.
Choose the necessary source.
Use the least intrusive source that can responsibly support the answer.
Explain and authorize.
If deeper evidence is necessary, state the purpose and boundary before collection begins.
Are the SCOUTz screenshots real?
Every image labeled Real Product is captured from the working application and anonymized. Every designed explanation is labeled Illustrative. We do not use AI-generated interfaces as evidence that a feature exists.
Read the authenticity standard →Your next prospect meeting is already on the calendar.
Bring dated evidence, clear limits, and useful questions.