Why the Heppner discourse is drifting toward a technical category error
A thank-you to my mother—the one who built the early legal architecture at the kitchen table, and to the network that now keeps the structural cases in my line of sight.
Developers are used to seeing bad abstractions cause real-world failures.
The legal system is now running into one of its own.
In the discussion around U.S. v. Heppner, a subtle but important mistake keeps showing up:
People are treating "privileged when created" as a requirement for something to become privileged when sent to counsel.
That's not how privilege works.
It's not how any communication system works.
And it's not how engineers think about confidentiality.
Let's break down the technical version of the problem.
1. Privilege Attaches at Transmission, Not Creation
In engineering terms:
- A draft is a local artifact.
- Privilege is a property applied at the moment of secure transmission.
- The medium used to generate the draft is irrelevant.
If a defendant types notes in Word, those notes aren't "privileged when created." They become privileged when the user intentionally transmits them to counsel under a reasonable expectation of confidentiality.
This is the same pattern as writing a draft email, saving a local file, jotting notes in a text editor, or preparing a document before a meeting.
None of these are privileged at creation. They become privileged when used for legal advice.
This is the doctrinal equivalent of:
Encryption doesn't apply when you type the message—it applies when you send it through the secure channel.
2. The Medium of Creation Has Never Been the Security Boundary
Privilege doctrine has always been technology-agnostic.
Courts don't care whether you drafted your notes in Word, Google Docs, Notepad, a Markdown editor, or a physical notebook. Because the drafting environment is not the security boundary.
The boundary is: the intent to communicate with counsel, the confidentiality of the transmission, and the reasonable expectation of privacy.
This is the same model engineers use when distinguishing local state vs. transmitted state, draft artifacts vs. networked artifacts, and internal buffers vs. external exposure.
The tool is not the threat model. The channel is.
3. The Heppner Commentary Introduces a New, Unstable Category
Some commentary around Heppner implicitly assumes: AI-generated drafts are categorically different from Word drafts.
That assumption has no technical basis.
A private AI interaction runs under an authenticated account, is not broadcast, is not shared with other users, is not publicly visible, and is often more isolated than email or cloud docs.
Functionally, it's more private than most tools lawyers already use.
So why is AI being treated differently?
Because the discourse is confusing tool identity with system behavior.
This is the same mistake engineers see when someone assumes: "It's in the cloud, so it must be public."
No—the architecture determines exposure, not the branding.
4. The Real Structural Error: Treating Boilerplate as System Behavior
The government's argument in Heppner—and the way it was accepted—rests on a category collapse:
Privacy policy language = actual disclosure = no confidentiality.
This is the equivalent of treating a permissive EULA, a broad ToS, or a generic "we may use your data" clause as if it were a runtime trace proving exposure.
Engineers know better:
- A risk wrapper is not a data flow.
- A liability disclaimer is not a telemetry log.
- A ToS is not a packet capture.
If courts start treating boilerplate as evidence of disclosure, then Google Docs becomes suspect, Office 365 becomes suspect, Slack becomes suspect, and every cloud-hosted workflow becomes suspect. Because all of them contain similar "we reserve rights" language.
This is not a legal problem—it's a misread of system architecture.
5. The Correct Technical Model: Purpose + Confidential Channel
Privilege attaches when the user creates material for the purpose of obtaining legal advice, and the material is transmitted through a channel with a reasonable expectation of confidentiality.
This is the same pattern as encrypt-on-send, secure RPC, TLS handshake, and authenticated session channels.
The drafting environment is not the security boundary. The transmission environment is.
If that's true for Word, it must be true for AI—unless we're prepared to invent a new category of "AI-tainted drafts," which has no technical or doctrinal foundation.
6. Why This Matters for Developers
If courts start treating AI tools as inherently non-confidential, developers will be forced into absurd design constraints: "privileged mode" editors, "lawyer-only" AI instances, "no AI allowed" enterprise policies, fragmented drafting workflows, and bespoke legal-safe sandboxes.
All because of a misunderstanding of where confidentiality actually lives.
The risk isn't AI. The risk is misclassifying the boundary.
7. The Bottom Line
If you're a developer, architect, or engineer, the Heppner drift should concern you because it introduces a precedent where tool identity overrides system behavior and boilerplate overrides actual privacy posture.
That's not how we design systems.
It's not how we reason about confidentiality.
And it's not how privilege doctrine has ever worked.
The medium of creation has never been the test.
The purpose and expectation at transmission have always been the test.
If courts forget that, the entire digital workflow stack becomes unstable.
For the full structural analysis and the proposed Substrate Test for preventing doctrinal drift in digital confidentiality rulings, see When Courts Mistake Boilerplate for Reality on Substack.
Top comments (1)
I'm not sure, but it seems to me that this Heppner discourse is raising some really interesting questions about what it means for something to be confidential. The idea that courts are treating AI-generated drafts as inherently non-confidential because they're created by a machine just feels off to me - like they're misunderstanding the whole point of privilege in the first place. It makes me wonder what kind of absurd design constraints developers will have to navigate as a result.