Verdicts explained

You open the Trust Report to answer one question: is my data leaving to MIT? The hero card at the top of the report answers it in one word, with a colour and an icon — but a one-word answer is only useful if you know exactly what each word means and what you should do next. This page walks through the three verdicts the Trust Report can show — all-clear, attention, and alarm — so that when you see one, you know precisely what it is claiming and, if anything looks off, what to

You open the Trust Report to answer one question: is my data leaving to MIT? The hero card at the top of the report answers it in one word, with a colour and an icon — but a one-word answer is only useful if you know exactly what each word means and what you should do next. This page walks through the three verdicts the Trust Report can show — all-clear, attention, and alarm — so that when you see one, you know precisely what it is claiming and, if anything looks off, what to do about it.

The verdict is not a vibe. It is computed from the same append-only, hash-chained log you can read row by row in the Audit Log, classified against the seeded catalogue of known MIT endpoints (see Egress components). You never have to take the headline on faith — every verdict on this page is something you can drill into and check yourself.

The Trust Report with an all-clear verdict — the state you want to see day to day.

How to read the verdict card

Whatever the verdict, the hero card sits at the top of the report with the same companions, so learn them once:

• the hero verdict itself — the single word and colour;
• the trust chips just beneath it — Append-only log, Hash-chained, Bodies OFF, and Self-egress N, where N is the number of calls ever attributed to the auditor module itself (you want this to read 0);
• three summary cards — Total events, MIT-bound events, and Third-party events — and the Traffic distribution donut and Volume — bytes transferred bars that visualise the same split.

The verdict is driven mainly by two of those numbers: how much MIT-bound traffic there is beyond the license baseline, and whether Self-egress is anything other than zero.

The hero verdict and its trust chips — watch the Self-egress chip especially.

All-clear — what good looks like

This is the verdict you should see almost every time you open the report, and it is the whole point of the module.

What it means. The only traffic the auditor has attributed to MIT is the small license-validation metadata the platform sends to confirm your licence — nothing more. Your other modules are talking only to your own providers: your Gmail or IMAP server, your own OpenAI or LLM key, your Microsoft 365 — and those destinations are classified as third-party, not MIT-bound. The auditor itself has made no outbound call: the Self-egress chip reads 0.

What to do. Nothing — this is the resting state. If you want to confirm the claim rather than read the headline, that is encouraged:

1. Open the MIT-bound destinations panel and confirm the destinations are the expected license endpoints and the byte sizes are small.
2. Click Verify chain in the header to recompute the hash chain end to end; a clean run shows the toast "Audit chain verified OK — no tampering detected."
3. When you need an artefact for a colleague, an auditor, or your records, use Export signed proof to produce a signed JSON file a standalone verifier can check.

Attention — review it, don't panic

Attention is a "look at this" verdict, not a "something is wrong" verdict.

What it means. There is MIT-bound traffic above the license-only baseline — more than the small, steady license-validation metadata an all-clear shows. In ordinary operation this is most often an update check or a diagnostics call, but the auditor will not silently decide that for you: it surfaces the deviation so a human can look.

What to do.

1. Open the MIT-bound destinations panel and find the destinations driving the number up. Each is a click-through into the underlying rows.
2. For each one, check the Audit Log Forensic Record — the URL path, query keys, request and response sizes, the masked headers, and above all the attribution: which addon and author made the call, and from which call site. That tells you which module reached out and why.
3. Confirm the sizes match metadata, not payloads. Remember the auditor never stores bodies — but the size, timing, and attribution together are usually enough to recognise a routine update or diagnostics call.
4. If it reconciles with something expected (a version check after an upgrade, a diagnostics ping), you are done. If it does not — if a module is reaching MIT for a reason you cannot explain — capture a signed proof export and raise it with us.

The two destination panels — start in MIT-bound destinations when reviewing an attention verdict.

Alarm — the auditor called out, by design this is critical

Alarm is the one verdict the module treats as serious, and it is worth understanding exactly what triggers it, because it is narrower and stronger than it first sounds.

What to do — in order.

1. Verify the chain. Click Verify chain in the header. If the chain is intact, the alarm is real telemetry — the auditor genuinely recorded an outbound call attributed to itself. If verify() names a tampered row instead, you have a tampering finding as well; note the row it names.
2. Inspect the MIT-bound destinations table and the offending rows. Open each in the Audit Log Forensic Record and read the attribution and provenance: where did the call go, and from which call site inside the module was it made? The Chain Seq, Prev Hash, and Row Hash on that record place the event precisely in the tamper-evident chain.
3. Capture the evidence. Use Export signed proof to produce a signed JSON export over the affected window. It carries the signed_head and the chain_seq range, so the finding can be checked independently and cannot be quietly walked back later.
4. Escalate to MIT. Send us the signed export. A genuine alarm means the trust guarantee has been challenged on the one module that is supposed to be silent, and we want to see it.

The three verdicts at a glance

A frank word on what a verdict can and cannot prove

This module proves what it can observe. Its capture is deep — it reaches down to the socket layer — but it is a transparency and detection tool, not a formal sandbox or a guarantee against an adversary who manages to bypass a layer it does not hook. An all-clear is strong, honest evidence; it is not a mathematical proof that no path exists anywhere. We would rather say that plainly than oversell it.

It is also worth repeating that the auditor observes, attributes, and proves — it does not block traffic. It is not a firewall. A verdict tells you what happened and lets you prove it; acting on a bad verdict — investigating, escalating, changing a configuration — is still a human decision.

Related

• Reading the Trust Report
• Audit Log
• Export & verify a signed proof
• Egress components
• How it works
• Security & access