Books / Canons / Chapter 3

Part One. The answer is not a verdict. Chapter three.

When Does a Document Count as Evidence?

9 min read

Stone forms. When Does a Document Count as Evidence?
Contents of Canons

Aidos works for a small company in Almaty. The office needed a keyboard. The purchase was approved, Aidos paid ten thousand tenge through Kaspi and sent the documents to Asem, the accountant. Now he is waiting to be reimbursed.

“But I sent you the receipt,” Aidos protests.

“You did,” Asem replies. “The receipt is for the keyboard. The payment confirmation is for a kettle.”

“The amount is the same, though.”

Aidos had bought the kettle for his own home. Its genuine payment confirmation had somehow ended up among the documents for the office keyboard. In the books the keyboard is purchase 42, the kettle is purchase 99. The approval order and the vendor’s receipt concern purchase 42. The bank confirmation is for the same ten thousand tenge, but for purchase 99.

Aidos, Asem, the company and its rules are invented for this example. The bank’s name helps picture the scene; the requirements on documents we set ourselves. By the terms of the problem the organisation reimburses an expense if the purchase’s approval, amount and payment are established without contradiction, and the amount does not exceed ten thousand tenge. For the calculation we take it that every document is current and the audit has confirmed their genuineness.

Is such a folder enough to reimburse purchase 42? Most people say yes — and most people would be signing off on a payment that belongs to another purchase.

The pile, as the machine reads it

The rule and the employer’s policy on documents were given to the machine together. The policy says which kinds of document, issued by whom and checked by whom, may support which of the three facts; it was written by the same person who wrote the rule, and the machine knows nothing about banks, tenge or audit desks except what that policy tells it.

Ask whether purchase forty-two is reimbursable. Not established. And with the answer comes a report, one line for every document paired with the claim it was offered for. The order, offered for the approval: accepted — under the employer’s policy, this document may support that one fact, and nothing more so far. The receipt, offered for the amount: accepted. The bank confirmation, offered for the payment: not accepted. No rule of the policy admits it, and the rule that came closest matched ten of its eleven conditions and failed on the eleventh, which the report prints: the document must concern purchase forty-two.

Aidos holds up a receipt for a kettle while carrying an office keyboard; Asem in round glasses points at the mismatch.

Read that line slowly. The machine did not call the document false. It is genuine, checked, in date, from a trusted bank. It did not say the purchase is unpaid. Ask about payment directly and the answer is not established, not refuted. It said something narrower and more useful: this document, offered for this claim, does not count, and here is the condition it fails. A document that does not count is not evidence of the opposite.

Now add the right confirmation: purchase forty-two, ten thousand tenge, checked by the audit desk. Established. The new document is accepted, and the report points to the step in the proof where the acceptance happened.

The amount has not changed. The rule has not changed. What changed is that the bank document now concerns the purchase you are asking to be reimbursed for.

What a document is to the machine

Here is the chapter’s one idea. In the first two chapters the facts of the case were taken as given: the suit was filed, the flight was cancelled. Here three of the facts the rule needs are declared protected. No statement in the case establishes them, whatever authority stands behind it. The only way in is a document, offered for a specific claim, and accepted by a rule of the policy.

So a document is not a fact and not a witness. It is one half of a pair, and the other half is the claim it is offered for. The confirmation of purchase ninety-nine is a perfectly good document and a bad support for the claim that purchase forty-two was paid; offered for a claim about purchase ninety-nine it would be accepted at once. Acceptance is decided pair by pair, and the report lists pairs, not documents.

That is why the author’s choices are so visible here. Who counts as a trusted verifier, which issuer may vouch for which kind of fact, what a receipt must say: none of that is the machine’s. The machine does not read the bank’s paper; it reads what the folder says about each document, its kind, issuer, amount and dates. It checks those dates against the date of the case and against the last day on which anything may still count, checks that each audit record is tied to its document by the document’s fingerprint, and runs the policy’s rules over the result. A different employer would write a different policy on the same frame.

“Sake approved the purchase,” Aidos insists.

“His approval may establish authorisation,” Asem replies, “but it does not establish payment.”

Even if Sake is entitled to approve the purchase, another question remains: which document confirms that this purchase was paid? Approval, amount and payment each need a document that satisfies the organisation’s rules. A bare statement “the purchase is paid” is not enough.

Would you accept this one?

Try a few more folders. Decide each one before reading the machine’s answer.

No bank document at all, but a plain statement that purchase forty-two was paid, carrying the court’s mark that in the first chapter let a verdict into the case. Not established: a protected fact requires a document. Even a statement carrying the kind of judicial authority accepted in Chapter One cannot establish payment here. This model requires payment to be supported by an admissible document. Both are choices, and both are on the page.

The right confirmation, but its audit check is dated the following January, while the case is decided in March. Not established. The document existed in March; the confirmation of its genuineness did not, and a decision taken in March cannot rest on a check performed ten months later.

The right confirmation, but for a different amount: one tenge instead of ten thousand. The purchase is the same, the genuineness check is in place. Still not established.

The receipt is the anchor in this policy: it fixes what the purchase was, how much and for whom, and every other document must agree with it. The currency matters too: a confirmation for ten thousand roubles against a ten-thousand-tenge purchase will not do either. The equality of the numbers is not enough. A separate folder, with an approval order naming a different employee, is rejected the same way, and the report names the condition: the claim concerns employee seven. In that folder payment is still established; only the approval is lost. The machine does not lose the case when one document is rejected — only the fact that document was carrying.

Two bank records that disagree: the confirmation, and a later record that the payment was reversed, offered against the claim. The policy accepts both. Here is a choice worth seeing: the author recorded the reversal as a denial of the payment, not as a later event that cancels it, and gave the later record no precedence. So the machine keeps both conclusions. Payment is established and refuted, the same third state as in the first chapter. Reimbursement needs payment established and not refuted, so it is not established. The machine did not average the two, did not prefer the later one, did not invent a fourth kind of answer called “disputed”.

The folder Payment Reimbursement
Approval, receipt, confirmation of purchase 99 not established not established
The same, plus the right confirmation established established
Right confirmation, audit check dated next year not established not established
Right confirmation for one tenge not established not established
Right confirmation plus a reversal record established and refuted not established

Every question in this chapter was put to two programs written independently of each other, and their answer documents agreed byte for byte.

The folder in a different order

One more, and it is the strangest. Two documents carry the same identifier, and their contents differ: one concerns purchase forty-two, the other purchase ninety-nine. What should the machine do?

It gives no answer at all. The run stops with an error naming the collision.

The refusal preserves a basic condition of evidence: one identifier must name one document. Choosing whichever conflicting record happens to be listed last would let the order of a folder decide the answer. Rejecting the collision keeps the question visible for the person who can resolve it.

How far to trust the explanation

The chapter has leaned on one promise: that when a document is rejected, the report says why, and says it precisely enough for you to fix the folder. For the confirmation of the wrong purchase that promise holds: ten conditions met, the eleventh named. Now look at the one-tenge confirmation.

It is rejected because one tenge does not confirm payment of the required amount. The explanation must identify that failed condition and that document. A nearby record about another purchase cannot supply the reason for this refusal. Checking a rejection therefore means checking both the status and the grounds attached to it.

A third program, built to verify derivations rather than produce them, certifies that each accepted support is bound in the proof to its policy, its document, its pairing and the rule that admitted it, and rejects seven forged certificates; it does not re-run the policy’s rules or the reading of the documents, and it certifies neither “not established” nor “established and refuted”. Nothing certifies the explanations of rejections at all. They are the most useful part of the answer to the person with the folder, and the least proved.

The retained run records are in the experimental notes.

What is left to argue about

A lawyer preparing a claim keeps two lists: what must be shown, and what shows it. The second list is where cases are won and lost, and it is almost never written down in a form anyone else can check. Here it is written down, pair by pair: this document, for this claim, under this policy, checked by this verifier, as of this moment of knowledge, admitted by this rule or stopped at this condition.

That leaves you three things to argue with. The policy itself: that the receipt is the anchor, that the audit desk is to be trusted, that payment is protected even from a court’s word. Those are one person’s choices, and nothing in the machine says they are good ones for any real employer. The moment of knowledge: the machine refused a check from next January, and you may think a check is a check whenever it was made. And the explanations: a reason must refer to the document and condition actually examined. A useful explanation remains something to check against the record, rather than a finding with authority of its own.

None of it is a verdict. It is a list of pairings and the reasons for them, and the reasons are the part you can still get wrong.

Contents · PDF · EPUB · Free under CC BY 4.0