Documentation doesn't go wrong all at once. It drifts. A hotfix goes in on a Friday. A rule gets tweaked for one customer. A developer extends a threshold because the business asked nicely. Nobody updates the spec, because nobody reads the spec.
Years later, the document and the code describe two different businesses, and nobody knows which one is real.
What drift looks like
In the estates we've read, the same patterns come up again and again:
- Thresholds and timings that changed in code but not on paper.
- Rules added for one customer, region or product that no document mentions.
- Processes that were retired in the documents but still run in the system.
- Integrations that were added project by project and never written up.
Why it matters now
Drift has always been a nuisance. It becomes a real risk at three moments: when you migrate, when you change something important, and when you point AI at your documents. In each case, people make decisions based on what they believe the system does.
If you scope a migration from the documents, you scope the wrong thing. If you feed out-of-date specs to a copilot, it repeats them with confidence.
How to catch it
The only reliable way to find drift is to read the documents and the code side by side, rule by rule. That's slow and tedious for people, which is why it rarely happens. It's exactly the kind of work Vera is built for.
Vera reads code bottom up and documents top down, then labels every finding: agree, disagree or gap. A disagreement isn't a verdict. It's a prompt for someone to decide which version is right, before cutover rather than after.