Three weeks into a licensing negotiation, terms nearly settled, someone asks: “what happens if they get acquired?” Silence. Your client assumed the licence was personal to the licensee. Their counsel assumed it transferred to any successor. Nobody said it. Now you are reopening what should have been paragraph two.
This is the ordinary failure mode of legal work. We run on unstated premises — about risk allocation, timing, what counts as “standard” — and only discover the other side was working from different ones when it is too late to fix cheaply. You already check for this mentally. The limit is that you can hold only so many variables at once, and you are too close to your own reasoning to see the assumptions baked into it.
A model is not smarter than you here. It is just not embedded in your context. It only sees what you wrote, not what you meant — and that is exactly why it catches the gaps you have stopped noticing.
The prompt
Map every assumption embedded in the position, structure, or argument
below:
[describe the situation — relevant facts, proposed terms, strategy,
or legal theory]
Work at three levels:
1. EXPLICIT — what am I stating directly as premises or conditions?
2. IMPLICIT — what am I taking for granted without saying it? Look at:
assumptions about how the parties will behave; about timing and
dependencies; about what is "standard" or "reasonable"; about risk
allocation; about future events; about how the law will be applied.
3. STRUCTURAL — what has to stay true for this whole approach to work?
What would break it?
For each assumption: state it, say whether it is shared by all parties
or only us, flag what happens if it is wrong, and suggest whether it
should be made explicit in the documentation.
Find the assumptions I'm not seeing.What comes back
Take one revenue-share term in a SaaS partnership: “Partner pays 30% of net revenue from customers acquired through the integration, calculated quarterly.” Clean enough. Run the prompt and the implicit layer fills up fast.
“Net revenue” means the same thing to both parties — except it rarely does. Does it net out refunds? Payment processing fees? Allocated overhead? “Customers acquired through the integration” assumes a clear definition, but what about a customer who heard about it through the integration and signed up directly, or an existing customer who upgraded? And the term assumes the partner can even separate these revenue streams in their accounting — and that your client has audit rights, which the clause never mentions.
Three concrete gaps surface: define “net revenue”, write explicit attribution rules, and add audit rights or the share is unenforceable in practice. You catch three future disputes before they are embedded in a signed document.
When to run it
Before you send terms or respond to a draft. Reviewing any novel or complex structure. At client intake — when the client explains what they want, map what they are assuming. And before committing to a litigation theory, to see what the other side might be assuming about your client.
The earlier the better. Assumptions are easy to fix while they are still words in a draft, and expensive once they are load-bearing in a strategy. Lawyers are trained to spot issues in other people’s work and are weakest on their own, because we know what we meant and filled in the blanks unconsciously. The model does not know what you meant. That is the feature.