The spec became folklore: what happens when the requirements author rolls off

Here is the week you just had. A renewal lands for a platform bought nineteen months ago. You open the requirements matrix from the original sourcing exercise and find a line marked MUST: dedicated tenancy, no shared instance, no exceptions. The vendor is now offering a 22 percent reduction if you move onto their multi tenant tier. You want to say yes. You cannot, because you do not know what that must-have was protecting. The engineering lead who wrote it left in March. The security architect who briefed her moved to another business unit. The person who signed the scoring sheet says, honestly, that she was approving a process rather than a position. So the requirement stands, unexamined, and you pay to preserve a constraint nobody in the building can explain. That is not a governance failure in the audit sense. Nothing was falsified and nothing was hidden. It is a memory failure, and it costs real money at renewal.

How a requirement turns into folklore

Requirements are written in compressed form on purpose. A sourcing matrix has room for a line, not an essay, so an entire negotiation with your own security team gets flattened into four words. That compression works while the author is present, because the author is the decompression engine. Ask her what dedicated tenancy meant and she will tell you it was really about a specific data residency clause in one customer contract, that shared tenancy would have been fine everywhere else, and that she had already agreed a fallback with legal. None of that is in the document. It lives in her head, in a Slack thread, and in a meeting that was never minuted.

When she leaves, the four words remain and the decompression engine goes with her. What is left behaves exactly like folklore. It is repeated with confidence, its origin is unknown, and challenging it feels risky because the person challenging it cannot prove the requirement was ever soft. So the safe move is to treat every inherited must-have as load bearing. Multiply that across a portfolio and you are carrying a set of constraints whose combined price nobody has ever totalled.

Most requirements were written by proxies in the first place

The turnover problem is worse than it looks, because the author usually was not the requirement owner. In most enterprise sourcing exercises a procurement lead or a business analyst gathers needs from five or six stakeholders and writes them down on their behalf. That is proxy authorship. The proxy makes dozens of small judgement calls while translating: which of two conflicting asks wins, whether a preference is a preference or a hard floor, how to phrase something so the vendor cannot game the scoring. Every one of those calls is a decision, and almost none of them are recorded as decisions.

So when the proxy rolls off, you lose two layers at once. You lose the reasoning behind the requirement and you lose the reasoning behind the phrasing of the requirement. The stakeholders who supplied the raw need are often still around, which creates a false sense of recoverability. You go and ask them. They tell you what they want today, which is not what they wanted then, and they say it with the confidence of someone who assumes their current view was always their view. Now you have a second version of the spec, undated, competing with the first, and no way to tell which one the contract was priced against.

Why nobody fixes this with better documentation

Every organisation that has been burned by this responds the same way. Someone proposes a richer requirements template with a rationale column. It works for one sourcing cycle. Then it stops, for three predictable reasons. First, the rationale column is filled in at the moment of least knowledge, at intake, before the market has told you which requirements are expensive. Second, it is never updated, so by signature the document describes a position that changed four times in negotiation. Third, it lives in a file, and files are not queryable. Nobody at renewal is going to open a nineteen month old document and read the rationale column, because they do not know it exists.

The deeper issue is that documentation captures state and what you need is history. You do not want to know what the requirement said. You want to know what it said originally, what it became, who changed it, when, and against what evidence. That is a decision record, not a document, and it is the same instinct behind the audit trail. The audit trail answers who saw what and why. Requirement provenance answers who decided what and why. Both fail for the same reason, which is that the reasoning is stored in humans and humans move.

The platform motion: rationale captured at intake, queryable at negotiation

The mechanism is simple to describe and it only works if it happens automatically. When a request enters the platform, the AI analyst conducts intake as a conversation rather than a form. It asks what the requirement is, who needs it, what breaks if it is not met, and what the acceptable fallback is. That last question is the one humans skip and the one that matters most eighteen months later. The answers are written into a persistent deal record, attributed to a role and a person, timestamped, and attached to the specific requirement rather than dumped into a general notes field.

From there the record accumulates rather than resets. When a requirement softens during evaluation because two of three shortlisted vendors cannot meet it, that softening is a logged decision with a reason. When a security review adds a condition, the condition arrives with its trigger. When the war room agrees a landing zone and trades a nice-to-have for a price concession, the trade is recorded against both items. Six specialist agents work the deal and each writes back into the same record, which is what stops the history fragmenting across tools. Read the negotiation war room for how the mandate and concession ladder get set, and note that the ladder itself is provenance: it says which requirements you were prepared to lose.

Then the record becomes an input rather than an archive. At renewal you do not open a folder, you ask a question. Which of these requirements were marked hard at intake and never tested in the market. Which were relaxed and by whom. Which requirement is the only reason we are on the premium tier. Because the deal record is structured and queryable, the answers come back with citations to the original intake notes and the dates they changed, and they flow straight into the Negotiation Dossier so the counter offer argues from your own recorded history rather than from institutional memory that no longer exists.

What this does not solve

Be clear about the boundary. The platform cannot recover rationale that was never articulated. If a requirement was invented in a corridor in 2021 and written down by someone who has since left, no system can retrieve the reason, because the reason was never expressed in any medium. What the platform does is stop the bleeding from today forward. Deals that go through intake now carry their reasoning. Deals signed before that do not, and for those you still face a manual reconstruction, only once, with the difference that the reconstruction is captured properly rather than repeated every eighteen months.

It also cannot force honest intake. If a stakeholder marks nine items mandatory because that is how they protect their position internally, the record will faithfully preserve nine mandatory items with thin justifications. The record makes the thinness visible, which is useful, but it does not resolve the underlying politics. A requirement that exists to protect a budget line rather than a capability is a management problem and it stays one.

And it does not replace the conversation with the current owner. Business needs move. A requirement that was correct at signature can be obsolete at renewal for reasons that have nothing to do with turnover, and the record will not tell you that on its own. What it will tell you is precisely who to ask and what to ask them, which turns a three week fishing expedition into two specific questions. Related failure modes, like a missed notice window, have the same shape: the information existed, it just was not attached to anything that would surface it at the moment of decision.

The test is uncomfortable and worth running this week. Pick your three largest renewals in the next two quarters. For each, take the top five requirements from the original sourcing exercise and ask whether anyone still employed can state, without guessing, why each one was mandatory and what the acceptable fallback was. If the answer is fewer than half, you are not negotiating from a specification. You are negotiating from folklore, and the vendor's account team has better records of your last deal than you do.