"Something feels off about this claim. But I cannot tell you where it came from."
A senior attorney said that to me in a demo. She was looking at a draft produced by one of the better-known AI patent tools; a draft that was, by all surface measures, very good. The structure was sound. The language was dense and technical in the right places. The claim hierarchy made sense.
But she could not trace a specific limitation in claim 1 back to the disclosure. She did not know if the AI had inferred it, assumed it, or found it in a part of the document she had not noticed. So she did what any careful attorney would do. She went back to the disclosure and read it again, manually, to find out. It took twenty minutes.
That is not a minor inconvenience. That is the tool transferring its verification burden onto the person it was supposed to be helping.
Why this matters more in patent law than anywhere else
In most professional contexts, an output you cannot verify is frustrating. In patent law, it is something else entirely. Every word in a patent claim is a legal position that will be held, challenged, and potentially litigated. Every element in the description is either building an evidentiary record or creating an unnecessary limitation. If the AI made an assumption; and it will, because that is what language models do when faced with incomplete information; that assumption is now in a document that will be examined, analysed, and cited for the next twenty years.
The problem is not that the AI was wrong. It might not have been. The problem is that you cannot tell. And in a domain where precision is not a preference but a professional obligation, "you cannot tell" is not a risk you accept.
"An accountant who hands you a tax return without showing their working is not being efficient. They are asking you to trust them blindly in a context where blind trust is specifically what you cannot afford."
What black-box AI looks like in practice
Most AI drafting tools share a structural problem. They are built to produce outputs, not to explain them. They have been trained on enormous volumes of patent text; they have learned, with real sophistication, what a patent sounds like. But they have not been built to show their work.
When you upload a disclosure to one of these tools, a number of things happen inside that you cannot see. The system identifies what it thinks are the key inventive elements; it makes decisions about claim scope; it chooses language. None of those decisions are visible to you. The output just appears. And if something is wrong; or even if something is subtly different from what you would have chosen; you have no trail to follow back to the source of the decision.
This is not a minor UX issue. In patent drafting, every decision has a reason. The reasons matter. And a tool that cannot give you the reasons is asking you to adopt its conclusions without being able to evaluate them.
What Checkable actually means in eety
When I built eety, I started with one constraint: the attorney should always be able to see where something came from. Everything else followed from that.
Checkability in eety has four concrete expressions:
- Source-mapped understanding. Every insight in the invention model is traced back to the specific part of the disclosure it came from. When eety identifies a novel element, it shows you the line. When it draws a conclusion about the technical problem, it points to the passage that grounded that conclusion. Nothing is inferred without a visible source.
- Open questions surfaced, not filled. When eety encounters a gap in the disclosure; something it cannot ground in the text; it does not fill the gap with an assumption. It surfaces it as a targeted question. The attorney sees exactly where the uncertainty is and what information would resolve it. The AI does not guess in the dark and hope you don't notice.
- Plan approval before drafting begins. Before eety writes a single word of a patent, it presents the drafting plan to the attorney. The claim architecture, the section order, the structural decisions. The attorney reads it, challenges it if needed, and approves it. Nothing proceeds without that gate. The plan is not a formality; it is the point at which the attorney takes ownership of the direction.
- Diff history on every change. When eety modifies a section; whether in response to a chat instruction, a file upload, or a section-specific refinement; it records exactly what was there before and what replaced it. The attorney can see the before and after at any point. Nothing is silently overwritten.
"A junior associate who silently guesses and gets it right most of the time is a liability. The one who says 'I was not sure about this part, so I flagged it' is actually useful."
The deeper reason this pillar comes first
I put Checkable first in the CARE framework not because it was the most requested feature; it wasn't. Most attorneys using AI tools are not initially asking for traceability. They are asking for speed, and then quality, and then ease of use. Traceability shows up later, usually after the first time an unverifiable output causes a real problem.
I put it first because without it, none of the other pillars mean much. Adaptive output that you cannot verify is just well-styled guessing. Retentive memory of decisions you cannot trace is just persistent confusion. Editable sections you cannot audit are just changes made to a document whose provenance you don't understand.
Checkable is the foundation. Everything else is built on top of it.
You would not accept a draft from a junior associate who could not explain any of their choices. The fact that the tool produced it faster and at lower cost does not change the standard. It only makes it easier to forget that the standard exists. :)
See It In Action
Watch eety.ai surface open questions and show its working before drafting a single word.
Try It Free →