Bitcoin consensus rules determine which transactions, blocks and chains a node accepts as valid. They cover matters such as signatures and scripts, prevention of double spending, block proof of work, issuance and the chain with the most accumulated work; they are not a vote, website or list maintained by one authority.
A rule either accepts a candidate history or rejects it. Hashrate, market price, corporate support and social-media majorities cannot make an invalid block valid for a node enforcing different rules.
Miners order transactions and extend a chain, but full nodes verify their output. Developers publish software, but users choose whether to run it. Economic actors can influence coordination, yet none receives an automatic protocol veto.
Consensus rules decide block validity. Mempool and relay policy decide what one node stores or forwards before confirmation; a policy-rejected transaction can still be consensus-valid in a block.
A soft fork narrows what is valid and can be enforced by upgraded nodes; a hard fork permits something old rules reject. Deployment mechanisms coordinate activation, but adoption ultimately depends on software voluntarily run by users.
Verification means obtaining blocks and checking them against the chosen rules, not trusting an explorer or miner. Different implementations must reproduce the same consensus result, which is why edge cases and compatibility tests matter.
Consensus determines validity; relay and mempool policy determine local forwarding before confirmation.
For the clearest picture, read this entry together with Full Node, Soft Fork, Proof of Work, Bitcoin Core. The reverse links also lead from 21 Million, Soft Fork, Hard Fork, BIP (Bitcoin Improvement Proposal).