You proposed “to rely upon” in favor of “to trust” in some context recently. There is an ill-defined and ill-named notion that I am striving to capture and perhaps the notions named above relate to it. Sometimes I try to use the word “agendum” to denote what a caller and callee have in common. Another possible word is “purpose”. It is not quite the same thing as the Keykos “process” that is also carried across a gate invocation. Usually the actions transpiring within a computer are due to recent signals entering the computer (or computer network, depending on your temporary perspective). Often you can relate these computer actions to such specific signals.

I think that if a program calls another it is typically relying on the other to support the purposes of the signal. (Not always for the call may be for the purposes logging, billing, profiling or debugging.) When the call is in support of the purpose of the signal I would inclined to say that the caller relies on the called routine. If the call is conventional so as to assume a prompt return and assume an uncorrupted call stack, I would say that the caller trusts but does not rely on the callee. If the callee can assume that all callers pass only valid arguments, then the callee trusts the callers but does not thereby rely on them. (The logger both trusts and relies on its callers; they must do the right thing for the log to be accurate. The logger trusts the callers for integrity of the log; it relies on the callers for the log's correctness.)

This notion of “rely-on” assumes that some program assumes responsibility for some agendum (purpose) as the signal enters the system and when a program with such responsibility calls and relies on another program than that new program assumes the responsibility for the agendum. A log maker carries no such responsibility.

My intuition is that these so far vague notions guide our designs and that understanding more explicitly them would help our designs and especially to explain our motivations for our designs.