The three-tenant sample evidence pack
This is the complete output of one audit run, produced from entirely invented tenants. It is published so you can judge the format before you send anything, and so that nothing about the deliverable has to be taken on trust.
No customer is depicted. The three tenants, their application IDs and every number below were invented for this demonstration. Every CSV declares a synthetic column and every JSON a synthetic field; every HTML report is headed REVIEW ONLY, and the portfolio report adds Synthetic evidence on its own face. Nothing here implies a customer relationship, a testimonial, or a result you should expect.
What this run found
Three tenants, two applications observed calling EWS, and four different verdicts. The point of the sample is the shape of the disagreement, not the size of the numbers.
| Tenant | Observed | Allowed | Blocked | Phased block | Cannot determine | Unresolved |
|---|---|---|---|---|---|---|
| fictional-alpha | 1 | 1 | 1 | 0 | 0 | 2 |
| fictional-beta | 1 | 0 | 0 | 1 | 0 | 1 |
| fictional-gamma | 0 | 0 | 0 | 0 | 1 | 1 |
fictional-gamma is the row worth looking at twice. Nothing was observed calling EWS in that tenant, and the verdict is still cannot determine rather than “safe”. That is the whole argument of this service in one cell.
Why the states are deliberately mixed
A demonstration that finds everything and resolves everything would be a demonstration of nothing. The sample was built so each awkward state appears at least once:
- Active and known. Usage observed, the application identified, a decision recordable. The easy case, and the minority of real ones.
- Active and unknown. Usage observed against an application ID nobody claims. In the pack these land in the unknown-owner queue, which in practice is where the real work is.
- Allow-listed but not observed in the window. An entry with no evidence behind it. Absence in a report window is not evidence of absence, so the pack refuses to call it unused and says so.
- Cannot determine. A state the tooling is allowed to return. It exists because the alternative — guessing, and calling the guess a finding — is how an allow list ends up wrong in a way nobody notices until October.
Every artifact, exactly as produced
These are the real output bytes, not a cleaned-up version made for a website. The HTML reports open directly on this site, so the portfolio’s tenant links retain their original folder layout. CSV and JSON artifacts open as raw evidence.
| Artifact | What to look at |
|---|---|
| portfolio-overview.html | Start here. Totals, the per-tenant table, the full-replace warning and the non-claims section, all on one page. |
| tenants/fictional-alpha/overview.html | The tenant with both an allowed and a blocked verdict, plus two unresolved entries. |
| tenants/fictional-alpha/evidence.json | The same tenant as machine-readable evidence, hashed into the run manifest. |
| tenants/fictional-beta/overview.html | Observed usage with one modeled phased-block verdict and one unresolved entry. |
| tenants/fictional-beta/evidence.json | Evidence behind the beta tenant, including the dimensions left unresolved. |
| tenants/fictional-gamma/overview.html | Nothing observed, and the verdict is still cannot-determine rather than safe. |
| tenants/fictional-gamma/evidence.json | What an absence of observations looks like when it is recorded honestly instead of read as an all-clear. |
| portfolio-summary.csv | One row per tenant. The synthetic column is in every row of every CSV here. |
| normalized-usage.csv | Observed usage after normalisation, with the report window and the source evidence recorded per row. |
| permission-reconciliation.csv | Usage state against app-only and delegated rights — the reconciliation the report cannot do for you. |
| organization-policy-model.csv | The modelled outcome per application per phase, with the policy-model version stamped on each row. |
| reconciliation-findings.csv | Findings with severity and an explanation code, so a finding can be argued with rather than believed. |
| unknown-owner-queue.csv | The queue that is the actual work: observed application IDs nobody has claimed yet. |
| unknown-evidence.csv | Every dimension where the evidence was missing or ambiguous, with a reason code instead of a guess. |
| mailbox-override-summary.csv | Per-tenant counts of mailbox-level overrides, including how many could not be determined. |
| configuration-proposal.csv | A review-only full-set replacement, with the current snapshot hash recorded next to it. |
| decision-register.csv | Who decided what, why, and by when. The column your client will ask about. |
| run-manifest.json | The manifest tying every artifact to one run fingerprint. |
| validation-report.json | The run's own self-check, published rather than summarised. |
What makes it evidence rather than a report
- Every file is stamped, and the set is tied together. Every artifact carries the output schema version and the run fingerprint that identifies the run it came from. The HTML reports add the artifact, binary and policy-model versions and an as-of timestamp in UTC; the manifest records a hash for each other artifact.
- Proposals are review-only. The configuration proposal is a full-set replacement written down for a human to approve. Nothing in the pack authorises or executes a change in any tenant, and the artifact says so on its own face.
- The limits travel with the output. The portfolio page carries its own non-claims section: not complete discovery, not a live authorisation test, not exact application-to-mailbox mapping, not production-safe allow-listing, not outage prevention, not Microsoft certification, not proof of migration readiness.
- Decisions have owners. The decision register records who decided what and why, because the question a client asks six weeks later is never “what is the value”, it is “who decided this”.
If the format fits how you would have to defend the work, the next step is a written scoping: describe your estate, and you get a fixed price and a fixed scope back in writing.