Originally written in French. Translated by AI — the meaning has been preserved, not the prose.
Angle
"What happens if the customer cancels this item after approval?" — the question lands on Slack, the support page does not cover the case, and a Product Manager opens a test environment for half an hour. Going to look for the answer in the repository rather than in the page only removes that half hour: an answer drawn from the code gets it wrong just as readily as outdated documentation, and with more confidence. What actually reduces the risk is not the change of source, it is the regime imposed on the answer — every assertion tied to a designatable element, the function that applies the rule, the test covering the scenario, the merge request that introduced the behaviour, the state of the feature flag; and every unestablished area named, the missing test, that particular customer's configuration you cannot reach, the product decision the code seems to contradict. Without that double regime, you replace the Product Manager's imperfect memory with a model's probabilistic memory, and the risk does not decrease: it changes bearer, passing from the person who knew he did not know to the support agent who believes he does.
Synthesis
The reasoning starts from a cost nobody counts, and that entry point is not incidental: it explains why the situation has been lived with for so long. Each verification takes half an hour and appears in no ticket, no estimate, no roadmap line. A second cost adds to it, even less visible, and it is not reduced by the same means: the interruption destroys the working state of whoever it reaches, and an answer obtained in two minutes instead of thirty leaves that state intact.
The move towards the code is presented as an answer to that cost, and it is one — provided you do not mistake it for an answer to the reliability problem, which is another problem. The repository is the only representation that does not diverge from what the product does; but it does not say everything a document said. The useful cut does not run between code and documentation, it runs between what describes — regenerable — and what explains — to be preserved, because no reading of the repository reconstitutes it. And the repository alone is not enough to settle matters: a feature flag leaves two possible behaviours there, and it is the deployed configuration that decides which one applies to a customer.
This is where the answer regime becomes the real subject. Two symmetrical requirements, and neither replaces the other: citing bounds what is asserted, admitting bounds what is not. The first acts at the moment the answer is produced, not at the moment it is reread — which is what distinguishes it from a traceability requirement, which presupposes a reader. The second gives value to what looks like a failure: flagging that no test covers a case, or that a product decision and the code diverge, is product information in its own right.
There remains the question of who all this benefits, and it is settled by form rather than by duplication: a single answer cut into angles — the short answer, the use, the value, the limits, the evidence — avoids maintaining as many consistent versions as there are functions, and gives the evidence somewhere to exist without cluttering those who will never open it.
Finally, two conditions frame the whole, and they do not belong to the mechanism. The first concerns the material being read: code whose exceptions carry the vocabulary of the domain lets itself be questioned, code where the rules are scattered behind technical names resists — a model as much as a developer. The second concerns the sorting upstream: not every product question is a reading. Those that call for an arbitration can be delegated to nothing, whatever the tooling.
What the whole brings into view: changing source of truth settles a problem of access, not a problem of trust. Trust is not won on where the answer comes from, it is won on what the answer obliges itself to show — and the same regime would hold for an answer drawn from a body of law or from a set of meeting minutes.
Tensions / contradictions
Two requirements in this batch conflict at a threshold nothing establishes. An answer must name what it does not know; an answer hedged at every sentence becomes unusable again, and its reader goes back to open a test environment — the cost you meant to remove comes back whole. The point of balance is described as necessary and never located.
Second tension, on what the mechanism really addresses. It attacks search time; the dominant cost, for a role whose work is cumulative, is that of interruption. Answering faster can therefore improve a figure without changing anything about what gets lost, and the article does not say how the question would stop arriving.
Third tension, with the way the move towards the code has been told elsewhere: there, the passage of authority from the specification to the repository is explained by the collapse of access costs. Here, access is a given and turns out to be insufficient. The two hold together, but the order of priorities reverses depending on which you read first.
Finally, the very term source of truth resists this batch: the repository is authoritative on the rules, the deployed environment is authoritative on what a given customer sees, and the history is authoritative on intent. Three sources, each sovereign over one question — which the singular in the phrase does not convey.
Questions
- What, in an organization, checks that the evidence cited really establishes what the answer makes it say, and how often?
- How does a company that judges its answers on how clear-cut they are take to a mechanism where part of the deliverable is the admission of a gap?
- On what conditions does a flagged gap — a missing test, a product decision the code contradicts — become work actually taken on rather than one more line at the foot of the answers?
- What becomes of this regime when the behaviour being queried no longer rests on a readable repository but on a trained model, where no function carries the rule?