Home / Blog / Requirements · Source of Truth

Everyone Wrote It Down. The System Had Already Decided Otherwise.

The requirement was correct in every artifact. The platform had a different definition of the same word, and nobody had written that down anywhere.


The requirement was correct in every artifact. The platform had a different definition of the same word, and nobody had written that definition down anywhere.

That is a source-of-truth failure that looks deceptively safe from the document side. Every document can agree with every other document and still be wrong about the system that will execute the rule.

Agreement between documents is not the same as agreement with behavior

Teams usually test consistency horizontally. The requirement matches the ticket. The ticket matches the acceptance criteria. The status note describes the same scope. Traceability looks clean because every written artifact points to the same idea.

But software behavior is not produced by prose alone. It can also be produced by configuration, defaults, existing data rules, workflow states, inherited platform semantics, permissions and logic that predate the current requirement.

If one of those layers already owns the meaning of a term, the project can have two sources of truth without noticing. The documents say what everyone agreed. The system says what will actually happen.

The dangerous word is the one everyone understands

Ambiguous jargon often gets challenged because it looks ambiguous. Ordinary words are harder. A familiar term can carry one definition in a requirement and a different operational definition inside the platform.

Nobody raises the conflict because nobody experiences it as a conflict. Each side hears a normal word and supplies its own established meaning. The discrepancy becomes visible only when the behavior is exercised or when someone compares the written rule with the executable one.

Trace the definition, not just the sentence

For delivery-critical requirements, I now want a vertical trace as well as a horizontal one. Do not stop at “where else is this requirement written?” Ask “where does this behavior get decided?”

The answer might be a configuration value, a workflow rule, a field definition, a permission model, an integration mapping or code. The specific layer depends on the system. The control principle does not: find the place where the behavior becomes executable and compare its semantics with the words the project is using.

Executable-definition check
I am going to give you a requirement and the system/configuration evidence that influences the same behavior.

Do not summarize either source.

1. List the key terms whose meaning must be identical for the requirement and the system behavior to agree.
2. For each term, quote or paraphrase only the definition supported by each source.
3. Mark MATCH, DIFFERENT, or NOT DEFINED.
4. For every DIFFERENT or NOT DEFINED item, state the user-visible or delivery consequence that follows directly from the mismatch.
5. Do not choose which source is correct. Surface the decision that needs an owner.

Requirement: [PASTE]
System/configuration evidence: [PASTE]

Why “we wrote it down” can be false reassurance

Documentation is valuable because it externalizes decisions. But repeating the same statement across more documents does not create a stronger source of truth if all of those documents inherit the same untested assumption.

The stronger check is triangulation. Compare the written intent with the rule that will execute it and, where possible, with an example of the resulting behavior. If all three agree, confidence rises for a reason. If the documents agree and the executable rule does not, the contradiction is visible before it becomes a release surprise.

The control I keep

When a requirement depends on an existing platform, I ask one extra question: where has the system already decided what this word means?

If there is an answer, that definition belongs in the review. If there is no answer, the ambiguity itself needs an owner. Either is safer than allowing a clean chain of documents to reassure us that the system agrees simply because the documents agree with each other.

Want the prompts behind workflows like this?

The Multi-AI Prompt Pack gives you ready-to-run prompts across ChatGPT, Claude, Gemini, Grok, and Perplexity, mapped to real PM and BA tasks. Free, instant, in your inbox.

Get the Free Prompt Pack →

This article was published in Analyst's Corner on Medium. Read the original on Medium →