In the image below from Rusty Russell's Deployable Lightning paper, you can see a visualization of the commitment transactions and their outputs:
For each payment in a channel, there are two commitment transactions generated, one for Alice and one for Bob. Both Alice and Bob sign both commitment transactions, so they're both valid transactions (although only one of them could be included in the blockchain since both transactions spend the same inputs).
Both transactions pay two outputs. The transaction Alice has (on the left in the diagram, Commit TxA) pays the following two scripts:
A regular P2PKH (or its segwit equivalent) output that Bob can spend at his leisure.
An output that Alice can spend after waiting a specified number of blocks (let's say 100), as enforced with
OP_CSV, or which Bob can spend if he has a piece of data that hashes to a value in this output. I call this the pre-image; in other descriptions of Lightning this is a private key used to generate a signature.
In the transaction that Bob has (on the right, TxB) these are reversed, there's:
In these outputs, Alice selects the pre-image that prevents Bob from spending her output (Revocation-A) and Bob selects the pre-image that prevents Alice from spending his output (Revocation-B). They could use a random number of large size, although they'll probably both use hashes from a hashchain generated using Rusty Russell's 64-dimensional shachain to allow compact storage of any revealed hashes, seeding the chain with some initial random value.
Each time Alice and Bob agree to update the state of the channel, they both reveal to the other person the pre-image for the hashlock they placed on the output for the previous state of the channel, allowing the other person to create a breach remedy transaction.