It all seems a bit messed up to me, and maybe you have lost or not described the original goal.
You want the user's profile to contain some choices. For the moment, and to avoid confusion, lets call them 'options'
You have three options now, you might have four or two in the future, and rather than hard code the options, you can create an options model and an options table. In this table, you will create the wording of the three options. You will just have an id column and an option column. Your options model does not need any relationships and nothing else relates to options.
When preparing the profile form for display, you will query the options model and get all the options. These can be a simple collection or an array, or does not matter.
In the profile edit view, you will foreach over the options and add a checkbox for each option. The value of the option is the text of the option (not the id). The name for each checkbox should be expectation[]
When the user saves their profile, you need to save any options that they have chosen. Since you will not programmatically use the responses you just need to store them.
Since there can be many options for one profile, you need a table to store them in. Lets call this expectations. So that you can replay to the user what options they chose, you need a link from the expectations to the profile. So your expectations table needs an option column (string) and a profile_id column. The expectations model needs a belongsTo relationship to the profile. The profile model needs a hasMany to the expectations.
When you save the profile you will have an array of expectation entries. Save the profile and then saveMany the array of expectations. This will create one row in the expectations table for each of the selected options, each one having the profile_id set.
If you later need to show the user what they said, you can get their profile ->with('expectations')
If you decide that the user should be allowed to edit their profile, and change the options then you will have to approach things slightly differently. You would have a link from the expectations table to the options table and have the option_id in the expectations table. This then makes the expectations table a pivot. I would still keep the text of the option that they chose in the expectations table in case you change your mind about the wording of each option. You will have the wording they chose at the time, and not the wording as it is currently.
I hope this helps structure your thoughts a bit