Standardness refers to a stricter set of rules enforced by full nodes on a transaction in addition to the consensus rules. Policy is an even broader set of rules or processes followed by a node. Contrary to standardness it is not local to a single transaction nor is it specific to validation rules.
Taken broadly, policy is everything that is not consensus. The set of rules dictating whether a block is valid is consensus. All the rest: how the block is relayed, whether a cache of unconfirmed transactions was used to speed up its transmission and validation or how unconfirmed transactions are propagated through the network is policy. For example:
- A transaction is invalid by Bitcoin consensus if the sum of the value of its outputs is larger than the sum of the value of its inputs. (In other words, its fee is less than 0.)
- A transaction is invalid by Bitcoin Core standardness rules if it has a fee lower than 1sat/vbyte.
- Sending an unconfirmed transaction which has 25 or more unconfirmed ancestors violates Bitcoin Core policy rules.
Mempool policy is the set of rules describing the validity of a transaction from the point of view of a node’s mempool. Probably the biggest difference with standardness is that it is contextual. An unconfirmed transaction may well be valid according to standardness (and therefore consensus) but still be refused by a node’s mempool. The ancestor rule from above is one such example.
The mempool isn’t however the only area where policy rules apply. For instance, transaction relay is another. For instance, the maximum number of transactions a node will request or announce per peer is often referred to as policy.
Finally, while policy may vary from a node to each other not all rules are equally important. A node for instance may choose to not store and relay unconfirmed transactions which store data in OP_RETURN outputs, or not store and relay unconfirmed transactions at all, and still be part of the network. But you can think of any stupid policy a node may have (for instance only finding peers and/or relaying blocks through its own custom protocol), in which case it would hardly even keep up with the network although it does implement all consensus rules. And there is every degree in-between, with the corresponding expectations one may have about the network.
Note this is an attempt at an answer; terminology is notoriously confusing in Bitcoin and people may have a different view of what “policy” represents. It’s just the definition i’ve been using (without ever spelling it out, so thanks for the question) and found useful when discussing related matters with other Bitcoin developers.
