Every program starts with a list. Somebody reads it out at kickoff — operating temperature, mounting standard, enclosure material, ingress rating, the depth the product is allowed to be.

The list gets discussed. What almost never gets asked is where each line came from.

Some of it is physics. Some is a customer contract. And some is on the list because it was on the last list, and at some point a decision that was correct in 2016 stopped being a decision and became the shape of the problem.

That third kind is the expensive one, and it's invisible for a reason: nobody argues with the shape of the problem. An inherited constraint doesn't present itself as a choice someone made. It presents itself as the ground you're standing on.

Three kinds, one audit

Pull a constraint list apart and it sorts into three piles. Physical and regulatory. Commercial. And inherited — the mounting architecture from the last generation, the wall section unchanged since the tooling was cut, the proportion, because that's what this category looks like.

All three constrain the design equally. Only the first gets audited, because it's the only one with a document behind it. Only the third is free to change.

The best instincts produce the most of these

In a lot of hardware categories, the people who built the category are still running it. They know the end user. They know what fails in the back of a vehicle at three in the morning in February. That knowledge is the moat.

It's also what hides inherited constraints. The intuition is good enough that nobody has needed to check it, and being usually right is what stops anyone asking about the times you weren't.

So the differentiation conversation happens, genuinely — but inside a frame nobody questioned at kickoff. Every option on the table is a variation within the inherited envelope. The team isn't failing to think creatively. They're thinking creatively inside a box they don't see.

Ranking is the audit

There's a way to surface this that doesn't require anyone to go hunting for assumptions. It falls out of a different exercise.

Before solving any of them, split the constraints in two. Coupled constraints close doors when you commit — lock the enclosure split and you've limited where the mount can go. Those get ranked, ordered by how much downstream freedom each one removes. Checklist constraints foreclose nothing, and can be solved in any order once the stack is settled.

Here's what makes it an audit. You can't rank a constraint without saying what it forecloses, and you can't say what it forecloses without saying why it's on the list at all.

So the first time a team ranks honestly, someone asks out loud why the mounting architecture is fixed. Not as a challenge — as a requirement of the exercise. The answer is either a document, a customer, or a shrug. The shrug is the finding.

Competitive or inherited

Most inherited constraints are load-bearing, and a team that throws them out to prove a point rediscovers why they were there. The point isn't that they're wrong. It's that you can't tell which is which until someone asks.

Worth asking on the next program: which of your constraints are actually competitive, and which ones are just inherited?

The distinction matters most before the decisions get made, not after them.

Every team we work with has one constraint they inherited and can't defend. If you already know which one yours is, that's the conversation.