One of the hardest parts of security is explaining a finding to the people who have to act on it, and most of them are not technical. Legible studies how that second telling is done, by collecting pairs of the same thing written twice, once for the engineers and once for whoever has to decide. Out of those pairs comes a rubric: a written list of what a retelling has to carry over from its source and what it owes the person reading it, where every item says how it can be checked and how far that check can be trusted. Three instruments run on it. A reviewer that checks a draft against the finding it came from. A benchmark that measures how much a language model drops when it writes the summary itself. A search for how the field has already explained something like it.
In 2023 a China-based group known as Storm-0558 broke into email accounts at the US State and Commerce Departments through Microsoft’s cloud. The review board’s report explains the cause twice, once for engineers and once for leadership.
The flaw was caused by Microsoft’s efforts to address customer requests for a common OpenID Connect (OIDC) endpoint service that listed active signing keys for both enterprise and consumer identity systems. However, Microsoft had not adequately updated the software development kits (SDKs), which Microsoft and its partners both used, to differentiate between the consumer MSA and the enterprise signing keys within the common endpoint. As a result, this allowed successful authentication to the Entra system for certain applications, such as mail, regardless of which key was used.
Signing keys, used for secure authentication into remote systems, are the cryptographic equivalent of crown jewels for any cloud service provider. [...] In fact, when combined with another flaw in Microsoft’s authentication system, the key permitted Storm-0558 to gain full access to essentially any Exchange Online account anywhere in the world.
Security work ends in a retelling. A finding written for engineers has to be explained again to a board, a regulator or a customer, and when that retelling fails nobody notices, because the reader only ever sees the retelling.
The audience matters. None of these is necessarily wrong. The audience decides what a retelling has to carry, so the same omission can be right for one reader and a failure for another.
Legible finds a technical finding, and the version of it written for an audience that will not read the technical text. Both halves are quoted exactly as they were published.
Some of the shapes a pair can takeBoth halves inside the same report: the detailed version, and the retelling written for whoever commissioned it. The most common shape.
Two separate publications about the same incident, written for different readers and released at different times.
A written record on one side, and the message somebody sent about it on the other. A handover, an email, a note upward.
A technical concept, and the plain-language image somebody else wrote to explain it. Different authors, no shared document.
All of it comes from writing already published in the open. Each pair keeps its document, link and licence.
A model was used to point at passages. The code kept a passage only if it was really in the document.
The corpus is not a finished set. Once it is open, other people can add to it.
The rubric defines what a security explanation needs to get right. It asks whether the text preserves the finding’s meaning and whether it gives its intended reader the information they need. Those are different questions, so the answers stay separate.
Its eight dimensions draw on two sources: what professionals actually wrote in the corpus, and 237 industry documents about how security should be communicated. The priorities change with the reader and the situation.
Same finding. Different reader.A board briefing needs the consequence, the current risk, and what needs a decision. An engineering ticket needs the affected component and a fix the engineer can verify.
Faithful can still be unhelpful.Both texts must preserve the facts that matter. But copying the same technical detail into both does not make them equally useful. The rubric assesses each against its own reader’s needs.
Did it keep faith with the source? Numbers, severity, scope, caveats, what is still unknown.
Is it any use to the reader? Their questions answered, their language, something they can act on.
Select a dimension to see its checks. These describe the full instrument; the preview below covers only part of the rubric.
Check explicit details in the text.
show the wording behind each findingEstimate whether a claim is supported by its source.
report confidence and the passage assessedOffer an opinion on what rules cannot settle.
quotes must match the source; opinions adviseLeave judgment with a person when it cannot be automated.
unexamined does not mean correctThe rubric is still being calibrated. Its eight dimensions define the intended assessment; an automated check does not reach every dimension. The reviewer and benchmark must state what they examined and what remains for a person to judge.
Put a finding beside the explanation you are writing. The reviewer points out what changed, shows the source behind each concern, and helps you decide what to revise. Try the worked example, or paste your own two texts.
Illustrative finding · written for this demo
Edit the explanation. Follow the evidence.
How well do language models preserve a security finding when they explain it to someone else? Each model receives the same finding and the same intended reader. The briefing it writes is then assessed against the Legible rubric.
STUDY DESIGN · BENCHMARKING LLM FIDELITY IN EXECUTIVE SECURITY BRIEFS
The rubric defines what to assess. The research is determining how reliably each part can be measured. Results will identify the checks used, their measured ability to catch errors, and what still requires judgment.
Paste a finding and get back real pairs from the corpus: findings like yours, and the summaries professionals actually wrote from them. Ask for a concept instead and it returns the definitions, plain-language explanations and analogies the field has already used for it. It is precedent, not a set of approved answers, and every result shows exactly what matched and where it came from.
A sample of 12 public pairs. The full library searches every shareable pair in the corpus, ranking exact identifiers first and then shared terms.
Legible is still being built. When it is ready, the corpus, the rubric and the three instruments will be released as an open-source project, so any security team can check its retellings, test the models it relies on, and learn from how the field already writes.
A larger corpus from more kinds of source, every pair traceable to the document it came from and shared under its own license.
Weights checked by hand against real pairs, so what fails a text is grounded in how the field actually writes.
The reviewer, the benchmark and the search, open and running in your browser or on your own machine, so findings never have to leave it.