The domain expert tells you one thing and the written procedure says another. How do you work out which one the system should follow?

Ask what each source is evidence of

The instinct is to rank the two sources, and both available rankings are wrong. Trusting the document because it is written treats a file's existence as authority. Trusting the person because they do the job treats one operator's view as the whole business. Neither is a claim to be believed or disbelieved; each is evidence of something narrower than it appears.

A procedure document is reliable evidence of what somebody intended the process to be on the date they wrote it, and of what the organisation would say if asked officially. It is weak evidence of current behaviour, because nothing forces it to be updated when practice changes, and the incentive to revise it is lowest in exactly the areas that change most.

An expert's account is reliable evidence of what happens in the cases they personally handle, now. It is weak evidence about volumes they never see, about other teams, and about the intended rule, because people reconstruct reasons for habits with great confidence. The first question to ask yourself is therefore not who is right but which parts of the answer each source is even competent to give.

The reading in which both are true

Before you treat this as a conflict, look for the interpretation under which nobody is wrong. That is the outcome most of the time, and finding it is worth more than picking a winner, because the shape of the overlap is usually itself the requirement.

What you observe	The likely reading	What it means for the build
The document describes an approval step the expert never performs	The threshold changed, or the step now happens elsewhere	Find where the control moved to; it rarely vanished
The expert describes a step absent from the document	Practice absorbed an exception nobody went back to write down	Model the step, then ask how often it fires
Both describe the same step with different sequencing	Two variants exist by product, region or channel	The variation is a real dimension of the model
The document is stricter than practice everywhere	Either the rule was relaxed, or it is being ignored	These two look identical and are not the same at all

The most common of these is the third, and it is the one engineers collapse. When a document and a person disagree about ordering or about who authorises something, the reason is often that each is describing a different variant correctly, and the business has never had to name the fact that there are two. Building either one alone gives you a system that is right for half the volume.

Get evidence that neither party controls

The way out of a stalemate between two accounts is a third source that has no opinion. Production data is the best one available and is routinely ignored in this situation.

If the argument is whether an approval happens, count the records that have an approver and the records that do not, over a year, grouped by amount. If the argument is whether a state is reachable, select the distinct values the status column has actually held rather than the enum in the code. If the argument is about frequency, the ticket queue or the audit trail settles it in an hour. Bring the number to the next conversation and the discussion changes character: you are no longer asking two people to agree about the past, you are asking them to explain a fact.

That reframing matters for the relationship as well as the answer. Nobody has to be told they were wrong, and an expert who watches you check rather than adjudicate will give you the awkward material next time.

The one shape that is not yours to resolve

There is a version of this situation that is not a documentation problem, and mistaking it for one is the expensive error. If the written procedure exists because it is a control — because an auditor raised it, because a regulator requires it, because a contract commits to it — and the expert's account is that the step is skipped, then you have not discovered that the document is stale. You have discovered that the organisation is not doing something it says it does.

The engineering instinct is to implement what happens, because working software should reflect reality. Do not, and be explicit about why: writing the deviation into a new system converts an operational gap into a designed behaviour, with your name on the commit. It also destroys the only evidence that the two ever differed.

The move is to raise it as a finding, in writing, to whoever owns the control rather than to the person who told you. Something as plain as this is enough:

"The credit-control procedure requires a second approval above the delegated limit. In the last twelve months, 1,340 of 1,398 releases above that limit have a single approver. I need to know whether the limit has changed or whether the control has lapsed, because the new service has to enforce one or the other. I have not changed any behaviour while this is open."

You have named the observation, the evidence, the decision you need and the fact that you have not acted. That is the whole obligation, and it takes a paragraph.

Close it with a record, not a conversation

Whatever the resolution, the failure mode from here is that it lives in a meeting. Write the answer where the next engineer will hit the same contradiction: both accounts as given, who gave them and when, the evidence you found, the decision, and who made it. Then get the losing artefact changed — either the document is corrected or the practice is, and if neither happens you have simply added a third account of the process for somebody else to be confused by.

A document and an expert who disagree are not two answers to be ranked; they are two dated observations, and the interesting question is what changed between them.