# FDPR is not really about where
FDPR is often explained as a technical rule.
Origin. Software. Production process.
That is all true.
But it is not the part that makes it difficult.
---
What makes FDPR difficult is this:
It forces you to stop thinking in terms of “where.”
---
A product can be designed, manufactured, and delivered entirely outside the United States.
And still be subject to U.S. export control.
At first, that feels counterintuitive.
Because most of us are used to thinking in geography.
Where it is made.
Where it is shipped from.
Whether it ever touches the United States.
---
FDPR does not follow that logic.
It follows dependency.
---
Not where the product is.
But what the product is built on.
---
And once you start looking at it that way,
the question changes.
It is no longer:
Is this product U.S. or non-U.S.?
It becomes:
What does this product rely on?
And more importantly:
What happens if you try to take that away?
---
Some dependencies are visible.
Others are not.
Some can be substituted.
Some cannot, at least not without time, cost, and redesign.
---
That is where the discussion starts to move.
Not just within legal teams,
but across engineering, sourcing, and management.
Because the answer is no longer in the text of the rule.
---
It sits somewhere else.
In how the product is designed.
In what tools are used.
In which parts of the process cannot easily change.
---
At that point,
FDPR stops looking like a classification problem.
It becomes a structural one.
---
And structure is a different kind of problem.
It is not something you verify at the end.
It is something you have already decided,
long before the legal question is even asked.
---
Which also means:
By the time the question comes to legal,
the answer may already be constrained.
---
FDPR is often treated as a rule to be applied.
But in practice,
it feels closer to a boundary you gradually discover.
---
Not where the line is drawn.
But where your product cannot move beyond.
