When the Design Says It Does Not Exist, Check Anyway
A design document stated in bold that no stepped-discount product would be created and no agent action was required. Two of them had been live for a month, self-approving at any amount.
The claim was in bold. No standalone stepped-discount product or promotion would be created, and no agent action was required.
Bold is a strong signal in a design document. It usually means somebody expected to be asked.
What Was Already in the Org
Two of them. Live for a month.
Configured as Qualified Discounts — the kind an agent adds to an order by clicking Add. Which is agent action, described in a document that says no agent action is required.
Both were registered in the bypass-approval custom metadata. That means they self-approve. At any amount.
So the mechanism the design says does not exist had been deployed for four weeks, is operated by a human clicking a button, and skips the approval path entirely regardless of value.
Two minutes in the org. That is the whole investigation.
The Third Artefact
There was a signal, and I want to be honest that it was available before I looked.
The parent story's acceptance criteria describe the agent-added mechanism. In detail. The same mechanism the design document denies.
So the story and the org agree with each other, and the design disagrees with both. Read together, they are a straightforward contradiction between two artefacts.
They are almost never read together. The design document was recent, comprehensive and authoritative-looking, and when a design document and a story disagree, the newer, larger, more polished artefact wins by default. The acceptance criterion reads as leftover wording from an earlier idea. That reading is available, it is comfortable, and it is wrong — and nothing inside either document can tell you which of the two is the stale one.
Only the org can tell you that.
Why This Class of Error Survives Careful Analysis
Documentation describes an intended future. The org describes a delivered past.
An analysis built entirely from artefacts — acceptance criteria against design, design against requirement, requirement against the wiki — is checking documents for consistency with one another. That check can pass completely while every one of those documents is out of date with what is deployed.
Internal consistency and currency are unrelated properties, and coherence makes a stale set of documents feel more trustworthy, not less.
The One Claim the Org Can Falsify by Itself
Most statements in a specification cannot be checked before the build. "The discount will apply to the second charge line." Those describe behaviour that does not exist yet, so there is nothing to look at.
"No such mechanism will be created" is different. It is a claim about absence, in the present tense, about an org you can open right now — the one kind of statement in a specification that the system itself can falsify before a line of code is written for the release.
So it is the cheapest claim in the document to verify, and the one nobody verifies, because absence does not feel like a thing to go and look for. You check what exists. You rarely check what does not.
Which Suite Were You About To Write
This is why the two minutes matter more than they sound.
If no stepped-discount mechanism exists, the test suite is about the new thing being built, and agent behaviour is out of scope entirely. That is one suite.
If two of them are already live, self-approving at any amount, added by an agent with a click, then the suite has to cover what happens when the new implementation lands next to them: agents with two existing paths to a similar outcome, a bypass-approval configuration carrying entries nobody re-examined, and a governance control that two products are currently exempt from at any value.
That is a completely different suite. Different risks, different data setup, different priority order.
The two suites do not overlap much, and I would have written the wrong one with total confidence, on the authority of a sentence in bold.
What I Do Now
Before analysing any design document, I extract every sentence that asserts something does not exist or will not be created. Then I check each one in the org before reading further.
It is a short list. It takes minutes. And it decides which document I am actually reading — a specification for a system, or a description of a system that was superseded a month ago by something already in production.
When a document tells you something does not exist, how long has it been since you checked?