It can be. You can trust someone to have done the job like they claim, but can still verify it to make sure they did it correctly. A second set of eyes rarely hurt.
That's not quite right; the point of "trust but verify"[0] is to assume in the short term that they did the job they claim (correctly, even), and start doing work that depends on it, but verify in the background, and roll things back if they didn't. This gives you some of the benefits of a high trust environment while still coping with the occational lying scumbag.
Of course, if it's fast/cheap enough, you can go with the much superior "verify and don't even waste time asking", but that's often impractical.
0: Well, the steel-man interpretation anyway; the historical version seems to just be a euphemism for "Don't trust, but claim you do so they look bad if they try to complain about it.".
I think the whole bone of contention with the statement is pretty much a semantic argument.
What is "trust"?
In your scenario, I wouldn't classify it as trust at all, yet I know I've used that word to describe something similar when describing building software.
But if you wanted to pin me down, I'd waffle and say, yeah, I'm not really talking about trust. If I trusted function X, I wouldn't check anything about it, I'd assume it's right.
So in your scenario, I wouldn't classify what you were doing as platonic trust either. I wouldn't call it trust unless the verification came when the deliverable was due. But then by then, your trust has been violated.
For instance I ordered something online. I trust the information FedEx gives me is accurate. It says my package is delivered. I am going home and I expect to see the package at my door. I trust my neighborhood/apt complex enough that I don't expect it to be stolen. That is trust. I don't have anything to confirm what I currently believe, but I still believe it.
In contrast, I stopped trusting the USPS at my old apartment. Because a couple of times, they've claimed a failed delivery attempt even when I was home. So I stopped expecting things to get delivered when they said they would be when they would come through USPS.
And I never trusted packages to be delivered to the house I lived at before that place. I'd get things delivered to work.
When people tell me they "trust, but verify", I tell them it's either or. You can trust or you can verify. When they tell me they trust the results of my work but want to verify it, I explicitly tell them, "I don't want you to trust it, I want you to double-check me to make sure I got it right. I don't fully trust myself. Accuracy is important, I want a critical eye on this in case I missed something. I don't mind being wrong if it means we are right."
> I think the whole bone of contention with the statement is pretty much a semantic argument.
> What is "trust"?
Actually I was talking exclusively about the phrase "trust but verify". Absent context, "trust" is like "know"; it's a useful shorthand but shouldn't be used if you're trying to speak rigorously about what's actually happening.
That's not trust.