In one of these engagements, we reverse-engineered the 36 wireframes they had already produced.

Out of that: 8 use cases the wireframes assumed but never stated. 14 business decisions the screens silently depended on. And of the 9 decisions foundational enough that nothing should be designed without them - 5 were still open. Not "open" as in under discussion. Open as in: the team was designing and building on top of them, and nobody had noticed they weren't decided.

The product's entire value is a compliance percentage. Clients log in to see how many of their vendors are compliant. The dashboards were designed. The number was everywhere.

The formula behind the number did not exist.

Does a "Waived" requirement count as compliant? Does "Pending Review" count as non-compliant, or is it a third state excluded from the math? Does an expired document flip a vendor instantly, or is there a grace period? Is the percentage calculated per project, or per client relationship, or both?

Every one of those is a business decision. Each one changes the number a customer sees. None had been made. And screens were already being designed to display that number.

That is one decision. There were thirteen more like it.

These were not oversights by careless people. The team is competent, all senior. The gap is that the work split into layers people own, and the layer in the middle has no owner.

The data layer - owned by developers - is what entities exist and how they are stored. Documents, records, requirements, projects.

The interface layer - owned by designers - is what the user sees and clicks. Screens, flows, components.

Between them sits the product-logic layer - what the data means and how it behaves. What the word "compliant" resolves to. What states a document moves through and what triggers each transition. What "version" of a document means when two of them exist at once. Whether the AI's verdict and a human reviewer's verdict are the same field or two different ones.

The product-logic layer is not data and it is not interface. It is the rules that connect them. And in most companies nobody owns it.

The developer assumes product has defined it. Product assumes the logic will emerge from the screens. The screens get designed around assumed logic. The developer builds from the screens. The assumptions get hardcoded. And the product-logic layer gets "decided" - not in a decision, but as an accident, scattered across wireframes and one person's implementation choices.

This is how the bugs get built in.

A scope document describes intent.

Wireframes describe the interface.

Code is the data layer.

The product-logic layer lives in the gaps between those three documents - and gaps do not show up in a review. Everyone inspects their own artifact, confirms it is correct, and signs off. The product still ships broken, because the thing that was wrong was not in any single artifact. It was in the space between them.

You find out at the worst possible time: when a customer asks why their compliance number looks wrong, and three people give three different answers about how it is calculated - because it was never decided, only implemented.

But we don't just list a team's assumptions; we run them through a meat grinder. Anyone - or any generative AI - can produce a clean-looking list of product rules on demand. A document, as a document, is not valuable.

For every open question, we don't write down the first consensus answer. We actively try to destroy the emerging conclusion. We test every rule against the hardest counter-evidence available - worst-case database constraints, the way the last version failed, the edge cases nobody wants to think about.

This contradiction-testing is what separates an unverified opinion from a locked decision. Once a business rule survives that level of internal assault, it becomes a decision the executive team can finally commit to and stop debating.

The screens come after. They are faster to design, and they are correct - because they were drawn on top of locked, validated decisions instead of blind assumptions.

By pulling the product-logic layer out of the shadows, we deliver a concrete target state. It is a decided end state. When the pre-build phase wraps up, the executive team walks away with a decision log - every structural call named, dated, and signed off by your team - and a product model your developers build from.

One question tells you whether your rebuild is exposed.

Pick the single most important number or status in your product - the one your customers log in to see. Now ask three people on your team, separately, to write down exactly how it is calculated, or what it means.

If the three answers do not match, you have found your product-logic layer. It exists. It is just not owned, not written down, and being hardcoded into your rebuild right now - the same way it was last time.