The constraint that shaped your design - order records must stay inside the country - came from a conversation with the VP who commissioned the work. She leaves in month three. What happens to the design next and what should have been in place?

What happens next

Week one after the handover, the new VP reads a design with regional isolation that costs roughly 30 to 40% more in infrastructure than the single-region alternative, and asks why. Your honest answer is "I was told". From there the system takes one of two paths, and both are bad.

The constraint is removed. It looked like an unjustified cost with no owner, so it goes, and the design is simplified. You find out whether it was real at the next audit, or when a customer's procurement questionnaire asks, or from a regulator — which is to say, at the point where the fix costs a data migration rather than a design choice.

The constraint survives and hardens. Nobody will take the risk of deleting a rule whose origin is unknown, so it stays, and it propagates. Within a year three later designs carry regional isolation because "that is how we do order data", and the original question is unanswerable. This is the normal end state, and it is why undocumented constraints are permanent: a constraint with provenance can be renegotiated, folklore cannot, because renegotiation requires someone who knows what it was for.

Why the design cannot defend itself

A constraint stated verbally has no owner after the speaker leaves, which means the design's most expensive structural decision rests on the memory of one person who is no longer accountable for it. The failure is not that the VP left; it is that the constraint's cost was permanent while its justification was not durable.

What stops it

Constraint provenance, applied only to the constraints that changed the structure — typically three to six in any design. Each one carries a single line: the artefact, the owner, the date confirmed.

Order records remain in-country. Source: Clause 7.3 of the 2025 data-residency policy, document ref DP-114. Owner: Head of Legal. Confirmed 12 March. Review when the policy is reissued.

The falsifiable test is blunt: for each of your top five constraints, can you produce the artefact in under 60 seconds? If not, it is a belief you are spending money on.

The move that gets you there costs one email. State the assumption back as a declarative sentence rather than asking an open question: "I am designing on the basis that order records cannot leave the country, which adds a second region and roughly 35% to the infrastructure line. Confirm or correct." People correct a wrong statement; they do not answer "what are the data requirements?". A reply saying "check with legal" is itself provenance, because it tells you who owns the answer. Total cost: an hour a project, and the occasional discovery that nobody actually requires the thing, which saves a quarter.

When this is the wrong answer

On a two-week internal tool, chasing written provenance costs more than the constraint it protects. And provenance applied to every constraint turns into a compliance ritual that people fill in without checking, which is worse than nothing because it looks like evidence. Apply it to the constraints that cost money or foreclose options, and leave the rest as design notes.

Common weak answers

• "Document the requirements properly at the start." Requirements documents record what was said, not who owns it and what artefact it came from. The missing field is provenance, and it is one line per constraint rather than a document.
• "Escalate to get a written policy before designing." Sometimes right, usually a way of waiting. The design has to start, so write the assumption down, mark it unconfirmed, and keep designing while the confirmation is in flight. An unconfirmed constraint that is visible is safe; an unwritten one that is confirmed in a corridor is not.