Confidentiality
Every engagement is confidential from the first message, and it stays confidential after the engagement ends. Client names, organizations, findings, documents, and the fact that an engagement exists at all are never shared without prior written permission naming exactly what may be shared, with whom, and in what form. Permission is the client's to give, and without it the answer is no.
The commitment
Most confidentiality language is satisfied by good intentions. These are the rules this practice runs on, written so that a client can hold me to them.
Not the client's name. Not the organization. Not the sector, the size, or the region, where naming those would identify it. Not a finding, a document, a figure, a slide, or a quotation. Not the fact that an engagement exists.
Before anything leaves an engagement I ask, in writing, for three things: the exact material, the exact people who will receive it, and the exact form and setting it appears in. Approval to mention the work is not approval to share it.
A yes for one conversation is not a yes for the next one. Permission covers what it names and nothing adjacent to it, and it can be withdrawn at any point without a reason being offered.
An anonymized case study is still the client's material. In a field where the practitioners largely know each other, anonymous describes the text and not the reader's ability to place it. Removing the identifying details does not replace the permission step; it takes the same explicit approval.
It does not lapse when the engagement closes, when the client's leadership changes, or when the work would have made a useful example. There is no expiry on it.
The case files, the patterns, the Lab organizations, and the evidence behind them are built from the published record. Engagement material is held separately from all of it, and it does not cross over on its own.
Why
Current AI governance rests on artifacts that only work when they are candid. A safety case is a structured argument that a particular deployment is acceptably safe in the conditions it actually runs in, and the part of it that carries weight is the part that states where the argument is weakest. Protected near-miss reporting rests on what aviation and clinical medicine settled decades ago: people report what nearly went wrong when reporting is protected, and they stop when it is not. Independent evaluation of capable systems runs on negotiated, structured access rather than on unilateral disclosure, for the same reason.
The work I do asks an organization to show me the distance between its stated safety position and its operational reality: the workaround that quietly became the process, the review that is scheduled but not happening, the incident nobody wrote up because writing it up would have started something. No organization shows that to someone who might publish it.
So a practice that treats client material as marketing does not end up with better evidence. It ends up with the findings that were safe to hand over, which are the findings that did not matter. Confidentiality here is not a cost paid against the quality of the work. It is the condition under which the work has anything true in it.
So the default is silence, and the client's permission is the only thing that changes it.
What is public
Everything published on this site is built from the record that is already public: peer-reviewed literature, regulator and inspector findings, court and audit records, and reporting, with each empirical claim tied to its source in the Evidence Registry. The case files in the Domain Atlas are documented public incidents. The patterns in the Practice Library come from the PAN framework's lever catalog and those same documented histories. The model organizations in the PAN Lab are calibrated to publicly documented deployments. Engagement material is held apart from all of it.
The organizations named anywhere on this site are places Stephen Lieberman has worked, programs he has led, or cases already in the public record. None of that is a client list.
Handling
Questions about any of this, before you write anything substantive, are welcome. Send them to Stephen@Paramerge.com.
Everything on this page already covers the first message. Say as much or as little in it as you want to.
Work With Paramerge
