Information vs Assurance

post by johnswentworth · 2024-10-20T23:16:25.762Z · LW · GW · 1 comments

Contents

1 comment

In contract law, there’s this thing called a “representation”. Example: as part of a contract to sell my house, I might “represent that” the house contains no asbestos. How is this different from me just, y’know, telling someone that the house contains no asbestos? Well, if it later turns out that the house does contain asbestos, I’ll be liable for any damages caused by the asbestos (like e.g. the cost of removing it).

In other words: a contractual representation is a factual claim along with insurance against that claim being false.

I claim^[1] that people often interpret everyday factual claims and predictions in a way similar to contractual representations. Because “representation” is egregiously confusing jargon, I’m going to call this phenomenon “assurance”.

Prototypical example: I tell my friend that I plan to go to a party around 9 pm, and I’m willing to give them a ride. My friend interprets my “plan to go around 9 pm” as an assurance: if I fail to show up around 9 pm to drive them to the party, and my friend misses out on some big thing at the party as a result, then they’ll place the blame on me. It’s a kind of non-monetary insurance - if my assurance fails, then I’m socially liable for damages.

In that context, it all seems pretty obvious - people would normally interpret me as having made an assurance (even if they wouldn’t know how to articulate it), I have knowingly taken on that assurance, so it’s totally reasonable to blame me if I don’t show up around 9 pm. But the whole thing is very implicit, which can make things subtle and tricky.

Suppose the conversation leading up to the 9 pm plan went like this:

Friend: Hey John, what time are you going to the party?

Me: I dunno, probably around 9 pm. [At this point, I’ve merely offered some information; I think most people would not interpret this as an assurance, and would not blame me much if I show up to the party at 8:30 or 10:00 or even skip it altogether.]

Friend: Cool, can you pick me up on the way? [This sounds like a very reasonable request, since my friend’s place is on the way. However, if I agree, then suddenly my “around 9 pm” becomes an assurance - showing up at 10:00 or skipping the party altogether would be a dick move! So my friend’s ask is a lot more costly than it nominally sounds.]

That’s the sort of subtlety which comes up: I intended 9 pm as a prediction, but it might get converted to an assurance in hindsight. And whatever request would convert my prediction to an assurance is implicitly more costly than it sounds.

One major problem which information/assurance ambiguity creates is that it’s potentially-costly to share information, if that information might be treated-in-hindsight as an assurance.

Here’s a real example: a year or so ago, David Lorell applied for a grant from the Long Term Future Fund (LTFF) to work with me. One of the fund managers reached out and said roughly “John, we’re imagining a virtual John Wentworth organization, and here’s the amount of funding we’re willing to allocate this year to the virtual John Wentworth organization. Do you want some of that funding to go to David?” and I said “Yup”. Some time later, David applied for another grant, and the amount he applied for was turned down. I contacted one of the fund managers and basically said “WTF dude, last I heard I was using way less money than the LTFF was willing to fund me for, why is this being turned down?”. It turned out that the information I’d received was out of date, due to various changes at the LTFF.

… and afterwards I apologized for being so annoyed. Because I want it to be cheap for people to share information with me, and getting angry when the information shared with me turns out to be wrong makes it more expensive to share information with me.

Takeaway: notice when you treat information shared with you as an assurance, and check what incentives you set up by doing so.

1. ^{^}

   but do not represent/assure

1 comments

Comments sorted by top scores.