Assumption Mapping: Surfacing Hidden Premises in Legal Positions

You’re three weeks into negotiating a licensing agreement. Terms are nearly finalized. Then someone asks: “Wait, what happens if they get acquired?”

Silence.

Turns out your client assumed the license was personal to the licensee. Their counsel assumed it would transfer to any successor. Nobody said it explicitly. Now you’re reopening negotiations on what should have been paragraph two.

This happens constantly in legal work. We operate on unstated premises—about risk allocation, timing, materiality, what’s “standard.” Then we discover the other side was working from completely different assumptions. Usually too late.

Here’s what most lawyers miss: AI is exceptionally good at surfacing assumptions you didn’t know you were making.

Not because it’s smarter than you. Because it’s not embedded in your context. It sees the gaps you’ve stopped noticing.

The Concept

Assumption mapping is exactly what it sounds like: identifying every premise underlying a legal position, argument, or transaction structure. The obvious ones and the invisible ones.

In practice, this means:

• What are we taking for granted about how this will work?
• What has to be true for this approach to succeed?
• Where are we filling in blanks without realizing it?

You already do this mentally. But your brain can only hold so many variables at once. And you’re too close to your own reasoning to see all the assumptions baked into it.

AI can hold more variables. And it has no ego investment in your brilliant strategy.

The Prompt

Concrete Example

Scenario: You’re representing a SaaS company in a strategic partnership. The partner will integrate your software into their platform. You’re negotiating the revenue share agreement.

Your proposed term: “Partner shall pay Company 30% of net revenue generated from customers acquired through the integration, calculated and paid quarterly.”

You run the prompt. Here’s what the AI surfaces:

EXPLICIT ASSUMPTIONS:

• Revenue share is 30%
• Calculation basis is “net revenue”
• Payment is quarterly
• Only applies to customers “acquired through the integration”

IMPLICIT ASSUMPTIONS:

• “Net revenue” means the same thing to both parties (it often doesn’t—does it include refunds? Credits? Payment processing fees?)
• “Customers acquired through the integration” has a clear definition (What if customer heard about it through integration but signed up directly? What if they were existing customers who upgraded?)
• Partner will track and report these metrics accurately
• Partner’s accounting systems can actually separate these revenue streams
• Quarterly payment timing is acceptable to your client’s cash flow
• The integration will remain substantially similar over time
• There’s no scenario where the partner’s customer becomes your direct customer later

STRUCTURAL ASSUMPTIONS:

• The partnership will be successful enough to generate meaningful revenue
• Partner won’t restructure in a way that makes “net revenue” meaningless
• Your company will have audit rights (not mentioned in the term)
• Disputes about calculation won’t tank the entire relationship
• Neither party will be acquired or restructured in a way that affects this obligation

AI flags three critical gaps:

1. “Net revenue” needs explicit definition - Your client thinks it means gross minus payment processing. Partner might think it means gross minus payment processing, customer acquisition costs, allocated overhead, platform fees…

2. Attribution is ambiguous - “Acquired through the integration” will cause disputes. You need explicit rules: first-touch attribution? Last-touch? Does partner decide?

3. No audit rights mentioned - Your client has no way to verify the calculations. This needs to be explicit or the revenue share is unenforceable in practice.

You revise the term. Add definitions. Add audit rights. Add attribution rules. You catch three potential disputes before they happen.

When to Use This

Deploy assumption mapping when:

• Negotiating any agreement - Before sending terms, before responding to their draft
• Reviewing deal structures - Especially complex or novel arrangements
• Planning litigation strategy - Before committing to a legal theory
• Client intake - When client explains what they want, map what they’re assuming
• Internal team alignment - When multiple people are working on the same matter
• Due diligence - To identify what the other side might be assuming about your client

The earlier you do this, the better. Assumptions are easiest to fix before they’re embedded in documentation or strategy.

Why This Works

Lawyers are trained to spot issues in other people’s work. We’re less good at spotting gaps in our own thinking. We know what we meant. We filled in the blanks unconsciously.

AI doesn’t know what you meant. It only sees what you said. That’s the feature, not the bug.

This isn’t about AI replacing legal judgment. It’s about using AI to pressure-test your judgment before reality does.

---

We’re building Mino for lawyers who think like this—using AI as a reasoning partner, not just a drafting tool. If you want to work through legal problems with specialist agents designed for exactly this kind of thinking, join the founding members list.

I need you to map all assumptions embedded in the following legal position/transaction structure/argument:

[DESCRIBE YOUR SITUATION - include relevant facts, proposed terms, strategic approach, or legal theory]

Analyze this at three levels:

1. EXPLICIT ASSUMPTIONS: What am I stating directly as premises or conditions?

2. IMPLICIT ASSUMPTIONS: What am I taking for granted without saying it? Look for:
   - Assumptions about how parties will behave
   - Assumptions about timing, sequence, or dependencies
   - Assumptions about what's "standard" or "reasonable"
   - Assumptions about risk allocation or responsibility
   - Assumptions about future events or market conditions
   - Assumptions about legal interpretation or enforcement

3. STRUCTURAL ASSUMPTIONS: What has to remain true for this entire approach to work? What would break it?

For each assumption you identify:
- State it clearly
- Assess: Is this assumption shared by all parties, or just us?
- Flag: What happens if this assumption is wrong?
- Suggest: Should this be made explicit in documentation?

Be thorough. Find the assumptions I'm not seeing.